Transaction Lifecycle
The transaction lifecycle is the sequence of states a card payment passes through from the moment a customer pays until the money is final: authorisation (approval and hold), capture (the merchant takes it), clearing (the record is exchanged), settlement (the money moves between banks), payout (the merchant is paid), and the after-life of refunds, reversals and chargebacks. Each state has an owner, a reference and a date.
- Also known as
- Payment lifecycle, Card transaction flow, Payment states
- Used at
- every card payment; the model behind every PSP's status field ("authorised", "captured", "settled", "refunded", "disputed"), every reconciliation, and every conversation between a merchant's finance team and its acquirer
- Binding
- the schemes' rules define each state and its timing — authorisation validity, capture windows, clearing cut-offs, settlement cycles, dispute windows (120 days from the transaction for most reason codes, and longer in some cases)
- Typical timeline
- authorisation in a second; capture within hours or days; clearing the night of capture; interbank settlement the next business day; merchant payout on the contractual cycle (T+1 to T+7); chargebacks possible for four months or more; the whole life closed only when the window shuts
- Typical references
- the authorisation code and retrieval reference number at authorisation; the acquirer reference number at clearing; the PSP's own ID throughout; the payout batch ID at settlement to the merchant
- Parties
- the cardholder, the merchant, the PSP or gateway, the acquirer, the network, the issuer, and — after the fact — the dispute teams on both sides
How the transaction lifecycle works in practice
A customer pays €150 online on Monday at 10:00. Authorised at 10:00:01: the issuer holds €150, the merchant has a promise. Captured at 16:00 when the order ships: the merchant instructs the acquirer to take it. Cleared Monday night: the acquirer's file reaches the network, the record is validated, fees computed, the acquirer reference number assigned; the issuer posts the €150 to the cardholder as a charge. Settled Tuesday: the network's net positions move between the acquirer's and issuer's settlement accounts. Paid out Wednesday: the acquirer credits the merchant's bank account on its T+2 cycle, less fees. The customer's statement says Monday; the merchant's bank says Wednesday; the money was at the issuer, the network, the acquirer and then the merchant.
Then the after-life. The customer returns the item in week two: a refund flows back through capture, clearing and settlement in reverse, posting to her account in a few days. Or she disputes it in month three: a chargeback arrives, the merchant represents, pre-arbitration follows; the transaction that was "settled" in week one is reopened. Only when the dispute window closes — 120 days from the transaction, or from the delivery date for some codes — is the €150 the merchant's without qualification.
For a payments company the lifecycle is the state machine its systems implement and its reports describe; for a buyer of one, it is the map on which every "where is the money" question has an answer.
Example
A subscription business reviews its lifecycle data for a quarter: 2.1 million authorisations; 96.2% captured (the rest voided or expired); 99.8% of captures cleared on the first submission (0.2% rejected for data errors and resubmitted a day late); settlement from the schemes within one business day on 99.9%; payouts on T+2 with 0.4% delayed by reserve adjustments; refunds on 3.1% of captured transactions, posting to cardholders in a median of four days; chargebacks on 0.4%, of which 41% represented and 47% of those won; dispute windows closing 120 days after each transaction. The finance team's revenue recognition follows capture; its cash forecast follows payout; its risk provision follows the open dispute windows — three different curves on one timeline, which the board pack now shows on one chart.
Common mistakes
- Treating "authorised" as "paid" in revenue, "settled" as "final" in risk, or "captured" as "in the bank" in cash. - Reconciliation that uses one reference across states when each state has its own. - Support scripts that cannot say which state a payment is in. - Forgetting that a settled transaction reopens on a chargeback for four months. - Buyers of a merchant business reading the payments dashboard's "settled" totals as collected cash.