Resources
Spec Card
A grounded note on spec card in South African payments, for teams who need the fields, checks, and edge cases in plain language.
Fields that belong on a Spec Card
Spec Card lays out the fields, checks, and awkward edge cases that often sit behind a payment process. It is written for teams that need the details in plain language, not banking jargon.
A useful Spec Card starts with the payment rail, the exact trigger event, and the point where settlement is treated as usable. Then add the data your team must capture every time, such as account holder name, reference format, amount rules, and the evidence saved when a payer says the transfer is done. For South African teams, it also helps to note whether the flow depends on Instant EFT screens, PayShap alias entry, or a DebiCheck mandate accepted in the correct banking session.
Put the failure checks near the top, not buried at the end. A Spec Card should show what staff compare first: bank response, beneficiary match, duplicate reference risk, reversed proof of payment, and the step taken when funds are pending rather than settled. That single page often becomes the version finance, support, and operations use when recon starts to drift.
What the finished card includes
The finished note should read like an operating document, not a marketing summary. Include mandatory fields, optional fields, customer prompts, settlement status wording, exception handling, and the references that must appear in your ledger or order record. If a process changes between checkout, call centre, and walk-in counter, the Spec Card should show those differences plainly.
Link the Spec Card to the matching process pages before anyone changes checkout copy or internal scripts. Keep references to bank rules, risk checks, and handover conditions on the same note, and use the contact form if you need to point out a field your current setup cannot capture. Screenshots of the payment step, confirmation screen, and stored proof help when the path needs review.
- Mandatory fields listed in order
- Settlement state defined for release
- References used by finance and support
Checks South African teams keep missing
A South African Spec Card should reflect the way payment queries arrive in the real world. That means carding for branch-assisted payers, mobile banking screenshots, delayed bank notifications, surname mismatches, and payment references that are shortened by customer apps. Teams in Johannesburg, Durban, and Cape Town may use the same rail but still need different handling notes if dispatch, pickup, or counter release sits in the process.
Power cuts, patchy signal, and bank-side delays can change how proof is captured and when stock is released. PayShap may need alias checks, Instant EFT often needs stricter proof rules, and DebiCheck requires the mandate state to be recorded exactly as accepted, pending, or failed. Write those local conditions into the card so staff are not relying on memory during a queue or end-of-day recon.
Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.
Spec Card drafting prompts
Draft the Spec Card with the payment type, settlement behaviour, customer prompts, supported banks, and the exact references your team relies on.
Draft the note around one payment type at a time. Start with the customer action, map the internal checks, record the release rule, and finish with the exact references your accounting and support teams search later. When a process has an exception for high values or manual review, give it its own line instead of folding it into the standard flow.