Specs
Settlement Window specs
Setup notes and briefing numbers for Settlement Window.
Settlement states before cut-off
Settlement Window specs lists the payment states and cut-off points teams should define before publishing internal notes. It helps finance, ops, and support talk about settlement in one clear way across Instant EFT and PayShap.
Set the exact handover points your team uses: customer paid, bank accepted, merchant notified, funds settled, goods released. Instant EFT and PayShap do not share the same evidence trail, so the spec should name which status counts for ops and which one only counts for support. Include the daily cut-off time, the timezone used in reports, and what happens when a payment lands just before month-end reconciliation.
Reference capture belongs at the top of the spec, not in a footnote. List the fields staff must verify on the first screen, including amount, payer reference, beneficiary name, and the bank status visible to the merchant. When disputes arise, that small block of detail is what lets finance trace a transaction without guessing from chat screenshots.
Outputs your team should define
A useful Settlement Window spec gives each team a fixed wording set for payment received, awaiting bank settlement, missed cut-off, and next-window processing. Add a release rule beside each state so warehouse, service desk, and finance are not working from different assumptions. Keep edge cases separate, especially reversed payments, duplicate references, and partial amounts.
Map Settlement Window to the related operational pages before anyone changes checkout copy or internal scripts. Link it to Playbooks for handling steps, Signals for status wording, and the contact form only when someone needs to share screenshots or bank message text. For stock dispatch or account activation, the spec should say exactly which bank-side result is acceptable on the day.
- Cut-off times by payment rail
- Accepted proof fields for finance
- Escalation route for missed windows
South African timing pressures to record
South African payment teams often juggle branch traffic, courier collections, supplier release times, and month-end bank reporting on the same day. A Settlement Window spec should therefore note public holidays, Saturday processing differences, and whether the bank statement date can differ from the customer payment date. Teams in Johannesburg, Durban, and Cape Town may share one process, but the evidence available at the counter is not always identical.
Load-shedding can interrupt status checks right when a payment is moving from customer action to bank confirmation, so write down the fallback proof your staff may rely on temporarily. PayShap may show a fast payer outcome while settlement reporting still follows the merchant's bank cycle. For Instant EFT, make room in the spec for provider messages, bank redirects, and the point where support must stop treating a screen as final proof.
Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.
Inputs needed for this spec
Send the payment method, current cut-off table, release rule, and two or three examples of problem transactions. Screens from the checkout, the merchant portal, and the finance report are more useful than a generic description.
Store the finished note next to the reconciliation checklist and any internal status wording used by support. When someone asks why an order waited, the answer should be visible in the defined window, the bank state, and the release rule on the same page.
What our Real-Time Payments customers say
Verified Google reviews