Card authorisation, capture and settlement: one sale moves through three different payment stages

A card payment is not one instant event. The issuer first authorises the transaction, the merchant or processor captures it for clearing, and the acquirer later settles the funds into the merchant balance or bank account. Understanding the stages helps finance explain pending payments, failed captures and payout differences.

Authorisation checks whether the issuer will approve the transaction

The merchant sends the card, amount and transaction data through its acquirer or payment processor. The issuer approves or declines based on funds, fraud rules and authentication information.

An approval normally creates a hold or authorisation on the cardholder account. It does not yet mean the merchant has received cash.

Capture tells the payment system to complete the approved charge

Some merchants capture automatically at checkout. Others authorise first and capture later after goods ship or a service is confirmed.

The captured amount can sometimes be lower than the authorised amount. The rules for partial or multiple capture depend on the payment provider and card network.

Unused authorisations can expire

An authorisation remains valid only for a limited period. If the merchant waits too long to capture, the approval can expire and the transaction may need a new authorisation.

Track uncaptured orders so old holds do not sit on customer cards while the merchant also lacks a completed sale.

Settlement happens after network clearing

After capture, the transaction enters clearing and settlement. The acquirer or processor receives funds and later pays the merchant according to its payout schedule.

Settlement timing can differ from the customer purchase date. Finance should not expect every Saturday card sale to appear as one Sunday bank credit.

Void or reverse unused authorisations promptly

If an order is cancelled before capture, use the processor's void or reversal process where available. That can release the customer's hold faster than waiting for expiry.

Do not issue a refund for a payment that was never captured. A refund is a different event and can create unnecessary fees or confusion.

Connect order, capture and payout IDs

Store the processor transaction ID and status with the order. Finance should be able to see whether a customer charge was authorised only, captured, refunded or settled.

Reconcile captured transactions through fees and adjustments to the final merchant payout rather than treating authorisation reports as bank cash.

Worked example: a hotel authorises £500 at check-in, captures £420 at checkout and releases the remaining hold. The customer can briefly see £500 pending, while the merchant ultimately settles £420. Finance should record the £420 captured sale, not the original authorisation amount.

Use ageing reports for authorised-but-uncaptured transactions. A high count can indicate fulfilment integration failures, staff forgetting manual capture or orders that should have been cancelled.

Monitor capture failures separately from issuer declines. The issuer can approve a payment that the merchant later fails to capture because of a technical or operational problem. Different causes need different fixes.

For ecommerce businesses shipping physical goods, decide whether capture occurs at order, dispatch or another milestone. Capturing too early can create refund work when stock is unavailable; capturing too late can allow authorisations to expire.

Worked example: a merchant authorises £1,000 for an appliance order on Monday but dispatch does not occur until the following week. If the provider's authorisation window expires before capture, the merchant may need a new authorisation even though the customer believed the order was already paid.

Use capture status in fulfilment logic. Warehouses should not ship high-risk goods based only on a successful authorisation if the business policy requires completed capture first.

At month-end, distinguish authorised-but-not-captured orders from captured unsettled payments and settled payouts. All three can exist simultaneously and represent different accounting and cash positions.

Set operational alerts for captures that remain pending beyond normal processor timing. A technical issue between gateway and acquirer can leave an order in an ambiguous state where customer service believes it was paid but finance never receives settlement.

For high-volume merchants, reconcile authorisation rate, capture rate and settlement rate separately. A strong authorisation percentage can hide lost revenue if the capture integration fails later in the lifecycle.

Keep processor timestamps in the merchant ledger. Authorisation, capture and settlement can occur on different calendar days and even different accounting periods, so timestamped status data helps explain month-end cut-off differences between orders, processor reports and bank cash.

For multi-currency merchants, preserve the currency at every stage. An authorisation in euros, capture in euros and settlement converted to sterling can create FX and fee differences that are invisible if finance stores only the final bank payout.

Keep a reconciliation rule for processor timezone. A capture made just after midnight UTC can fall into a different payout day from the customer's local purchase date, creating apparent exceptions unless finance understands the cut-off.