# Recurring payments

> Charge a customer repeatedly after a single authorisation.

Source: https://hub.ozow.com/payment-products/recurring-payments/

> ⚠️ **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:**

1. You send the customer to Ozow to set up the agreement.
2. They authorise it with their bank, agreeing to the limits; how much you can take and how often.
3. Ozow confirms the agreement is active.

**Then, for each payment:**

1. You tell Ozow to collect, for an amount within the agreed limits.
2. Ozow collects from the customer's account. They don't need to do anything.
3. 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-ins already. The agreement is set up through a redirect 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.

→ [Set up recurring payments](https://hub.ozow.com/integration-methods/apis/recurring-payments/set-up-recurring-payments.md)

**Status handling**: see [Transaction and settlement statuses](https://hub.ozow.com/integration-methods/statuses.md).