Why architecture matters here
The architecture matters because the gap between authorization and capture is where most payment correctness bugs live, and each bug maps directly to money and to customer trust. An authorization is a promise the issuer makes to hold funds, but it is a promise with an expiry: if the merchant does not capture within a network-defined window (often a handful of days, varying by card type and merchant category), the hold lapses and the guarantee evaporates. Capture after expiry may be declined — the merchant fulfilled and then cannot collect — or may force a fresh authorization the customer no longer expects. Modeling the auth's lifetime, and capturing inside it, is not bookkeeping; it is the difference between getting paid and eating the cost of an order.
The second forcing function is that authorized and captured amounts are frequently different, and the rules about how they may differ are strict. Many businesses authorize an estimate and capture the true amount: a partial capture (capturing less than authorized, when an order ships incomplete) is normal and releases the remainder of the hold; capturing more than authorized is generally forbidden and, where allowed, tightly bounded, because it charges the customer beyond what they agreed to. Open-ended charges — a hotel stay that runs long, a tab that grows — use incremental authorization to legally raise the hold before capture. Getting these amount relationships right is what keeps a merchant from over-charging or from silently forfeiting revenue.
The third reason is that the flow must be idempotent and non-duplicating across a distributed, retry-prone network. A capture request that times out and is retried must not capture twice; a void and a capture racing on the same auth must resolve to one outcome; an incremental auth applied twice must not double the hold. Each operation therefore carries an idempotency key and the auth's state is tracked so illegal transitions (capture an already-captured auth, void a captured one) are rejected. Payments run over unreliable networks with automatic retries, and without idempotency the natural consequence is double charges — the single most trust-destroying payment failure there is.
The fourth architectural payoff is reconciliation and auditability. Every authorization, capture, void, and expiry is an event that the merchant records, the issuer records, and the network settles, and these three views must be matched — reconciled — so that the merchant's books agree with the money actually moved. A hold the merchant thinks is open but the issuer already expired, or a capture the merchant recorded but the network never settled, is a discrepancy that reconciliation must surface. Because money and disputes hinge on it, the lifecycle is designed so that every state transition emits an auditable record keyed to the authorization, and the operational job is to close the loop between what the system believes and what the network confirms.
A fifth consideration, specific to agent-mediated payments, is that the auth-then-capture split is exactly what makes autonomous spending safe to delegate. When an agent transacts on a user's behalf, the authorization is the point at which a mandate can be checked — is this merchant, this amount, this moment within the limits the user granted? — before any money moves, and the capture is a second, separately-authorizable step that can require the goods to have actually shipped or the service to have actually been rendered. The hold gives a bounded, reversible commitment: if the agent gets it wrong, a void releases the funds with no charge ever posting, whereas a system that moved money in one irreversible step would have to claw it back through a refund. Modeling the lifecycle faithfully is therefore not just a card-network compliance detail; it is the mechanism that lets an agent commit to a purchase tentatively, prove the conditions were met, and only then finalize — the reservation-before-settlement pattern that makes delegated spending auditable and recoverable rather than a fire-and-forget transfer.
The architecture: every piece explained
Top row: the happy path from reservation to settlement. Authorize is the opening move — the merchant sends the card, amount, and details to the issuer (via the network), and the issuer, if the funds are available and the card is valid, returns an authorization code and places a hold, lowering the customer's available balance by the authorized amount without moving money. Fulfilment is whatever the merchant does next — ship the goods, provision the service, complete the ride — the real-world event that justifies collecting. Capture then converts the hold into an actual charge: the merchant tells the network to settle the authorization (in full or part), and money begins its move from issuer to acquirer to merchant.
Middle row: the adjustments the lifecycle allows. Partial capture settles less than the authorized amount — an order that shipped incomplete captures only what shipped and releases the rest of the hold. Incremental authorization raises the hold above the original amount for open-ended charges (a hotel adding room service, a ride running long), placing additional reserved funds before capture so the eventual capture stays within an authorized total. Void cancels an authorization before it is captured — an abandoned order, a corrected mistake — releasing the hold immediately rather than waiting for expiry. Auth expiry is the passive release: if the merchant never captures within the network's window, the hold lapses on its own and the funds return to the customer's available balance.
Bottom row: the model and the closing of the loop. The state machine is the governing abstraction — an authorization is authorized, then transitions to captured (fully or partially), voided, or expired, and each transition is legal only from certain states (you cannot void a captured auth, nor capture an expired one). Reconciliation is the after-the-fact matching of the merchant's authorization, capture, and void records against the issuer's and the network's settlement records, catching discrepancies where the two disagree. The ops strip names the health signals: authorization approval rate, capture latency (how long holds sit open), expiry leakage (auths that lapsed uncaptured), and over-capture disputes.
End-to-end flow
Trace an online order through the full lifecycle. At checkout the customer confirms a cart totaling one hundred and twenty. The merchant sends an authorization to the issuer, which verifies the card and available balance, places a hold of one hundred and twenty against the customer's balance, and returns an auth code. The customer's available spending power drops by that amount immediately, even though no money has moved and their statement shows a pending, not posted, transaction. The order enters the merchant's system as authorized, with the auth code and its expiry window recorded.
The warehouse ships two of the three items; one is back-ordered. The merchant issues a partial capture for the eighty that shipped, telling the network to settle that amount against the authorization. The issuer converts eighty of the hold into a posted charge and releases the remaining forty back to the customer's available balance, because a partial capture closes the authorization for the uncaptured remainder. Money for the eighty now flows through settlement to the merchant. Days later the back-ordered item ships; because the original authorization is closed, the merchant places a fresh authorization for the remaining forty and captures it — the correct handling, rather than trying to capture more against an auth that partial capture already finalized.
Now the failure paths the state machine guards. On a different order the customer cancels before anything ships. The merchant voids the authorization: the issuer releases the full hold at once, the customer's available balance is restored immediately, and no charge ever posts — far better than letting the hold sit until expiry, which would leave the customer's funds reserved for days. On yet another order the merchant is slow: it never captures and never voids, and the network's authorization window elapses. The auth expires, the hold lapses on its own, and the customer's balance frees up — but the merchant, having meanwhile shipped, now cannot capture against the dead auth and must re-authorize (risking a decline) or absorb the loss. This is expiry leakage, and the operational playbook exists to prevent it by capturing promptly.
Finally, the incremental case and reconciliation. A hotel authorizes an estimated four hundred at check-in; mid-stay the guest runs up room-service charges, so the hotel sends an incremental authorization raising the hold to five hundred, keeping the eventual bill within an authorized total. At checkout it captures the final amount. Overnight, reconciliation runs: the payment system matches each authorization, incremental, and capture record against the network's settlement file. Every hold is either captured, voided, or expired; every capture has a matching settlement; any mismatch — a capture with no settlement, a hold the issuer expired but the merchant still shows open — is flagged for investigation. The cycle of authorize, adjust, capture or release, and reconcile closes, and the merchant's books agree with the money that actually moved.