"Just use Stripe" works in California. In South Africa, customers want to pay with EFT, your client list will eventually ask why their Capitec card failed at the 3DS step, and your accountant will have an opinion about USD settlement. We've shipped both PayFast and Stripe in production SA SaaS. Here's the comparison from someone with skin in the game.
Settlement currency and bank account
PayFast settles in ZAR to a South African bank. No FX cost, no Stripe Atlas, no Wise account. For a SaaS where 80%+ of revenue is in ZAR, this is significant — you're saving 1.5–3% on FX spreads and avoiding cross-border banking friction.
Stripe settles in the merchant's chosen currency. To take ZAR card payments and settle to a SA bank, you typically go through Stripe Atlas (a Delaware C-corp) and convert to ZAR via Wise or your forex bank. The aggregate cost depends on volume but tends to be in the 1.5–2.5% range on top of Stripe's transaction fees.
Recurring billing and subscription state
This is the gap that decides most projects. Stripe Subscriptions is a full state machine — proration, mid-cycle upgrades, dunning with Smart Retries, automatic invoice generation. You wire it up and it just works.
PayFast supports tokenized recurring billing, but the subscription state machine is yours to build. There's no Smart Retries, no first-class proration, no dunning UI. We've built this twice and it's three to six engineer-weeks of work that you simply don't have to do on Stripe.
3D Secure and fraud realities
PayFast mandates 3DS on most card transactions and the experience varies by issuer. Capitec especially has a high friction rate at 3DS handoff. We've seen conversion drop 12–18% relative to a no-3DS baseline.
Stripe Radar gives you tunable fraud detection, an explicit 3DS engine you can configure (with exemptions for low-risk transactions), and the ability to A/B test friction levels. For B2C high-volume merchants this matters a lot. For B2B subscription SaaS where the buyer is paying with a corporate card and is highly motivated, it matters less.
Developer experience and webhooks
Stripe's API is the gold standard. Webhooks are signed, idempotency keys are first-class, the test mode is functionally complete, and the docs are accurate. We can integrate Stripe in a day; we can build a recurring subscription with dunning in two more.
PayFast's ITN (Instant Transaction Notification) is webhooks done in 2008. You receive form-encoded POST data with no native signature — verification is a re-call to PayFast's pingback endpoint. Idempotency you build yourself. The sandbox is functional but slower and less complete than Stripe's. Plan for double the integration time.
The decision matrix
ZAR-only B2B SaaS, low-volume, sticker-price under R5,000/month: PayFast still works. The dunning burden is bearable, the FX savings matter, and the local trust signal helps.
Mixed-currency or international from day one: Stripe via Atlas. The integration speed alone pays for the FX cost.
B2C high-volume in ZAR: Stripe + Atlas, or both — Stripe for cards and PayFast for EFT specifically. Run them through the same internal billing layer.
FSCA-regulated or POPIA-sensitive: both work, but ask the auditor before you pick. We've seen both pass; we've seen specific deal structures push one or the other off the table.
We default to Stripe + Atlas now unless the client has a hard ZAR-bank-account requirement or runs strictly in the local market with low-volume B2B subscriptions. The price of Stripe Subscriptions stops looking expensive once you've burned a quarter building the dunning state machine yourself.
PayFast still has a real place — local trust, ZAR settlement, no FX costs, tighter payments-data localisation if you care about that. It's not the wrong answer; it's the answer for a specific kind of project, and the matrix above is the one we use to decide.
