Payment Status

Payment status is the stage a payment has reached at a given moment in its life, from the time the payer's instruction is received to the time the money is credited to the payee or the payment is rejected or returned. Banks, payment system operators and payment service providers report status so that the payer, the payee and each institution in the chain know whether a payment has been accepted, is waiting, has settled or has failed. Status is usually shown as a short code or label in messages, online banking screens and application programming interfaces.

In modern payment messaging, status reporting is formalised by ISO 20022, which defines payment status report messages and a standard list of status codes. Cross-border tracking services such as SWIFT gpi apply the same idea across a chain of banks. Payment status is related to, but different from, payment finality: a status reports where a payment stands, while finality is the legal point after which a settled payment cannot be unwound.

Ordering a meal through a delivery app gives you a series of updates: order received, being prepared, picked up, delivered. Each update tells you something useful, and if the restaurant cancels, you find out straight away rather than waiting hungry. Payment status works the same way for money. Each bank or system that handles a payment reports what it has done with it.

A payment might be "received" by the payer's bank, "accepted" after its checks, "pending" while it waits for funds or a compliance review, "settled" once banks have exchanged the money, and finally "credited" when it reaches the payee's account. If anything goes wrong, the status changes to "rejected" with a reason, so the sender can fix the problem and try again.

ISO 20022 defines two main status messages. The customer payment status report (pain.002) goes from a bank to a corporate or other customer that has sent payment instructions. The FI-to-FI payment status report (pacs.002) passes between banks and payment systems. Both carry a transaction status code from an external code list, often with a reason code explaining why. Commonly used codes include:

• RCVD (received). The instruction has arrived but has not yet been checked.
• ACTC (accepted technical validation). The message is correctly formatted and has passed technical payment message validation.
• PDNG (pending). Further checks or events are needed, for example a funds check, a sanctions review or the next settlement cycle.
• ACSP (accepted settlement in process). All checks are passed and the payment has been passed on for settlement.
• ACSC (accepted settlement completed). Settlement on the debtor side is complete.
• ACCC (accepted settlement completed, creditor account). The payee's account has been credited.
• RJCT (rejected). The payment will not be executed, with a reason code such as an invalid account or insufficient funds.

Not every scheme uses every code, and the implementation guide for each system specifies which apply. In instant payment schemes the status response is a core part of the flow, because the payer's bank must tell its customer within seconds whether the payment succeeded.

A cross-border payment may pass through several banks, each with its own systems. Before tracking services, a payer often had no view of a payment once it left the first bank, and finding out where it was meant a payment investigation. SWIFT gpi changed this by requiring participating banks to report status updates to a central tracker, keyed to the payment's unique end-to-end transaction reference (UETR). Any bank in the chain can then see whether the payment is in progress, credited to the beneficiary or rejected, along with charges deducted and the time taken at each step. These updates are often stored in a payment information repository for later reference.

Status labels describe events, not legal rights. A "settlement completed" status from a clearing system usually indicates that interbank settlement has happened and is final under the system's rules, but a status of "accepted" or "in process" carries no such guarantee. Even after settlement, the receiving bank can still send the money back, for example because the account is closed. A returned payment is a new payment in the opposite direction with its own status trail. Readers of status codes therefore need to know which point in the chain a code refers to: the payer's bank, the clearing system or the beneficiary bank.

• Customer experience. Clear status reduces enquiries and lets businesses release goods once they see a payment credited.
• Operations. Banks use status data to spot stuck payments, route items to a message repair queue and meet cut-off times.
• Cash management. Treasurers use status reports to forecast balances and confirm that critical payments have gone.
• Regulation. Rules in several jurisdictions require payment service providers to tell payers promptly when a payment is rejected and why, and instant payment rules such as the EU's Instant Payments Regulation depend on near-instant confirmation.

• ISO 20022
• Swift