Ozow Hub

Take a payment

Everything 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.

On this page4 sections
Markdown, linkedMarkdown, everything inlined

Your system asks One API for a payment, sends the customer to Ozow's hosted page, and learns the outcome from a 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., not from the 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. back. Implement the pages in the order above.

One API only. The Payments API is a separate contract, receives no new features, and has its own package, migrate-a-payin-to-one-api. One API authenticates with 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 signs each webhook with a Svix signature. It uses no hash at all, so computing one means you are on the wrong contract.

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 what this package takes a payment with. It is enabled on every account by default and needs no opt-in, so it is the method a first integration meets. Card, vouchers, PayShapPayShap South Africa's rapid payments service, run by the banks. Low-value payments clear in seconds, and the recipient can be identified by a ShapID instead of by an account number.payshap.co.za, crypto and buy now pay later are opt-ins that arrive on the same request once Ozow enables them, which is why there is one integration here rather than one per method.

The webhook is the outcome and the redirect is not. A customer who closes the tab must still end up with the right order state. Verify the signature before acting on a delivery.

Handle every status the statuses page lists. The test cases cover a successful payment, a cancellation, a failure, a duplicate notification and a status check against the API.

Build against production. Staging has separate credentials and its own hostname. PayinsPayin 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. can be tested in production.

What this was built from

Implement against these

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

  • Quick start: accept your first payment: Accept your first Ozow payment with One API. Get a token, create a payment request, redirect the customer, and read the webhook that confirms it.
  • Redirect to Ozow: Build a redirect payin with One API. Create a payment request, send the customer to Ozow's hosted page, and confirm the result from the webhook.
  • Verify a webhook signature: The signature on a One API webhook, the five steps that check it, and a working implementation in four languages.
  • Payin test cases: The payments to run before you go live with Ozow, what each one delivers, and a 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.
  • Pay by Bank: The payer authorises the payment directly from their bank account.
  • 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.
  • Payment method identifiers: The UUIDUUID A 128-bit identifier written as 36 characters, such as 497f6eca-6276-4993-bfeb-53cbbbba6f08. Generated rather than assigned in sequence, so two systems can create identifiers without coordinating.Wikipedia for each payment method Ozow supports, for the fields that take one.
  • Transaction and settlement statuses: Every payin, payout, refund and settlementSettlement Ozow paying the money you have collected into your bank account. Payins arrive at Ozow first and are settled to you on a schedule, so what a customer paid you today and what has been settled to you today are different amounts. status, which are final, and what to do about each.
  • Building a secure integration: Where Ozow's security responsibility ends and yours begins: credentials, webhook 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.