Built to build on
Which payment API is actually good to build on.
The only page on this site written for the person doing the integration: sandbox friction, SDK reality, checkout models and webhook signing, compared across every gateway and cited to each provider's own documentation.
The developer's triage
Where each gateway lands.
Grouped by each provider's own developer-experience verdict, read from the same data as the matrix below.
Developer-first
An instant self-serve sandbox, modern docs and sane auth: you can hit the API in five minutes without talking to anyone.
Solid
A dependable integration with a real test environment, carrying some legacy shape: form posts, fragmented docs or an auth scheme with history.
SnapScan and Zapper expose merchant and query APIs rather than full card-acquiring APIs, and DPO PayGate sits behind bank onboarding. They are deliberately not rows in this matrix: it compares APIs you can build a checkout on.
The developer-experience matrix
The API surface, cited like a fee.
An SDK or sandbox claim is evidence, not opinion: docs signals are artefacts you can check exist, SDK tiers are marked official or community, and every row cites the documentation it was read from.
| Provider | API | Auth | Sandbox | JS / Node SDK | React Native | Checkout | Webhooks and signing | Docs signals | Verdict | Source |
|---|---|---|---|---|---|---|---|---|---|---|
 iKhokha | REST | App ID and API key with an HMAC sign secret | Gated | None | None | Hosted redirect | Signed callback payload | None found | Gated | iKhokha developer experience We could not confirm this against a primary source. Checked this month, on 20 Jul 2026. developer.ikhokha.com |
 Ozow | REST | API key plus private key with a SHA512 request hash, migrating to JWS | Self-serve | None | None | Hosted redirect · QR | SHA512 hash of the notification payload | None found | Solid | Ozow developer experience Read off the provider's own published pricing page. Checked this month, on 23 Jul 2026. hub.ozow.com |
 PayFast | REST + form post | Merchant ID and key with an MD5 signature salted by a passphrase | Self-serve | Community | None | Hosted redirect · Popup / inline | ITN signature plus a server-side confirmation call | None found | Solid | PayFast developer experience Read off the provider's own published pricing page. Checked this month, on 23 Jul 2026. developers.payfast.co.za |
 Paystack | REST | Secret key as a Bearer token | Self-serve | Official · TS | Community | Popup / inline · Hosted redirect · Embedded | HMAC-SHA512 of the payload in x-paystack-signature | Postman | Developer-first | Paystack developer experience Read off the provider's own published pricing page. Checked this month, on 20 Jul 2026. paystack.com/docs |
 PayU | REST + SOAP | Not published for South Africa | None | None | None | Hosted redirect | None | None found | Gated | PayU developer experience We could not confirm this against a primary source. Checked this month, on 23 Jul 2026. corporate.payu.com/south-africa/en |
 Peach Payments | REST | OAuth client token for Checkout, entity ID with user and password for the Payments API | Self-serve | Official | None | Hosted redirect · Embedded · Headless | Yes, unsigned | Postman · Playground · llms.txt · Changelog | Developer-first | Peach Payments developer experience Read off the provider's own published pricing page. Checked this month, on 20 Jul 2026. developer.peachpayments.com |
 Stitch | GraphQL | OAuth2, a client token for payments and a user token for bank data | Self-serve | Community · TS | None | Hosted redirect · Headless | Svix-signed, HMAC-SHA256 in X-Stitch-Signature | Playground | Developer-first | Stitch developer experience Read off the provider's own published pricing page. Checked this month, on 20 Jul 2026. docs.stitch.money |
 Yoco | REST | Secret key as a Bearer token, OAuth 2.0 for partner apps | Self-serve | None | None | Hosted redirect · Popup / inline | Standard Webhooks, HMAC-SHA256 with a whsec_ secret | None found | Developer-first | Yoco developer experience Read off the provider's own published pricing page. Checked this month, on 20 Jul 2026. developer.yoco.com |
Official against community SDK status shifts between releases, which is exactly why each row carries its verified date. No South African gateway ships an official online React Native SDK; the native SDKs that exist target card machines. Corrections jump the queue via the methodology page.
Test before you sign
Sandbox and testing, in detail.
Sandbox friction is the highest-value comparison axis there is: it decides whether integration starts today or after an onboarding cycle.
| Provider | Sandbox | Self-serve | Test cards | Access |
|---|---|---|---|---|
| iKhokha | Yes | Gated | Not confirmed | developer.ikhokha.com |
| Ozow | Yes | Yes, instant | Not confirmed | hub.ozow.com |
| PayFast | Yes | Yes, instant | Not confirmed | sandbox.payfast.co.za |
| Paystack | Yes | Yes, instant | Yes | paystack.com/docs/payments/test-payments |
| PayU | None found | n/a | n/a | Not published |
| Peach Payments | Yes | Yes, instant | Yes | sandbox-dashboard.peachpayments.com |
| Stitch | Yes | Yes, instant | Not confirmed | ide.stitch.money |
| Yoco | Yes | Yes, instant | Yes | developer.yoco.com |
SDKs, honestly marked
The JavaScript reality.
Official SDK coverage is thinner than the marketing suggests, and the matrix marks official against community precisely because the difference is maintenance risk you inherit.
What the matrix means by official
- No South African gateway ships an official online React Native SDK. Native SDKs that do exist target card machines, not online payments. For first-party mobile online payments the realistic routes run through the cross-border providers below.
- Community packages are often good, and often one maintainer deep. Pin versions, read the source of anything handling card data, and treat an unmaintained wrapper as a fork you now own.
- A hosted or redirect checkout needs no SDK at all, which is the honest default when the official support is not there: less surface, smaller PCI scope, one less dependency to audit.
Official server SDKs today
- iKhokha: Node none, PHP community.
- Ozow: Node none, PHP community.
- PayFast: Node community, PHP official.
- Paystack: Node official, PHP official.
- Peach Payments: Node official, PHP community.
- Stitch: Node community, PHP none.
- Yoco: Node none, PHP official.
The production detail
Webhooks: the production detail that decides everything.
Verify every payment from a signed webhook with idempotent handling, never from the redirect or success URL. The signing schemes below come from each provider's own row in the matrix.
Getting it right
- Verify the signature server-side on the raw body before parsing, and reject anything unsigned or stale.
- Handle retries idempotently: a delivery that arrives twice, out of order, or after a timeout must not double-credit an order. Key on the payment reference, not the delivery.
- Where a provider offers a confirmation call as well as a signature, do both. On a bank rail there is no chargeback to reverse a mistake.
- Return the expected success status quickly and do the work asynchronously; several providers time out slow endpoints and re-deliver.
Signing schemes, per provider
- iKhokha: Signed callback payload.
- Ozow: SHA512 hash of the notification payload.
- PayFast: ITN signature plus a server-side confirmation call.
- Paystack: HMAC-SHA512 of the payload in x-paystack-signature.
- Peach Payments: webhooks without a documented signature; confirm and add a server-side lookup.
- Stitch: Svix-signed, HMAC-SHA256 in X-Stitch-Signature.
- Yoco: Standard Webhooks, HMAC-SHA256 with a whsec_ secret.
Beyond the register
Building for the world.
When the buyer is not South African, the local matrix stops being the constraint and the cross-border stacks take over. The tax, exchange-control and settlement treatment of these routes lives on the international page; this is only their API surface.
Flutterwave
- The strongest cross-border option that still onboards a South African entity, with official Node, React and React Native SDKs and a dedicated sandbox. The one first-party React Native path available to an SA-registered business.
Stripe, via a foreign entity
- The best developer experience in the industry, and unavailable to an SA-registered business directly. A UK Ltd or US LLC unlocks it at the cost of exchange-control and tax consequences that need professional advice, not a blog post.
Merchant-of-record SDKs
- Paddle, Lemon Squeezy, FastSpring and kin ship overlay and hosted checkouts behind small JS SDKs. You trade per-method control for the MoR handling global tax and chargebacks; for most SaaS the trade is the point.
Exchange control, tax and settlement for these routes live on the international page; this page covers only their API surface.
Recommendations by stack
Start here for your stack.
Fit first, then price: the matrix narrows the field, the calculator ranks what remains.
JS or React web app, domestic
- Start with a developer-first gateway with an inline or popup checkout, and get webhook signature verification working on day one. Add a pay-by-bank rail as the second method once cards flow.
WooCommerce or platform store
- Choose on plugin depth rather than raw API quality: the gateway with the first-class plugin for your platform beats a prettier API you will never call directly.
React Native app
- No SA gateway offers a first-party online RN SDK, so either wrap a hosted checkout in a web view, or take the cross-border route with an official RN library and accept its settlement model.
Marketplace or platform splitting payments
- Split and multi-split support via API is rare locally; the matrix's split column is the shortlist. Everything else means building the ledger yourself on top of payouts.
Enterprise bank-rail billing
- GraphQL, mandates and variable recurring payments point at the bank-rails specialist tier; expect a sales conversation and per-bank test credentials rather than an instant key.
Five things that sink integrations
Things everyone gets wrong.
Every gateway has a sandbox; you can always test first.
Sandbox access is the single widest gap between providers. Some publish shared test keys you can hit in minutes; others gate the test environment behind sales or bank onboarding measured in weeks. The sandbox column in the matrix is the honest availability picture, and if instant testing is a hard requirement it is a shortlist by itself.
The success redirect confirms the payment.
It confirms only that a browser came back. Redirects are forged, replayed, and abandoned mid-flight. The payment is confirmed by the signed webhook, verified server-side and handled idempotently, and every provider in the matrix that signs its webhooks documents exactly how. Trusting the redirect is the most common integration bug in local payments.
A community SDK is as good as an official one.
Sometimes better, until its one maintainer moves on. The distinction the matrix draws is not quality but accountability: an official SDK ships with the provider's API changes, a community one follows when someone volunteers. If you build card handling on a community package, pin it, read it, and budget to fork it.
Stripe works from South Africa if you try hard enough.
Stripe does not onboard South African-registered businesses, and no configuration changes that. The routes that exist are its local subsidiary for rand, a foreign entity running Stripe directly, or a merchant of record. The second engages SARB exchange control and SARS residency rules, which is a professional-advice decision, not an integration detail.
GraphQL or REST is the decision that matters.
It is mostly taste. The decisions that actually cost or save weeks are sandbox friction, webhook signing, SDK accountability and checkout model, which is why those are the matrix columns. A well-documented form post beats an elegant API you cannot test.
The API fits. Now price it.
A good developer experience does not make a gateway cheap. Run your numbers through the calculator to see what each shortlisted API actually costs per R100.