Approved Is Not Paid Out

The coffee shop terminal says "Approved." The customer puts the card away. The barista starts the order. Later, the shop owner opens the bank account and asks why that sale is not visible as a separate credit.

There is no contradiction yet. The terminal response and the merchant's bank statement describe different stages. Product and operations teams need to connect those stages before deciding that money is missing.

This fictional coffee purchase follows a simplified online card route with authorization and capture represented separately. Actual acceptance arrangements can combine messages or use different routing and timing. Offline approvals, network stand-in processing and other exceptions need their own provider-specific explanation.

Follow the authorization request

The customer presents a card or a supported wallet credential. The merchant's acceptance setup sends a request through its provider or acquiring processor and the relevant card network toward the issuer. In the ordinary online path, the issuer returns an approval or decline through the chain. Earlier checks can also prevent a request from reaching that decision point.

Visa's acceptance documentation distinguishes authorization, capture and a combined sale operation. That is a concrete example of why a diagram must state which interaction it illustrates rather than assume one universal terminal flow. VisaNet Connect Acceptance

An approval gives the merchant a payment result to act on under its acceptance arrangement. It does not itself prove that a payout reached the merchant's bank. Keep the terminal receipt and its references, but do not use the word "paid" for every later question.

Suppose the illustrative coffee costs 15 units. The receipt records the sale amount and the available transaction reference. The merchant's payment record should let support match that receipt to the provider operation. A terminal sequence number alone may not be the reference finance uses for the payout.

Capture advances the sale

Where authorization and capture are separate, the merchant or its configured service submits the capture under the provider's rules. Automatic capture can make this invisible to the cashier. It remains a meaningful financial stage that needs evidence.

A capture request, its acceptance and its eventual processing are not always the same event. A delayed batch, an integration fault or an unresolved response can leave an approved sale needing investigation. The shop should inquire about the original transaction rather than ask the customer to pay again simply because a later record is missing.

Model the commercial order separately. The coffee may already have been served while the financial workflow is incomplete. Correcting that workflow should not create another drink order, another receipt or another card charge.

Clearing, settlement and payout answer different questions

Clearing establishes the transaction information and obligations between the relevant participants. Settlement concerns the movement of funds to discharge those obligations. The merchant's payout is the transfer made under its provider arrangement, potentially covering many sales and adjustments.

Provider labels need interpretation. In Adyen's lifecycle, "Settled" means Adyen has received funds, and does not mean the merchant has already been paid out. Read the status definition before displaying it as a bank-credit confirmation. Adyen payment lifecycle

For the coffee shop, the expected bank credit may be a net batch containing card sales, fees, refunds and other permitted adjustments. The single 15-unit sale can therefore be present in the settlement detail without appearing as a 15-unit bank credit. The provider contract and reporting format determine the actual components and schedule.

Investigate the gap at the right boundary

Start with the question the merchant is actually asking. "Was the card approved?" requires different evidence from "Did the provider include the sale in this payout?" The three-way reconciliation guide expands the comparison between internal transactions, provider records and bank evidence.

The table is a proposed investigation sequence. An exception needs an owner and an expected next update, especially when several teams use different reference formats. Preserve the original evidence instead of rewriting the transaction into a convenient final state.

Cancellation changes the next action

If the customer changes their mind before capture, the available action may be cancellation or release of the authorization. After capture, the appropriate provider action may be a refund. Adyen's cancellation documentation explicitly limits that operation to an uncaptured payment. Confirm the state and supported action in the actual integration. Adyen cancellation

A refund then has its own result and customer-credit journey. It should not erase the original sale from the merchant's audit trail or make the original payout reconciliation disappear. Link the adjustment to the purchase so finance can explain both events.

Use labels that answer the merchant's question

A useful merchant view can show the sale amount, authorization/capture status, provider financial status, payout reference and reconciliation exception. It does not need to expose every message exchanged between institutions. It does need to avoid presenting a single green badge as proof of all stages.

For the coffee shop owner, the useful answer is specific: the sale was approved, capture is confirmed, it belongs to this payout batch, and that batch is either matched to the bank or still being investigated. The drink can be finished long before those records are complete.

Originally published on 22 September 2026; substantially revised using primary documentation checked on 25 October 2026. The coffee purchase is illustrative.