The transaction lifecycle
In card processing, a single consumer purchase is not an atomic event. It is a sequence of discrete, asynchronous state transitions spanning multiple independent financial institutions. Each transition generates its own cryptographic message, follows its own settlement schedule, and exposes distinct operational failure modes.
Much of the confusion in payment operations—and the majority of stalled customer support inquiries—stems from treating the entire sequence as a monolithic event labeled "the payment."
Lifecycle state machine
The specific operation required to modify or cancel a transaction depends entirely on which state the payment currently occupies:
- Releasing an uncaptured hold requires an authorization reversal.
- Canceling a captured transaction before the day's batch is transmitted to the card network is executed via a void.
- Returning capital after interbank settlement has occurred requires issuing a formal refund.
While voids and refunds appear similar to consumers on digital banking statements (both resulting in the removal of the charge), their underlying mechanics, processing fee liabilities, and settlement timings are completely different.
Operational action matrix
| Desired business outcome | Before batch close (open batch) | After batch close, before settlement | Following interbank settlement |
|---|---|---|---|
| Cancel transaction entirely | Issue an immediate void | Void if supported by processor; otherwise refund | Issue a formal refund |
| Release unneeded hold amount | Issue an authorization reversal | Authorization reversal | Not applicable; funds already settled |
| Reduce captured charge | Execute a partial capture | Issue a partial refund | Issue a partial refund |
| Return customer funds post-delivery | Not applicable; goods not yet delivered | Not applicable | Issue a partial or full refund |
Always prioritize the earliest possible cancellation mechanism:
- An authorization reversal releases reserved funds immediately at negligible cost.
- A void prevents the transaction from entering interbank clearing, eliminating interchange expenses.
- In contrast, a refund constitutes an entirely separate transaction that incurs additional processing fees, ties up working capital, and takes several banking days to credit the consumer's account.
Single-message sale versus dual-message auth-and-capture
Card processing operates under two primary transaction architectures:
| Architectural dimension | Single-Message Sale | Dual-Message (Auth then Capture) |
|---|---|---|
| Protocol message count | Single message combining authorization and clearing | Two distinct messages: real-time authorization followed by later capture |
| Financial claim timing | Claimed and committed immediately upon approval | Claimed explicitly when capture message is dispatched |
| Best suited for | Immediate physical retail (card-present), digital downloads | Physical e-commerce shipping, car rentals, lodging, professional services |
| Primary operational risk | Charging consumers prior to order fulfillment | Authorization hold expiring before fulfillment occurs |
Under scheme regulations from Visa and Mastercard, merchants accepting payments for physical merchandise delivered at a future date are expected to separate authorization from capture. Running an immediate sale for custom furniture that ships three weeks later charges the cardholder long before fulfillment, dramatically elevating the risk of consumer disputes.
Certain payment rails and pin-debit networks operate exclusively in single-message mode, requiring transactions to be authorized and settled in a single atomic step.
Categorizing payment failure modes
When an engineering or support incident reports that "the payment failed," the issue typically falls into one of five distinct operational categories:
- Declined during real-time authorization: The issuing bank rejected the transaction during the initial authorization check. No funds were held, and no subsequent cleanup is required.
- Authorized but uncaptured: The issuer approved the hold, but the merchant never submitted a capture request. The authorization hold eventually expired and dropped off the cardholder's statement without transferring funds, leaving the order unfulfilled and unfunded.
- Captured but rejected during clearing: The merchant captured the transaction, but the clearing record contained data formatting errors or was transmitted past scheme presentment deadlines, stranding the funds between the merchant and the network.
- Settled interbank but withheld from merchant funding: The card network successfully transferred settlement funds from the issuer to the acquiring bank, but the acquirer placed a compliance hold or reserve on the merchant's payout balance.
- Funded and subsequently charged back: Funds settled into the merchant's commercial bank account, but the cardholder later initiated a formal dispute, resulting in an automated clawback of capital months after the original transaction.
Identifying which of these five states a transaction occupies is the essential first step in resolving any payment processing failure.
Terms introduced
- Sale: a single message that authorizes and captures at once.
- Batch close: the daily cut-off at which captured transactions go for clearing.