Specs
Instant Eft specs
Setup notes and briefing numbers for Instant Eft.
Instant EFT field map
The Instant EFT specs page narrows that overview into the fields, states, and process details an implementation team should confirm. It is useful when you need clearer definitions than the marketing term gives you.
Start with the transaction record, not the checkout label. For Instant EFT, the useful spec points are the payer reference, merchant reference, bank result code, timestamp, amount, and the status names your provider sends back after the customer leaves online banking. South African teams often need to line those fields up with an order ID, an invoice number, and a manual release check before stock, tickets, or account access move.
The first screen worth saving is the one that shows the payment reference exactly as submitted. Another important check is whether your system stores a customer-facing success message only, or the provider callback and bank-side outcome as separate events. That distinction matters when finance is reconciling a payment that looked successful at checkout but has not settled into the merchant account yet.
Checks before release
A workable Instant EFT spec lists the status points that trigger action by ops, finance, and support. One set of notes should cover pending, successful, failed, expired, reversed, and duplicate-attempt scenarios, with the exact evidence required before goods leave a warehouse or a service is activated. Teams also need the fallback wording used when a customer paid from a different bank account name than the order details show.
Link the spec to your checkout behaviour, refund handling, and exception queue before changing any customer messaging. Confirm which event is treated as final in your environment, then test the same payment journey with the reference formats you actually use in production. If you send questions through the contact form, include provider name and a screenshot of the status data visible to staff.
- Bank reference format and length
- Provider callback fields captured
- Duplicate payment handling rules
South African failure points
Instant EFT in South Africa sits inside ordinary banking behaviour, which means the spec must account for customer bank choice, mobile banking steps, and provider-specific status wording. A team in Johannesburg or Cape Town may process the same order volume very differently from a branch counter in a smaller town where staff still read back references and amounts to customers. Those operating differences belong in the note because they affect proof, timing, and who may override a hold.
Store traffic affects which Instant EFT proof a cashier can ask for without delaying the queue. During load-shedding, teams often rely on battery-backed tills and mobile data, so the spec should state where payment references are captured and who checks bank-side confirmation later. Dispatch cut-offs matter too, because an instruction marked paid in checkout is not the same as verified funds for release.
Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.
Implementation note pack
Send the current field list, sample status payloads, and the wording shown to customers at each payment stage. It also helps to note which provider handles your Instant EFT flow, whether staff can see raw references, and what proof finance accepts for manual review.
Keep the order flow, reconciliation steps, and refund procedure together. When a disputed payment lands in the queue, those three notes together usually show whether the issue came from customer input, provider messaging, or a release decision made too early.
What our Real-Time Payments customers say
Verified Google reviews