Which payment methods should South African SMEs prioritise?

Introduction — the decision you actually need to make

Choosing a primary online payment rail changes who completes checkout, how quickly cash posts to your bank, how much reconciliation work finance does, and which POPIA obligations you must manage. Pick the single business outcome you need (maximise conversion, speed cash to the bank, or enable reliable recurring billing) and choose the primary rail to match it. For most South African SMEs in 2026 that practical primary stack is a local A2A / Instant EFT (pay‑by‑bank) as the default, with a card gateway kept as the fallback for subscriptions, refunds and international customers.

Executive summary — pick by priority

• Maximise checkout conversion: default to a local A2A / Instant EFT rail and display cards as a clear fallback. Local pay‑by‑bank options are familiar to many South African buyers and reduce visible friction and payment failures (see Ozow on A2A growth).
• Speed cash into the bank (lower DSO): choose an Instant EFT provider that offers fast settlement or same‑day payouts; verify payout cadence and cut‑offs before committing because provider payout rules materially change cash timing and accounting work (see Peach Payments payout guide).
• Reliable recurring billing (subscriptions/memberships): adopt a card gateway with tokenisation and recurring authorisation support. Cards remain the pragmatic choice for repeat charges, refunds and standardised dispute handling (behavioural priors and rails effects summarised in Stitch’s consumer payments report).
• Minimise headline fees: compare net vs gross settlement, per‑transaction bands, fixed monthly minimums and cross‑border surcharges; Instant EFT can be cheaper at scale but contractual terms vary — always review provider pricing and settlement examples.

How rails differ in practice

• Instant EFT / A2A (bank→bank): the customer authorises a payment in their banking app or a pay‑by‑bank flow; merchants receive high‑confidence payment notifications and some providers support near‑real‑time settlement. Integration requires webhook handling and invoice matching to avoid manual AR work (practical notes on reconciliation and webhook best practice are available from CentraPoint).
• Card networks (Visa, Mastercard, Amex): universal reach, tokenisation for recurring billing and standardised refund/chargeback flows. Cards generally cost more per transaction and expose the merchant to chargeback risk, but are superior for subscriptions and international buyers.
• Wallets & BNPL: optional additions. Wallets (Apple Pay / Google Pay) improve conversion on supported devices; BNPL can lift average order value but requires margin support and credit‑risk processes. Add them only when the unit economics are justified.

Fees, settlement and reconciliation — what to check now

Fees are only part of the story; settlement behaviour and reporting shape finance work and cash visibility.

• Fee structure: card processors typically charge percentage + fixed fee and may add 3DS or cross‑border surcharges. Instant EFT vendors may show lower percentages but include fixed fees or monthly minimums — compare full contracts and worked examples on provider pricing pages (example: Ozow pricing).
• Gross vs net settlement and cadence: some providers pay gross receipts and debit fees separately, others pay net amounts. Payout cadence varies (same‑day, next‑day, weekly) and cutoff times affect end‑of‑day cash posting — confirm cadence and file formats before integrating (see the Peach Payments payout guide for a concrete example).
• Reconciliation complexity: multiple payout batches, refunds crossing cut‑offs and net settlements increase manual work unless you automate webhook‑driven invoice matching. Include invoice IDs in checkout metadata, implement idempotent webhook handlers, and mark invoices “paid — awaiting settlement” until bank receipts arrive to reduce manual AR.

Vendor pros & cons (short, pragmatic comparison)

• Ozow (A2A/Instant EFT): strong local A2A coverage and merchant tools; good for conversion and local buyer preference — confirm their pricing and payout behaviours before committing (Ozow pricing and product notes).
• Peach Payments (gateway with detailed payout docs): clear payout cadence documentation and examples of gross/net settlements; useful when you prioritise predictable reconciliation flows (Peach Payments payout guide).
• Card gateways (various providers): best for recurring billing and refunds; expect higher per‑transaction costs and standard chargeback handling. Choose a gateway with PCI‑compliant token vaulting and robust dispute evidence flows.

A one‑hour decision framework you can run now

1. Choose a single dominant business outcome: maximise conversion, reduce DSO (get cash faster), or ensure reliable recurring billing.
2. Map outcome → primary rail:
   • Conversion → Instant EFT primary; card fallback.
   • Speed cash → Instant EFT with fast payout terms.
   • Recurring → Card gateway primary.
3. Check operational constraints: bank coverage, provider cut‑offs, DPA availability, refund handling and integration effort.
4. Shortlist 2–3 providers and plan a 4‑week A/B experiment to validate the choice.

Four‑week A/B experiment to validate the primary rail

Goal: measure checkout → paid conversion and net revenue per session when adding Instant EFT.

Experiment design

• Population: new visitors (to avoid returning‑customer bias).
• Variants: A = current checkout (card default); B = Instant EFT shown as primary option with bank logos and one‑click flow.
• Duration: 28 days (or until sample size met).
• Metrics: sessions, checkout starts, paid orders, payment success rate (by rail), refunds/chargebacks, average order value, net revenue per session (post‑fees). Use server‑side events or provider webhooks to record confirmed payments.

Sample hypothesis and size guidance

• Hypothesis example: “Defaulting to Instant EFT will increase checkout‑to‑paid conversion from 5.0% to 6.0% (a 20% relative lift).” For low baseline rates (3–6%), detecting small absolute lifts needs large samples; use an online sample‑size calculator and set expectations using regional priors (see Stitch’s consumer payments report for local behaviour benchmarks).

Integration & reconciliation checklist (non‑negotiables)

• Webhooks: implement payment.created / payment.succeeded / payment.failed / refund.created webhooks with idempotency keys, retries and an event replay strategy. Include invoice_id in checkout metadata so you can match events to invoices automatically.
• Settlement mapping: confirm gross vs net settlement, payout cadence, cut‑offs and report formats (CSV/JSON). Map provider transaction IDs to your invoice and bank statement lines; reconcile daily. See a practical payout example in the Peach Payments payout guide.
• Refunds & chargebacks: test end‑to‑end and confirm whether refunds debit your merchant account or use separate settlement flows. Understand chargeback windows and dispute evidence requirements.
• POPIA DPA: obtain a signed data processing agreement that specifies limited processing to your instructions, breach notification timelines, security measures (encryption, access controls, logging), and restrictions on onward transfers without merchant consent. The Information Regulator explains the controller/operator split and notification duties under POPIA (POPIA guidance).

Sample reconciliation journal mapping (example)

• Sale recorded when customer pays (invoice R1,000): mark invoice paid pending settlement.
• Settlement arrives net of fees (example: merchant receives R970, fees R30): accounting entries
  • When settlement posts: Debit Bank R970; Debit Payment Fees Expense R30; Credit Sales (or Accounts Receivable reversal) R1,000.
  • If provider reports gross then fees separately: Debit Bank R1,000; Credit Sales R1,000; later Debit Payment Fees Expense R30; Credit Bank R30.
    Using invoice IDs in provider metadata makes automated matching routine and keeps daily reconciliation simple.

POPIA and payment data — quick, non‑negotiable checks

Merchants are normally the “responsible party” under POPIA and gateways act as operators; that distinction fixes contractual and notification duties. Require a written DPA, confirm where data is stored and if cross‑border transfers occur, and map gateway incident timelines to your statutory breach‑notification plan (see the Information Regulator’s guidance at InfoRegulator — POPIA).

Common technical questions

KPIs and guardrails to watch

• Payment success rate by rail (track per‑rail and aim for the highest practical rate).
• Checkout‑to‑paid conversion (use experiment baseline).
• DSO: average days from invoice to cash posted (measure before and after any rail change).
• Reconciliation mismatch rate (unmatched transactions per 1,000).
• Refunds & chargebacks as a percentage of gross revenue.

Next steps

Pick the single dominant outcome (conversion, cash speed, or recurrence); shortlist 2–3 providers and confirm payout cadence, net vs gross settlement and DPA availability from their docs (e.g., see Ozow pricing and product notes and Peach Payments payout guide); run the 4‑week A/B experiment above with server‑side confirmation and webhook matching; implement invoice_id metadata, idempotent webhooks and a daily reconciliation job so AR doesn’t become a bottleneck.