What Is Instant EFT and Open Banking?
Instant EFT and open banking are both ways for a customer to pay a merchant directly from their bank account during checkout, without using a card. The customer selects "pay by bank", authenticates with their own bank, and the merchant receives near-immediate confirmation that the payment has been made.
The two terms describe different generations of the same idea. Instant EFT services grew up before South African banks offered payment APIs, so they worked by guiding the customer through their internet banking inside the checkout flow. Open banking replaces that approach with bank-supported APIs, and the industry — with the South African Reserve Bank's (SARB) support — is moving toward a regulated open banking framework.
How Does Instant EFT Work?
A traditional instant EFT service works like this:
- The customer chooses instant EFT at checkout and selects their bank.
- The customer enters their internet banking credentials into the service's interface.
- The service initiates an EFT from the customer's account with the payment details pre-filled.
- The customer approves the payment, often with their bank's usual verification step.
- The merchant receives confirmation and can release goods or services immediately, even though interbank settlement follows later.
This model has a screen-scraping heritage: the service effectively logs into the customer's internet banking on their behalf. It solved a real problem — merchants no longer had to wait days for a manual EFT and proof of payment — but it requires customers to share banking credentials with a third party, which banks have long cautioned against.
How Is Open Banking Different?
Open banking, sometimes called pay-by-bank or API-based payment initiation, achieves the same outcome through official channels:
- The payment is initiated through APIs provided or sanctioned by the bank.
- The customer authenticates directly with their bank, typically in the banking app, and never shares credentials with a third party.
- Consent is explicit, scoped to the specific payment, and visible to the bank.
| Aspect | Instant EFT (screen-scraping) | Open banking (API-based) |
|---|---|---|
| Credential sharing | Customer enters bank login into a third-party screen | Customer authenticates with their own bank |
| Bank involvement | Bank often unaware a third party is in the flow | Bank participates via APIs |
| Consent model | Implied by completing the flow | Explicit, per-payment consent |
| Regulatory direction | Being phased toward regulated models | Aligned with where SARB and industry are heading |
Where Does PayShap Request to Pay Fit In?
PayShap Request to Pay is a bank-native alternative for collecting account-to-account payments. Instead of the customer pushing a payment from checkout, the merchant sends a payment request to the customer's bank, and the customer approves it in their banking app. It delivers a similar "pay from my bank account" experience over the PayShap instant rail, without any credential sharing.
See What Is PayShap? and What Are ShapIDs and Request to Pay? for how these work.
Why Offer Pay-by-Bank at Checkout?
- Reaches customers without cards or who prefer not to use them online.
- Near-immediate confirmation, unlike traditional EFT where merchants wait for proof of payment.
- No card data in the flow, which reduces card fraud exposure.
- Push payments are hard to dispute, since the customer actively authorises each one — there is no chargeback mechanism equivalent to cards.
The main trade-offs are checkout friction (the customer must authenticate with their bank) and the fact that refunds must be processed as separate payouts rather than reversals.
What Should Merchants Consider?
- Prefer API-based or bank-native options (open banking, PayShap Request to Pay) over credential-sharing flows where available.
- Confirm how quickly confirmed payments settle to your account and how references are carried for reconciliation.
- Plan a refund process, since account-to-account payments cannot simply be voided.
- Treat pay-by-bank as one option in a broader mix — see How Do You Choose Payment Methods?.
Tips
- Label the option clearly at checkout so customers know they will authenticate with their bank.
- Show supported banks upfront to avoid abandoned payments.
- Reconcile using the payment reference rather than waiting for proof-of-payment emails.
- Watch industry developments: as regulated open banking matures in South Africa, API-based options will continue to displace screen-scraping.
Related Topics
QR Plus
How interoperable QR Plus payments let customers scan one merchant QR code with any participating banking or wallet app in South Africa.
Buy Now, Pay Later
How buy now, pay later splits purchases into interest-free instalments, who carries the credit risk, and what BNPL costs merchants in South Africa.