Ozow Hub

Take a recurring payment

Everything needed to collect from a customer on a schedule with One API, from the consent the customer gives once through to each collection and the webhook that reports it.

On this page4 sections
Markdown, linkedMarkdown, everything inlined

A recurring payment is two separate things: consent, which the customer gives once, and collection, which you trigger for each amount afterwards. They are different calls and they fail for different reasons.

Capitec is the only supported bank today, on a limited rollout to approved merchants. A customer who banks elsewhere needs a standard payment each cycle, so that fallback is part of the design rather than an afterthought.

Four steps: create the subscription, 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. the customer to consent, action a payment against that consent, handle 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.. A collection is not confirmed by the response to the call that triggered it. The outcome arrives on the webhook, exactly as it does for a one-off 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..

Subscription statuses are their own set, separate from a collection's. A subscription sits at PendingAuthorization until the customer approves consent in their banking app, and only an Active one can be collected against; an individual collection carries Pending, Successful or Failed instead. Copy every name as written, including Canceled, which has one l.

What this was built from

Implement against these

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

  • Recurring payments: Collect repeat payments with One API. One consent the customer approves, then merchant-initiated collections that need no further customer action.
  • Verify a webhook signature: The signature on a One API webhook, the five steps that check it, and a working implementation in four languages.

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.
  • Recurring payments: Charge a customer repeatedly after a single authorisation.
  • 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.