Why Are Payment Statuses Asynchronous?

Many South African payment outcomes are not known at the moment you submit the transaction. A debit order submitted today may only show its final result days later, a DebiCheck mandate authentication may come back in about two minutes or by end of the next business day, and a batch file only produces its response files on the next processing cycle.

Systems that assume an instant yes-or-no answer break in production. Designing for asynchronous statuses from the start avoids duplicate collections, misleading customer messages and reconciliation gaps.

Why are payment outcomes delayed?

Different rails confirm at different speeds because of how clearing works:

• Debit order collections are processed in batch cycles. The instruction is accepted for processing first, and unpaids (insufficient funds, closed accounts, disputes) flow back over the following days. See unpaids, returns and resubmissions.
• DebiCheck mandate authentication depends on the customer. A real-time authentication may complete in about 120 seconds, while a delayed authentication gives the customer until end of the next business day to respond on their banking channel. See mandate authentication.
• Batch file submissions produce acknowledgement files and then response or unpaid files on a schedule, not per request.
• Card payments authorise in real time, but settlement, refunds and chargebacks arrive later.

What do interim statuses mean?

A well-designed status model distinguishes between interim and final states:

• Interim statuses such as submitted, accepted for processing, pending authentication or in progress mean the outcome is not yet known. The transaction may still succeed or fail.
• Final statuses such as successful, failed, rejected or disputed mean processing has concluded, although some final states (like a successful collection) can still be reversed later by an unpaid or dispute.

Treat an interim status as exactly that: do not release goods, mark invoices as paid or trigger downstream fulfilment on a pending state unless your business model accepts that risk. The general status model is covered in payment statuses and references.

How should your system handle asynchronous outcomes?

Store a status per instruction, not a single flag

Keep a status history for every payment instruction, with timestamps and the reason code for each change. This supports queries, disputes and reconciliation.

Consume updates from webhooks and files

Final outcomes arrive through webhooks and callbacks or through response and unpaid files. Build your processing around these updates rather than polling alone, and use polling or status queries as a safety net for missed events.

Design business logic around state transitions

• Only act on transitions you have defined, for example pending to successful, or successful to unpaid.
• Handle out-of-order delivery: an unpaid notification might arrive after you have already reconciled the collection as successful.
• Make handlers idempotent so a repeated notification does not double-process, as explained in idempotency and duplicates.

Set expectations with customers and staff

• Show customers a pending state honestly, with an indication of when the outcome will be known.
• Give operations teams a view of transactions that have been pending longer than expected, so stuck items are investigated rather than discovered at month end. See retries and stuck payments.

What time frames should you plan for?

Exact windows depend on the bank, stream and cut-off, so confirm them for your integration rather than hard-coding assumptions.

Back to the Payment Operations hub.