Approved Is Not Paid Out

The coffee shop terminal says "Approved." The customer puts the card away. The barista starts the order.

That moment feels finished to the customer, but it is not finished for the merchant. The card tap has entered a chain of payment states that still has to become a captured sale, a cleared and settled obligation, and finally a merchant payout that can be reconciled to the shop's bank account.

The distinction matters because support teams, finance teams and product teams often talk about one transaction as if it has one state. In a real operating model, the customer receipt, the processor record, the settlement file and the bank credit may be correct at different times for different reasons.

Follow The Coffee Receipt

Start with one normal card purchase. The terminal sends an authorization request through the merchant's acceptance setup. That route can involve a payment service provider, acquiring processing, a card network and the cardholder's issuer. The issuer decides whether to approve the request and the response returns to the terminal.

Adyen's payment lifecycle documentation separates authorization, capture, settlement and payout as distinct parts of a payment's movement through the system. That is a useful product model even when a merchant uses another provider, because it prevents the team from treating the terminal response as the whole money movement. Adyen payment lifecycle

In the UAE, Network International describes acquiring processing as a service layer for financial institutions and merchants. In Saudi Arabia, Geidea and neoleap publish merchant POS and payment-terminal propositions. These examples are not one transaction chain. They are local acceptance providers that show why a coffee shop's route depends on the provider and agreement it actually uses. Network International acquiring processing Geidea payment terminals neoleap POS

The operating question is therefore not "was it approved?" The better question is "which evidence do we have for each state?"

Approval Is Only The First Useful Signal

Authorization answers a narrow question: can this purchase proceed now? It does not prove that the final merchant amount has been submitted, settled or paid out.

That is why a merchant dashboard should not collapse every successful terminal response into the same bucket. A good dashboard separates at least four labels:

• Approved: the issuer response allowed the purchase at the point of sale.
• Captured: the merchant or provider submitted the transaction for financial processing.
• Settled: the relevant obligations moved through the clearing and settlement process under the scheme/provider arrangement.
• Paid out: the merchant can identify the payout or bank credit that includes the sale, net of fees, refunds or adjustments.

The labels sound basic. They are also where many operational disputes begin. A cashier can see an approved receipt and still be unable to explain why finance cannot find the bank credit. Finance can see a payout and still need the original receipt reference to identify which sale it includes.

Design The Exception Path Before The Incident

A useful product exercise is to take one receipt and draw a row for each later event. Put the authorization reference in the first row. Add a capture reference only when the system has one. Add settlement and payout references when the relevant reports provide them. Leave blank fields blank.

Then test three cases:

1. A normal purchase that is approved, captured, settled and paid out.
2. A purchase where the terminal response times out after the issuer approved it.
3. A purchase captured after a cutoff, so payout lands in a later batch.

Those cases reveal whether the product has real traceability or only a successful front-end experience. The cashier does not need to read clearing files. The finance user should not need to ask engineering to find a bank credit. Each role needs the next useful reference, not the whole payment stack.

The support path should follow the same split. If approval exists but capture is missing, the next action belongs with the merchant's acceptance workflow. If payout exists but bank credit is absent, the investigation moves to the payout and bank-credit path. If a cardholder asks why an issuer declined the purchase, the merchant may only be able to explain what the terminal received, not the issuer's private decisioning.

The Product Requirement Is Evidence

For product managers, the main requirement is not a prettier transaction timeline. It is an evidence contract.

Each state should have an owner, a timestamp, a reference and a permitted customer/support message. "Pending" is acceptable only if the product can say what it is waiting for. "Approved" should not be used as shorthand for "paid." "Paid out" should not be shown until the payout evidence exists.

This is also a reconciliation requirement. The shop's daily sales total, provider reports, fee deductions, refunds and bank credits must eventually agree. When they do not, the product should classify the exception: missing capture, delayed batch, payout adjustment, refund, fee variance or bank-credit mismatch.

The coffee receipt is a small example, but the pattern scales. Marketplaces, subscription platforms and cross-border merchants face the same issue with more rows, more currencies and more counterparties. The transaction is not done when the customer walks away. It is done when the merchant can trace the money.

Operator Takeaway

Approved is a customer-facing milestone. Paid out is an operating milestone.

If the product uses one word for both, it will eventually create a support problem, a finance problem or a reconciliation problem. The cleaner design is to model the payment journey as evidence-backed states and show each team the reference it needs to act.

FAQ

Does an approved card payment mean the merchant has been paid? No. Approval means the purchase was allowed at the point of sale. Capture, settlement and merchant payout are separate states that depend on the provider arrangement and timing.

Why can a receipt be visible before bank credit appears? The receipt reflects the point-of-sale event. Bank credit depends on later processing, payout timing, fees, refunds and adjustments.

What should a merchant payment dashboard show? At minimum, it should separate approval, capture, settlement and payout evidence, with references and timestamps for each state.