Payfast Guide: South African Local Payment Methods and Instant EFT

Payfast Guide: South African Local Payment Methods and Instant EFT

South Africa is one of the few mature card-led markets in Africa, which leads many teams to a seemingly reasonable conclusion: connect international cards and you are done. Conversion data usually contradicts that conclusion. Local consumers use Instant EFT heavily: the buyer completes a transfer inside their own online banking and returns to the merchant site to confirm, never typing a card number. A checkout page that only accepts international cards shuts those buyers out.

Payfast is a South African local payment gateway covering cards, Instant EFT and some other local methods. Its value is bringing those rails into one collection chain. The difficulty is that confirmation works nothing like cards: Instant EFT confirmation depends on redirects and status queries rather than card-network notifications. This guide follows the order of an actual integration: positioning and boundaries, onboarding, settlement paths, integration shapes, method behaviour, fee composition and the misreadings that recur.

1. Positioning: A South African Local Gateway and an Instant EFT Entry

1.1 Card-Dominant Does Not Mean Card-Only

Reading South Africa as a card-led market is broadly correct: card acceptance is mature, buyers are comfortable paying online by card, and international cards work. But card-led describes a share structure, not the only method available. What actually drives conversion is whether the checkout page offers the methods buyers habitually use.

Instant EFT is the clearest example. The buyer does not type a card number; at checkout they are redirected to their own online banking, complete a transfer, and the gateway identifies it and returns the result. Acceptance is noticeably higher among buyers unwilling to enter card details on an unfamiliar site. It is also the more realistic option for buyers who hold a local bank account but have limited card facilities.

So the value of a local gateway is not simply one more option. It is placing cards and local instant transfer inside the same checkout flow so buyers can choose by habit. The engineering complexity created by that difference in mechanics is covered in section three.

1.2 What It Is Not

First, it is not a local entity. The local entity, tax registration and invoicing obligations that apply when you operate in South Africa do not disappear because you use a local gateway. For the wider structure see the Cross-Border Seller Entity and Account Structure Guide.

Second, it is not a solution covering all of Africa. Payment structures across the continent differ enormously: southern Africa leans on cards and local transfers, while some East and West African markets lean on mobile wallets. For the regional picture read the Africa Payment Guide, and for method differences see the Local Payment Methods by Region Guide.

Third, it is not a substitute for cross-border settlement. A local gateway solves collection. It does not solve how local currency reaches a usable account or how it is converted. That chain needs separate design, as section five explains.

2. Onboarding and Entity Requirements

2.1 What Onboarding Actually Looks At

Onboarding variables for local acquiring and gateways match mature markets: entity location, how explainable the business model is, how verifiable the website and product are, expected volume and category risk. South Africa is relatively mature, which means a more standardised process but also clearer expectations about material completeness.

The most underestimated item is still business explainability. The reviewer needs a page a third party can open, from which to judge what you sell, to whom, whether the refund policy is clear and whether the support channel really works. If the page is product images plus an order button, the number of rounds rises noticeably.

Another point is that delivery model and refund policy must agree. Digital goods, physical goods and subscription services have different transaction structures and accept different evidence. If the page says refunds are not supported while the terms describe a refund process, review asks for an explanation, and this kind of contradiction is one of the most common material faults.

2.2 Entity, Currency and Repatriation

This matters especially in African markets. The endpoint of local collection is not money arriving but money arriving in a currency, through a path, into an account you can use. South African settlement and repatriation paths differ from Europe and North America, so three things need confirming up front.

First, whether the settlement currency matches your reporting currency, and if not, at which step conversion happens and who bears it. Second, settlement cadence and minimum thresholds, per the current official description, without inferring from experience in other markets. Third, what the local currency is for: whether it can stay local to pay local suppliers or must be repatriated. These three decide your capital efficiency and whether you need an additional multi-currency arrangement. For currency path thinking see the Multi-Currency Payment Account Guide.

3. Integration Options and Account Structure

3.1 Checkout Shape and Redirect Confirmation

Local gateways usually offer two shapes: hosted checkout, which takes the buyer to a provider-maintained page, and an API integration, where you render method selection in your own page and handle state.

One specific feature of the South African market is that Instant EFT inherently involves a redirect and a return: the buyer is sent to online banking, completes the transfer and comes back to the merchant site. That return is not an incidental detail. It is part of the buyer experience and the starting point of the confirmation chain. Hosted checkout maintains the redirect logic for you and gets you live fast. An API integration lets you control the post-return page and guidance, but you handle lost returns, mid-flow closures and repeated returns yourself.

If cards and Instant EFT coexist in your flow, unify the user-visible states across both chains. A buyer should not see two entirely different progress patterns just because they picked a different method. This looks like a product detail but directly affects support ticket volume.

3.2 Server Side: Redirect, Status Query and Reconciliation

The server has to get three things right, and two of them differ from the usual card approach.

First, query status instead of waiting passively. The final result of an Instant EFT depends on the gateway identifying the transfer, so after the return you must actively query the transaction status and treat returned-but-unconfirmed as its own intermediate state rather than treating the return as success. For the full chain from initiation to final confirmation see Payment Transaction Flow Basics.

Second, idempotency. Returns can fire more than once, users can refresh a result page, and calls can be retried after timeouts. Both order creation and status updates need idempotency so one order never pays twice or ships twice.

Third, reconciliation. Gateway settlement reports must match your order records line by line, and Instant EFT matching fields differ from cards, usually relying on amount, reference and a time window. Fix the reconciliation rules before integration; for method see the Payment Reconciliation and Bill Operations Guide.

4. Core Capabilities and Market Coverage

4.1 Authorisation and Confirmation Mechanisms

For South Africa, the most useful step is to write the authorisation mechanism, confirmation mechanism and refund path of each method separately. The combination of those three decides your state machine, support scripts and finance process.

Cards authorise synchronously and confirm asynchronously: the authorisation result returns immediately, capture and settlement follow, and refunds return to source under card scheme rules. Instant EFT starts with an action the buyer takes inside online banking, confirms through gateway identification plus your status query, and may have a refund path that differs from cards. Other local methods vary and must be confirmed individually rather than forced into one template.

4.2 Authorisation, Confirmation and Refund Comparison

The way to use the table is to map it onto your own system and mark the states that have no design yet. The Instant EFT row is the easiest to miss: many teams build the redirect during development and skip the status query, then face tickets saying the buyer paid while the system says unpaid. For refund operations see the Payment Refund and Settlement Operations Guide.

5. Fee Structure and Real Cost

5.1 Fee Components

Local gateway fees are not one number but a set of components.

Current rates and conditions belong to the official quote and the signed contract. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.

5.2 Judging the Real Cost

Comparing headline rates is the easiest mistake at this stage. The right method is to build a transaction mix that matches your business: the same method share, the same order value bands and the same refund rate, then compare total cost and final received amount.

South Africa carries one easily missed dimension: cross-border and remittance cost. Local collection is only the first step, and funds travel further to reach your reporting account, so the cost and timing of that leg belong in the budget. Comparing only local processing fees usually produces a figure that is too low.

Another dimension is the effect of method coverage on conversion. Adding one local method may lift conversion noticeably, or it may only add another state to maintain. Comparing fees without conversion tends to produce a biased conclusion.

6. How It Divides Work With Other Options

6.1 Against Other African Options

Africa is not one payment structure. Markets dominated by mobile wallets need local wallet and telecom operator channels, which is nothing like the South African combination of cards and instant transfer. If your business covers both South Africa and East or West Africa, you usually need several options in parallel, or a provider with broader regional coverage plus a local gateway for the main market. Compare the market focus of Paystack and Flutterwave, and check aggregator method lists for Africa such as dLocal.

The logic is still cost structure: if South Africa is the main market, prioritise local depth; if it is one of several, prioritise organisational cost.

6.2 Against Global Acquiring Platforms

Global acquiring platforms offer mature interfaces, complete documentation and standardised multi-currency support, which suits teams with engineering capacity that want payment logic under their own control. The difference is local depth: for methods such as South African Instant EFT, global platforms usually depend on partner channels. The method list may be sufficient, but experience and success rate may not match a local gateway. When evaluating, compare the local method list and settlement structure of Adyen.

A pragmatic combination is to run main card volume on a global platform and local instant transfer through a local gateway. The cost is two reconciliation flows and two state machines, which needs extra engineering to abstract.

7. Who It Fits and Who It Does Not

7.1 Good Fit

First: teams where South Africa is a primary or important market and buyers are mostly local consumers. Local method coverage directly decides whether a sale completes.

Second: businesses with modest order values, high order frequency and buyers who hesitate to enter card details. Instant EFT measurably reduces abandonment for that group.

Third: teams willing to invest engineering in status queries and reconciliation. Treating instant transfer like a card guarantees rework.

Fourth: teams that also need to pay local suppliers or service providers. Keeping local currency local is often more efficient than repatriating everything.

7.2 Weak Fit

First: teams whose buyers are mostly abroad and where South Africa is only a supplementary market. The incremental gain from local methods may not cover integration cost.

Second: teams hoping one interface covers all of Africa. Internal differences are too large, so single-market options are more realistic.

Third: teams with no server-side engineering capacity that expect to go live by editing settings. Redirects and status queries require development work.

Fourth: teams treating compliance and repatriation outsourcing as the goal. Collection does not solve repatriation, as noted earlier.

8. Rollout Notes and Common Misreadings

8.1 Rollout Notes

8.2 Common Misreadings

The first misreading is treating South Africa as a pure card market and integrating cards only. Card acceptance is indeed mature, but local Instant EFT is widely used, and card-only checkout loses a share of orders that would otherwise complete. Card-led describes the share structure, not the only method.

The second misreading is treating Instant EFT as an ordinary bank transfer. An ordinary bank transfer is initiated by the buyer and manually verified by the merchant. Instant EFT completes a redirect and immediate confirmation through a gateway: the buyer pays inside online banking, returns to the merchant site, and the gateway identifies the payment and returns the result. The experience and the verification method are entirely different, and treating it as an ordinary transfer drags automation back to manual verification.

The third misreading is assuming a return means the payment succeeded. A return only means the buyer came back to your page, not that funds are confirmed. The real success state comes from the gateway status query, and there must be an intermediate state between the return and the confirmation.

If you are evaluating collection options for South Africa, use this guide as a checklist: confirm first how buyers actually pay, then confirm whether redirect, status query and refund paths for Instant EFT all have a design in your system, and finally confirm the repatriation path for local currency. For more regional selection thinking, continue from the Payment category page.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.