Specs
Merchant Checklist specs
Setup notes and briefing numbers for Merchant Checklist.
Checkout checks before go-live
The Merchant Checklist specs page turns that preparation work into a more structured reference. It helps a team confirm ownership, required inputs, and operational checks before a payment option is introduced to customers.
The handover work happens before Instant EFT, PayShap, or DebiCheck appears at checkout. Record the payment rail, the person who owns reconciliation, the customer-facing wording, and the release rule for goods or access. Include cut-off times, refund handling, and what staff must capture when a payer phones from a branch queue or sends proof by email.
Add the first payment screen, the success message, and the exception route used when a reference does not match. Screenshots matter here because a merchant can have one set of wording on the website and another inside the bank or gateway flow. Keep the version used by support, finance, and operations in the same file so the checklist stays usable during a live query.
What the spec must capture
A useful Merchant Checklist spec names owners, evidence, and stop points. Set out who checks status, who can release an order, which bank reference counts as valid, and when a case moves from waiting to manual review. For DebiCheck, note mandate timing and dispute handling, not only the sign-up step.
Link Merchant Checklist specs to the relevant Playbooks note and any Signals entry before changing customer messaging. If stock, bookings, or account access depend on payment state, write down the exact status text that triggers release and the proof required when that status is missing. Use the contact form with a screenshot of the current checkout or payment instruction screen.
- Owner for each payment checkpoint
- Reference fields copied exactly as shown
- Current route for payment exceptions
Verification points before release
The checklist should reflect South African payment behaviour rather than a generic ecommerce template. PayShap may suit low-value, immediate customer payments, while Instant EFT often needs tighter wording around confirmation and release controls. Where teams work across Johannesburg, Durban, and Cape Town, note who handles after-hours issues and which office keeps the audit trail.
Load-shedding plans belong in the spec if verification, fulfilment, or support depends on power and connectivity. Put branch walk-ins, call-centre scripts, and courier cut-offs into the same document so staff do not improvise different rules under pressure. If customers pay from a banking app while standing at a counter, state what proof is helpful and what proof is not enough.
Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.
Evidence to gather first
Collect checkout captures, settlement reports, sample references, and the exact text shown to customers at each step. Note failed cases as well, especially duplicate references, delayed confirmations, and orders released before bank-side status was checked.
Keep this spec beside the operational note used by finance or support, then update both when a bank flow or gateway screen changes. The point is not a long document. It is a short reference that prevents mismatched wording, missed checks, and avoidable release mistakes.
What our Real-Time Payments customers say
Verified Google reviews