# Choosing a checkout experience

> Where your customer pays decides how much you build and whether you take on PCI DSS scope. Compare redirect, embedded and server to server.

Source: https://hub.ozow.com/integration-methods/apis/payin/

If you're building a payin integration with our APIs, your first decision is where the customer
actually pays. That affects how much you build, whether the customer leaves your site, and whether
you take on PCI DSS scope.

> ℹ️ **If you're not sure, use [Redirect to Ozow](https://hub.ozow.com/integration-methods/apis/payin/redirect-to-ozow.md).** It's the fastest to build,
> it supports every payment method we offer, and Ozow carries the PCI DSS scope. Moving to an
> embedded experience later is a real piece of work rather than a switch: the embedded guides are
> Payments API integrations, so the endpoint you post to, the credentials you send and the way you
> verify the notification all change.

## The three approaches

|  | Redirect to Ozow | Embedded | Server-to-server |
|---|---|---|---|
| **Customer leaves your site** | Yes | No | No |
| **Who renders the payment form** | Ozow | Ozow | You |
| **Your PCI DSS scope** | None | None | Full |
| **Payment methods** | Enabled by Ozow on your account | Enabled by Ozow on your account | Enabled by Ozow on your account |
| **Available today** | Yes | Yes | No |
| **Build effort** | Lowest | Moderate | Highest |

All three use the same underlying model: you create a payment request from your server, the customer
authorises it, and Ozow notifies your server of the outcome. What changes is where the
authorisation happens, and, between redirect and embedded, which API you build it against.

## One integration, every payment method

Payment methods are enabled on your Ozow account, not in your code.

**Pay by Bank is enabled by default.** Any other methods you opt into, card, PayShap request,
voucher, buy now pay later, crypto; are enabled by Ozow on your account. Once enabled, they appear
on the Ozow payment page automatically. You don't build a new integration, call a different
endpoint, or ship code for each one.

This means you can start with Pay by Bank, go live, and add methods later as a commercial decision
rather than a development project.

Two things to know:

- **[Standalone buttons](#standalone-payment-buttons) are optional extra work.** They're recommended
  for conversion, but each one is a per-method build rather than something enabled on your account.
- **Apple Pay and Google Pay ride along with card**: they don't have their own `institutionId`. Once
  card and wallet payments are enabled on your account, they appear on the Ozow payment page
  automatically; on the default selection screen and on the card payment screen, for customers whose
  device and browser support them. To render them directly on your own checkout page instead, use
  the [embedded wallet](https://hub.ozow.com/integration-methods/apis/payin/embedded-wallet.md).

To opt into a payment method, speak to your Ozow account manager. See [Prerequisites and onboarding](https://hub.ozow.com/getting-started/prerequisites-and-onboarding.md).

## Redirect to Ozow

You create a payment request server-side and send the customer to the URL Ozow returns. They
complete the payment on an Ozow-hosted page, then return to your site.

**Choose redirect if:**

- You want the shortest path to a working integration
- You want every enabled payment method available without extra work
- You don't want payment details touching your infrastructure
- You're integrating a backend system, an invoicing flow, or anything without a browser checkout of
  its own

**Look elsewhere if:** keeping the customer on your own domain throughout is a hard requirement.

→ [Redirect to Ozow](https://hub.ozow.com/integration-methods/apis/payin/redirect-to-ozow.md)

### Standalone payment buttons

By default, the Ozow payment page asks the customer to choose how they want to pay. If you'd rather
show your own buttons; "Pay with Capitec Pay", "Pay with card"; and send the customer straight to that
method, pass the relevant `institutionId` when you create the payment request. The customer skips
the selection screen.

This works with both redirect and embedded checkouts.

The identifier for each one is in
[Payment method identifiers](https://hub.ozow.com/integration-methods/apis/payin/payment-method-ids.md), where the **Standalone button**
column marks the methods you can put your own button behind.

> ℹ️ There's no `institutionId` for Apple Pay or Google Pay, and you don't need one. Once card and
> wallet payments are enabled on your account, the wallet buttons appear alongside card entry; both
> on the default selection screen and on the card payment screen. If you want a standalone card
> button, use the **Card** `institutionId` and the wallet buttons come with it. To render them on
> your own checkout page instead, use the [embedded wallet](https://hub.ozow.com/integration-methods/apis/payin/embedded-wallet.md).

> ⚠️ If you replace the Ozow selection screen entirely with your own buttons, newly enabled payment
> methods won't appear until you add a button for them. Worth keeping in mind if you plan to add
> methods over time.

> ℹ️ Several bank methods require **Customer Identity Verification** if you operate in a high-risk
> industry. Check [Customer Identity Verification](https://hub.ozow.com/integration-methods/apis/payin/identity-verification.md) before
> building standalone buttons for them.

## Embedded

The customer never leaves your page. Ozow still renders the payment form, so you take on no PCI DSS
scope; you're hosting it inside your own layout.

**All three are Payments API integrations**, unlike the redirect above, which is One API. The
payment request, the credentials and the notification check are the Payments API's throughout.

There are three variants.

|  | iframe | Modal | Embedded wallet |
|---|---|---|---|
| **What the customer sees** | Ozow checkout inside a container on your page | Ozow checkout in an overlay above your page | Apple Pay, Google Pay and card, in an iframe on your page |
| **Container element needed** | Yes | No | No |
| **Payment methods** | All enabled on your account | All enabled on your account | Apple Pay, Google Pay, card |
| **Requires** | Ozow SDK and jQuery | Ozow SDK and jQuery | Ozow Wallet SDK |
| **Additional setup** | None | None | Card and wallet payments enabled on your account, Apple Pay domain verification, CSP allowances |

**Choose iframe** if you want the payment form to sit inline in your checkout page as part of the layout.
→ [Embedded iframe](https://hub.ozow.com/integration-methods/apis/payin/embedded-iframe.md)

**Choose modal** if you'd rather trigger checkout from a button and have it appear over your page.
Same SDK, no container markup to manage. → [Embedded Modal](https://hub.ozow.com/integration-methods/apis/payin/embedded-modal.md)

**Choose the embedded wallet** if you want Apple Pay, Google Pay and card payments rendered directly
on your own checkout page rather than on an Ozow screen. Card and wallet payments must be enabled on
your account by Ozow first. It covers those three methods only; if you also need Pay by Bank or
anything else, combine it with redirect or one of the other embedded options. → [Embedded
Wallet](https://hub.ozow.com/integration-methods/apis/payin/embedded-wallet.md)

> ⚠️ The iframe and modal checkouts require jQuery on the page and must be loaded through the Ozow
> SDK. Don't build your own iframe around a payment URL, it won't behave correctly and it isn't
> supported.

## Server-to-server

You collect the customer's payment details on your own page and post them to Ozow from your server.
Ozow renders nothing.

> ⚠️ **Not available yet.**

Because you'd be handling raw payment details, you'll need to be PCI DSS compliant to use this. If
you're evaluating it, speak to your Ozow account manager early; compliance is usually the longest
part of the project.

## Native mobile apps

Ozow doesn't provide a native iOS or Android SDK. For payments inside a mobile app, use [Redirect to
Ozow](https://hub.ozow.com/integration-methods/apis/payin/redirect-to-ozow.md) and open the payment URL in a system browser or web view.

> ⚠️ The embedded wallet SDK is a web SDK. It is not supported inside native mobile applications.

## What every approach still needs

Whichever you pick, these don't change:

- **Create the payment request from your server**, never from the browser. Your API credentials must
  never reach client-side code.
- **Treat the webhook as the source of truth**, not the customer's browser returning to your success
  page. See [Building a secure
  integration](https://hub.ozow.com/getting-started/building-a-secure-integration.md).
- **Handle every status**, not just success and failure. See [Transaction and settlement statuses](https://hub.ozow.com/integration-methods/statuses.md).

## Still deciding?

- Building a normal online checkout and want it working quickly → **Redirect**
- Customers must not leave your domain → **Embedded iframe** or **Modal**
- You want Apple Pay and Google Pay on your own page → **Embedded wallet**
- You want your own branded button per bank or method → **Redirect or Embedded, with standalone buttons**
- You're PCI DSS compliant and want full control of the form → **Server-to-server**, when it's released