Recurring payments
Charge a customer repeatedly after a single authorisation.
On this page5 sections
Build with AI 1 package
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 recurring paymentEverything 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.
Limited availability, and by approval only.
Recurring payments are available on Capitec accounts, to merchants Ozow has approved for a specific use case. Not all use cases are authorised. Speak to your account manager before planning around them.
Recurring payments let a customer authorise you once, and then you charge them repeatedly without sending them back to their bank each time.
That's the difference from a standard Ozow payment. Normally the customer authorises every transaction. With recurring payments they give consent up front, including the limits they're comfortable with, and after that you initiate the payments yourself, within those limits.
It's built for anything you bill more than once and usage-based billing where the amount changes each time.
What's available today
| Status | |
|---|---|
| Capitec | Available to approved merchants, in a limited rollout |
| Other methods | Not yet available |
Your customer needs to bank with a supported bank. If they don't, recurring payments aren't an option for them and you'll need to fall back to a standard payment each cycle.
How a recurring payment works
Setting it up, once:
- You send the customer to Ozow to set up the agreement.
- They authorise it with their bank, agreeing to the limits; how much you can take and how often.
- Ozow confirms the agreement is active.
Then, for each payment:
- You tell Ozow to collect, for an amount within the agreed limits.
- Ozow collects from the customer's account. They don't need to do anything.
- Ozow notifies your system of the outcome.
Enabling recurring payments
Recurring payments require explicit approval from Ozow. They aren't a self-service opt-in, and not every use case is authorised: approval depends on what you're billing for and how you're billing for it, not just on whether the rollout has reached your customers' bank.
Speak to your account manager before you scope any work, and don't build against recurring payments on the assumption you'll be approved.
You'll also need to be integrated for pay-insPayin 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. already. The agreement is set up through 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. to Ozow, so if you're using an embedded checkout you'll need a redirect flow for this part.
Things to know
The customer sets the limits, and they can change their mind. The agreement is between your customer and their bank, and they can cancel it there at any time without telling you. Build for that: a collection can fail because the agreement is gone, not because the money isn't there. Handle the two differently; one is worth retrying, the other needs you to ask the customer to set up a new agreement.
Payments outside the agreed limits will fail. If you need to collect more than the agreement allows, or more often, that's a new agreement rather than a bigger request.
This is not a debit order. It doesn't run on the debit order system and it doesn't behave like one. The customer authorises it directly with their bank and controls it from there.
A failed collection isn't necessarily a lost customer. Insufficient funds is the most common reason and it's usually temporary. Decide your retry policy up front, how many attempts, how far apart, and when you tell the customer.
Your customer's bank determines availability, not you. Check whether recurring payments are possible for a given customer before you offer them a subscription, rather than after.
Integrating recurring payments
The integration covers setting up the agreement, collecting payments against it, handling the webhooks, and managing or cancelling agreements.
Status handling: see Transaction and settlement statuses.
Last updated