Payment Statuses and References Explained
A payment status tells you where a transaction currently sits in the payment lifecycle, and a payment reference tells you which transaction you are looking at. Together they are the tools you use to answer the two questions every business asks daily: has this customer paid, and which payment is this money for?
Statuses matter because most South African payment rails are asynchronous — the final outcome of a debit order, for example, is only known after the processing cycle completes, which can be a banking day or more after submission.
What do the common payment statuses mean?
Exact status names vary by provider and rail, but most map to these stages:
| Status | What it means | Is the money yours? |
|---|---|---|
| Pending / submitted | The payment has been created or sent for processing, with no outcome yet | No |
| Authenticated | The payer has been verified (for example a DebiCheck mandate approved via the bank) | No — this confirms authority, not payment |
| Authorised / approved | The payer's bank has approved the instruction | Not yet — funds still need to clear and settle |
| Paid / successful | The payment cleared and the funds are due to you | Effectively yes, subject to settlement timing |
| Settled | The funds have been paid over to you | Yes, though disputes remain possible on pull payments |
| Failed / declined | The payer's bank rejected the payment | No |
| Unpaid / returned | A debit order was processed but returned afterwards, for example due to insufficient funds | No — treat it like a failed collection |
| Disputed / reversed | The payer disputed the payment after the fact | Funds may be clawed back |
| Refunded | You returned the funds to the payer | No |
Two practical warnings:
- Authorised is not paid. The difference is explained in Authentication, Authorisation, Clearing and Settlement.
- A debit order can succeed and then be returned. Always process unpaid notifications, not just the initial submission response. See Unpaids, returns and resubmissions.
When a payment fails or is returned, the bank supplies a reason code describing why. Do not assume what a code means — check it against the rail's definitions, as covered in Error and reason codes.
What is a payment reference?
A payment reference is an identifier attached to a transaction so it can be tracked and matched. A single payment usually carries several:
- Your reference — the invoice number, contract number or customer reference you assign. This is what makes reconciliation possible.
- Provider reference — the unique ID Kwik assigns to each transaction, used when querying a payment.
- Bank statement reference — what the payer sees on their statement. For debit orders this includes the abbreviated short name identifying the collecting business, which must match the mandate.
- Interbank references — identifiers used between the banks and BankservAfrica, occasionally needed when tracing a missing payment.
How do references help with reconciliation?
Reconciliation is matching money received to the transactions that produced it. Good reference practice makes this nearly automatic:
- Use one unique reference per expected payment, and never reuse it.
- For manual EFT, give each customer their own reference, since you cannot control what payers type — see Proof of payment and reconciliation.
- Keep the statement descriptor recognisable so payers do not dispute payments they do not recognise.
- Store the provider reference against every transaction so queries and disputes can be traced quickly.
How should systems handle status changes?
Because outcomes arrive asynchronously, treat statuses as events rather than a single answer: record each change, act only on final states (paid, failed, unpaid, disputed), and design for the possibility that a "successful" pull payment is later returned. Webhooks and polling patterns for this are covered under Asynchronous payment statuses.
Related topics
Methods, Rails and Channels
Learn the difference between a payment method, the rail it runs on and the channel it is accepted through, with South African examples for each.
Cut-Off Times and Value Dates
Learn how bank cut-off times, banking days, non-banking days and value dates determine when a payment is processed and when funds actually reflect.