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.
On this page9 sections
Build with AI 2 packages
A build package is every page for one task, with the API operations they use. Copy the prompt into a coding assistant, or hand it the package itself: slim links to each page, full inlines all of them in one document.
- Take a paymentEverything needed to take a payment end to end with One API, from credentials through the hosted page to the webhook that confirms it, and the test cases that prove each outcome before you go live.
- Embed checkout in your own pageEverything needed to keep the customer on your site while they pay, as an iframe, a modal, or the Wallet SDK for Apple Pay and Google Pay, with the notification that actually confirms the payment.
If you're building a payinPayin A payment made by a consumer to a merchant. The direction most of this site is about: money coming in. Its counterpart is a payout, which sends money out and is not tied to any payment anyone made you. 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 DSSPCI DSS The security standard that applies to anyone who stores, processes or transmits card data. Its reach is the reason most integrations avoid touching card numbers at all.PCI Security Standards Council scope.
If you're not sure, use RedirectRedirect Sending the payer to the Ozow payment page to complete the payment, and returning them to your site afterwards. The alternative is embedding the checkout in your own page, where the payer never leaves it. to Ozow.
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 BankPay by Bank The payer authorises the payment inside their own banking app or online banking, and the funds move from their bank account. No card is involved and no card details are entered. is enabled by default. Any other methods you opt into, card, PayShap requestPayShap Request The request side of PayShap. Rather than the payer pushing money, the payee asks for it: the payer receives a request and approves it in their own banking app, and the funds move once they do. Enabled by Ozow on request rather than by default.payshap.co.za, 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 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.
To opt into a payment method, speak to your Ozow account manager. See Prerequisites and onboarding.
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.
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 PayCapitec Pay Capitec's own payment method. The payer gives a cellphone, account or ID number rather than card details, and approves the payment in the Capitec app, so no card number and no banking login is ever entered at checkout. It gets its own button rather than sitting inside the bank list, and it requires Customer Identity Verification.Capitec", "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, 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.
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 VerificationCustomer Identity Verification Checking that the payment instrument belongs to the natural person making the payment. Ozow requires it for merchants it has classified as high-risk, on Pay by Bank, Absa Pay, Capitec Pay, Nedbank Direct EFT, FNB Payment Requests and PayShap Request, and can disable those methods where it is not implemented correctly. if you operate in a high-risk industry. Check Customer Identity Verification 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, CSPContent Security Policy A response header listing the origins a page is allowed to load scripts, frames and other resources from. A policy that does not name Ozow's origin blocks an embedded checkout, and the browser reports it in the console rather than on the page.MDN allowances |
Choose iframe if you want the payment form to sit inline in your checkout page as part of the layout. → Embedded iframe
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
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
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 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 webhookWebhook A URL of yours that Ozow calls when something happens, rather than you polling to find out. The call carries no credential of yours and arrives at a public URL, so authenticate it before acting on it: a hash field on the Payments API, a Svix signature on One API. as the source of truth, not the customer's browser returning to your success page. See Building a secure integration.
- Handle every status, not just success and failure. See Transaction and settlement statuses.
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
Last updated