Built to bill on repeat
Not every gateway can run a subscription.
Accepting a card once is easy. Charging a saved customer automatically every month, recovering the failures and testing all of it in a sandbox first is a much smaller club, and recurring charges often price above the headline card rate.
Triage before price
Who can bill on repeat at all.
Grouped by each provider's own capability verdict, read from the same data as the matrix below. Comparing rates before capability is how subscription businesses end up on gateways that cannot bill them.
Subscription-ready
A first-party recurring product with tokenisation and a real sandbox: you can build, test and bill on repeat without a third-party billing engine.
Ready, behind a conversation
The capability exists, but pricing is quoted and access runs through sales or bank rails built for larger books. Right for enterprise billing, slow for a solo founder.
The capability matrix
Subscription capability, cited like a fee.
A capability verdict is treated exactly like a rate: each row cites the provider documentation it was read from, or says plainly that it was confirmed with the provider directly.
| Provider | Recurring | Tokenisation | Bank recurring | Sandbox | Webhooks | WooCommerce Subs | Verdict | Source |
|---|---|---|---|---|---|---|---|---|
 iKhokha | None | No | None | Yes | Yes | No | Not subscription-ready | iKhokha subscription capability We could not confirm this against a primary source. Checked this month, on 21 Jul 2026. developer.ikhokha.com |
 Ozow | None | No | Capitec Pay VRP | Yes | Yes | No | Not subscription-ready | Ozow subscription capability Read off the provider's own published pricing page. Checked this month, on 21 Jul 2026. hub.ozow.com |
 PayFast | Native API | Yes | None | Yes | Yes | Yes | Subscription-ready | PayFast subscription capability Read off the provider's own published pricing page. Checked this month, on 21 Jul 2026. developers.payfast.co.za |
 Paystack | Native API | Yes | None | Yes | Yes | No | Subscription-ready | Paystack subscription capability Read off the provider's own published pricing page. Checked this month, on 21 Jul 2026. paystack.com/docs/payments/subscriptions |
 PayU | Token-based only | Yes | None | No | No | No | Enterprise, quote-gated | PayU subscription capability We could not confirm this against a primary source. Checked this month, on 21 Jul 2026. corporate.payu.com/south-africa/en |
 Peach Payments | Native API | Yes | None | Yes | Yes | Yes | Subscription-ready | Peach Payments subscription capability Read off the provider's own published pricing page. Checked this month, on 21 Jul 2026. developer.peachpayments.com/docs/dashboard-recurring |
 Stitch | Native API | Yes | DebiCheck · Debit order · Capitec Pay VRP | Yes | Yes | No | Enterprise, quote-gated | Stitch subscription capability Read off the provider's own published pricing page. Checked this month, on 21 Jul 2026. docs.stitch.money |
 Yoco | None | No | None | Yes | Yes | No | Not subscription-ready | Yoco subscription capability From the provider's own domain, but a support article rather than its rate card. Checked this month, on 21 Jul 2026. developer.yoco.com |
Capability, not price: rates live on the compare table and in the calculator, computed by the shared fee engine. A "No" here is a product fact on the day it was checked, and providers ship; corrections jump the queue via the methodology page.
The recurring surcharge
Recurring often costs more than the headline.
Merchant-initiated and non-3DS charges can price above the advertised card rate, and tokenisation can carry its own monthly fee. Where a provider publishes the recurring rate, it is here.
| Provider | Headline card rate | Recurring rate | Source |
|---|---|---|---|
| Peach Payments | 2.95% | 3.50% + R1.50 | Peach Payments recurring rate Read off the provider's own published pricing page. Checked this month, on 20 Jul 2026. www.peachpayments.com/fees |
Rates ex VAT. A subscription business should model the recurring rate, not the headline rate; on the fee tables of the other providers the two coincide only because no separate recurring price is published.
The second rail
Bank-based recurring is the second rail.
Card-on-file is not the only way to bill a South African subscriber. Bank rails avoid card expiry churn, and the 2026 rule changes strengthen them.
How it works in 2026
- DebiCheck is the authenticated debit order: the customer approves the mandate once, and valid collections within its terms are not disputable.
- Capitec Pay VRP, live since December 2025, is the first variable-recurring-payments product in South Africa: the customer pre-approves a per-transaction limit and charges under it need no further authorisation.
- From 13 April 2026 dispute windows for EFT, Registered Mandate and DebiCheck collections are standardised at 60 days. Valid DebiCheck collections within mandate terms stay non-disputable, which is precisely what a subscription business wants.
- The trade-off is reach and effort: bank recurring suits larger-ticket, mandate-friendly billing more than a R99-a-month self-serve SaaS.
Who runs it
- Ozow: see its row in the matrix above for the exact mandate types it supports.
- Stitch: see its row in the matrix above for the exact mandate types it supports.
Selling past the border
The two-stack pattern.
The standard 2026 setup for a South African SaaS selling globally is two checkouts, split by customer country.
Domestic leg: a local gateway
- South African customers pay in rand through a local subscription-ready gateway. Local card rates, rand settlement in days, and the customer sees a checkout that reads local.
International leg: a merchant of record
- Foreign customers pay a merchant of record, which becomes the legal seller, files the VAT and sales tax of every jurisdiction, and absorbs chargeback liability. The fee is higher; the compliance burden it removes is the reason it exists.
The routing rule is one if-statement
- South African customer, local checkout; anyone else, the MoR checkout. Most teams key it on the customer country at signup.
The tax, exchange-control and settlement treatment of the international leg lives on the international page; this page owns only the domestic half.
Can your team build on it?
The developer experience, summarised.
Read from the same shared developer-experience data as the full matrix. The complete view, sandbox friction, SDKs, webhook signing, lives on the developers page.
| Provider | DX verdict | Sandbox | Full view |
|---|---|---|---|
| iKhokha | Gated | Gated | Developer matrix → |
| Ozow | Solid | Self-serve | Developer matrix → |
| PayFast | Solid | Self-serve | Developer matrix → |
| Paystack | Developer-first | Self-serve | Developer matrix → |
| PayU | Gated | None | Developer matrix → |
| Peach Payments | Developer-first | Self-serve | Developer matrix → |
| Stitch | Developer-first | Self-serve | Developer matrix → |
| Yoco | Developer-first | Self-serve | Developer matrix → |
Five things that sink subscription builds
Things everyone gets wrong.
Any gateway can do subscriptions if it takes cards.
No. Charging a saved card automatically every month is a different capability from accepting a card once: it needs tokenisation, merchant-initiated transaction support, a recurring API or product, and webhooks for the lifecycle. Several South African gateways accept cards perfectly well and offer none of that, which is exactly what the capability matrix on this page records.
The headline card rate is what a subscription costs.
Often not. Recurring and non-3DS card charges can price above the headline 3DS rate, and tokenisation can carry its own monthly fee. A subscription business should model the recurring rate its provider actually publishes for merchant-initiated charges, not the rate on the homepage banner.
Direct debit is old technology that subscribers dispute at will.
DebiCheck changed that. The mandate is authenticated by the customer up front, and a valid collection inside its terms is not disputable, a protection card payments do not offer. The April 2026 standardisation of dispute windows leaves that DebiCheck property intact, which is why bank-based recurring is gaining ground for South African subscription billing.
A merchant of record is just an expensive gateway.
It is a different legal arrangement. The MoR is the seller of record: it bills the customer, files VAT and sales tax in every jurisdiction where the customer sits, and carries chargeback liability. Its roughly five percent take replaces a compliance burden that would otherwise be yours in dozens of tax systems. Compare it on total cost of ownership against registering for VAT abroad, not against a local gateway's card rate.
You must pick one provider for everything.
The prevailing pattern is the opposite: a local gateway for rand subscriptions and a merchant of record for the world, routed by customer country. The two never see each other, and each does the half it is actually good at.
The nuance a table cell cannot carry
Provider notes.
The caveats behind the matrix, one per provider. The capability facts stay in the matrix; these are the behavioural details that decide builds.
iKhokha One-off card and EFT payments for SMEs. No native recurring product, and its API recurring support is unconfirmed; nothing here should be built on it for subscriptions today.
Ozow Pay-by-bank is customer-initiated by design, so it cannot charge anyone unattended. Superb as the cheap EFT method beside a recurring-capable gateway; not a subscription engine.
PayFast Two recurring modes, a fixed-schedule subscription and a tokenised ad-hoc charge, plus the strongest WooCommerce Subscriptions integration in the market and a sandbox where the whole lifecycle can be exercised.
Paystack The cleanest developer path to card subscriptions, with one behavioural caveat: the customer must complete a first transaction before recurring charges can bind, and there is no native proration or pause, so teams with complex plan logic add a billing layer such as Chargebee on top.
PayU Asserts tokenised subscription support on its corporate pages, but everything runs through sales and nothing about the South African recurring stack is publicly verifiable. Treat the sales conversation as the only source of terms.
Peach Payments The most complete local recurring product: a formal recurring API, a card vault, and dashboard management. Model the recurring rate, not the headline rate, and confirm the current tokenisation and plan fees on its own fees page before committing.
Stitch The bank-rails specialist: DebiCheck, debit order and Capitec Pay VRP with automated fallback between methods. Built for enterprise-scale mandates and collections rather than self-serve SaaS signup.
Yoco A clean one-off card gateway with no recurring product at all. If subscriptions matter, this is the wrong provider, full stop; its own documentation says as much.
Now price the ones that can
Capability first, then cost. Run your basket, volume and refund rate through the calculator to rank the subscription-ready gateways by what actually reaches your account.