Ozow Hub
On this page4 sections

Three ways to take a payment without sending the customer to a page of Ozow's: the payment page in an iframe on your checkout, the same page in a modal over it, or the Wallet SDK rendering Apple Pay, Google Pay and optionally card into a container you place. They are alternatives, not steps. Read the comparison, then implement one.

All three are on the Payments API, not One API. Authentication and the notification are the Payments API's throughout: an API key and a hash, not a bearer tokenBearer token An access token sent in the Authorization header as Authorization: Bearer <token>. Anyone holding the token can use it, which is why it belongs on your server and never in a browser or a mobile app.RFC 6750 and a Svix signature. Create the payment request server-side with POST /postpaymentrequest, which returns paymentRequestId; the SDK takes that value as its requestId option. For a 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. 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., take take-a-payment instead. Mixing the two contracts in one integration means two sets of credentials and two notification formats.

The SDK's events are not confirmation. The outcome arrives as a notification to your NotifyUrl, hash verified. A postMessage event or a redirect to your success URL reports what the browser did, not what the bank did.

The hash is computed from your private key, so the payment request must be built server-side in every case. Browser code that builds it has published the key.

What this was built from

Implement against these

Every field name, order and format on these pages is exact.

  • Embedded iframe: Load the Ozow payment page inside a container on your own checkout with the Ozow SDK, so your customer never leaves your site.
  • Embedded modal: Open the Ozow payment page as an overlay on your own checkout with the Ozow SDK, so your customer pays without leaving the page.
  • Embedded wallet: Offer Apple Pay, Google Pay and cards on your own checkout through a secure Ozow iframe, so card data never touches your page. Approved merchants only.
  • Payin test cases: The payments to run before you go live on the Payments API, what each one delivers, and a notification handler that survives all of them.

Background

Context for the above. Nothing here is implemented against.

  • How Ozow works: How Ozow connects you to South African banks and payment methods, and the two directions money moves: payins from customers, payoutsPayout Money sent from a merchant to a bank account. Unlike a refund, a payout is not tied to a payment anyone made you, so you can pay anyone with a bank account. Payouts draw on your float rather than on your incoming payments, and they are not self-service: they need approval from Ozow and testing in staging first. to recipients.
  • Prerequisites and onboarding: What to have in place before you write any code: a merchant account, Dashboard access, your credentials, and payout eligibility if you need it.
  • Choosing a checkout experience: Where your customer pays decides how much you build 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. Compare redirect, embedded and server to server.
  • Hash calculator: Work out the hashCheck a request carries, and see the exact string it is computed from.
  • Building a secure integration: Where Ozow's security responsibility ends and yours begins: credentials, 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. endpoints, verifying notifications, and validating amounts.

The contract

Fetch the OpenAPI document named above to generate a client, or to check a field name or an enum against the schema.