The transaction lifecycle

One purchase produces a string of separate events. Each has its own message, its own timing, and its own way of going wrong. Treating them as a single thing called "the payment" is what makes reconciliation hard and support calls circular.

The states

The operation you need depends on which state you are in, and using the wrong one costs money. Voiding and refunding look identical to the customer and are not remotely the same for you.

That diagram is a map of the rest of this section rather than something to absorb now. Each state is a page: approval is authorization, the claim is capture, the three ways back are voids, reversals, and refunds, the bank-to-bank movement is clearing and settlement, getting paid is funding, and the last two states belong to disputes.

Which operation, when

You want to	Before batch close	After batch close, before settlement	After settlement
Cancel the whole thing	Void	Void may still work, otherwise refund	Refund
Release an unused hold	Authorization reversal	Authorization reversal	Not applicable
Reduce the amount	Partial capture, or partial reversal	Partial refund	Partial refund
Return money after delivery	—	—	Refund

The cheapest and earliest option is nearly always the right one. A reversal costs almost nothing and gives the customer their money back at once. A refund is a fresh transaction with its own fees, its own settlement delay, and a customer waiting days. Voids, reversals, and refunds works through the choice in detail.

Sale, or auth then capture

There are two ways to run a card payment. The choice is about when you know you can deliver.

	Sale	Auth then capture
Messages	One	Two
Money claimed	Immediately	At capture
Suits	Card present, instant delivery	Goods shipped later, services rendered later
Risk	Charging before delivery	The authorization lapsing before you capture

Card schemes expect capture at delivery. Running a sale at checkout for furniture that ships in three weeks is trivially easy to build and leaves the customer paid-up and empty-handed for three weeks, which is a dispute waiting to be filed.

One caveat before you design around this. Splitting authorization from capture is a property of the rail, not a choice you always have: some debit products send a single message and fix the amount at approval. Cards sets out which is which.

What "the payment failed" can mean

The phrase covers at least five different events. Each has a different fix, so an incident conversation that does not distinguish them goes nowhere.

Declined at authorization. The issuer said no. Nothing was held, nothing to clean up.

Approved but never captured. Money was held and then quietly released. The customer saw a pending charge disappear; you saw an order that never funded. Capture covers why this is the most common silent failure.

Captured but rejected at clearing. A late or malformed clearing record. Uncommon, and it leaves the transaction stranded between "we think we are owed" and "no money is coming."

Settled but not funded. The money reached your processor and stopped. Usually a reserve, a funding hold, or a bank detail problem — all of which live in funding and disbursement.

Funded and later reversed. A chargeback or an ACH return, turning up long after everyone had moved on. See disputes and ACH; they are not the same thing and only one of them can be contested.

Being precise about which one you mean is most of the work in any payments incident.

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. See capture.
• Clearing — the exchange of records that decides who owes whom.
• Settlement — the movement of funds between issuer and acquirer.
• Funding — the processor paying you, which is a separate event from settlement.

The transaction lifecycle

0 of 4 answered

1. A customer cancels 10 minutes after checkout. The transaction was authorized but not captured. What is the correct operation?

   Authorization reversal.Void.Refund.Nothing; let the hold expire.
2. Why prefer the earliest applicable operation when undoing a payment?

   Earlier operations cost less and return the customer's money faster.Later operations require acquirer approval.Only reversals are reported to the network.Refunds are blocked once a batch has closed.
3. Why is running a single "sale" message risky for goods that ship three weeks later?

   The customer is charged three weeks before they receive anything, which invites disputes.The authorization will expire before the goods ship.Sale messages are not permitted for card-not-present transactions.The acquirer cannot batch a sale message.
4. Which of these describe genuinely different failure states? Select all that apply.

   Declined at authorization.Approved but never captured.Settled but not funded.Funded and later reversed by a chargeback.