Research brief: Why “Approved” Does Not Always Mean “Settled”

Executive summary

In card-present POS payments, “Approved” usually means the issuer or network has accepted an authorization request. It does not necessarily mean the merchant has received money, that the transaction has been cleared, or that the payment is financially final. Mastercard describes card transaction processing as three distinct activities: authorization, clearing, and settlement; authorization verifies cardholder identity, card authenticity, and available funds, while clearing exchanges financial transaction details for account posting and reconciliation.

The practical gap is this: an approved authorization creates a right or expectation to capture funds, but the payment still depends on later steps: capture, clearing record generation, acquirer processing, scheme processing, issuer posting, settlement funding, reconciliation, and exception handling. Adyen’s lifecycle documentation makes this explicit: an Authorised payment means funds are reserved and can later be captured or cancelled; if not captured within the validity period, the authorization expires.

For POS professionals, the most important lesson is: do not design business logic around the word “approved” alone. Build around payment state transitions, idempotency, reversals, capture/settlement confirmation, reconciliation, and customer-visible ambiguity.

⸻

Key concepts

1. Authorization

Confirmed fact: Authorization is the real-time decision step. In card networks, it transports requests, responses, cancellations, and advice messages used to verify cardholder identity, card authenticity, and funds availability at purchase time.

Interpretation for POS: At the terminal, “Approved” is often the UX label for this stage. It tells the cashier or cardholder that the transaction passed the authorization decision. It does not prove that funds have moved to the merchant.

2. Capture

Confirmed fact: In processor APIs, authorization and capture can be separate. Stripe states that setting capture_method=manual authorizes the amount but does not capture it on the customer’s payment method.

Interpretation for POS: Capture is the merchant/acquirer-side instruction to move the transaction from “reserved” toward financial processing. In many POS systems capture is automatic or batched, so operators may not see it as a separate step, but technically it remains distinct.

3. Clearing

Confirmed fact: Mastercard defines clearing as the exchange of financial transaction details between acquirer and issuer to support posting to the cardholder account and reconciliation of settlement positions. Its Global Clearing Management System accepts, edits, assesses fees, and routes card transactions.

Interpretation for POS: Clearing is where the transaction becomes a financial record suitable for posting and reconciliation. A transaction can be approved at authorization time but fail, be delayed, or be mismatched later in clearing.

4. Settlement

Confirmed fact: Visa’s Transaction Acceptance Device Guide defines a sale completion as the financial settlement of a previously authorized transaction, often where the cardholder and card are no longer present. It also says sale completion is the clearing component of a pre-authorization and associated incremental authorizations.

Interpretation for POS: Settlement is the movement or netting of funds between parties. Merchant payout may occur after scheme settlement and acquirer/PSP accounting, so “settled” in a PSP dashboard may not always equal “paid out to merchant bank account.”

5. Authorization reversal

Confirmed fact: Visa states that authorization reversals notify the issuer that all or part of a transaction has been cancelled and that the hold on cardholder funds should be removed. Visa also states that if a transaction is not completed, the authorized amount must be reversed within 24 hours of the merchant becoming aware the transaction will not be completed or by the end of the authorization validity period.

Interpretation for POS: Reversal is critical in failed POS flows. Without a reversal, the customer may see a pending hold even though the merchant never completed the payment.

⸻

Current state of the topic

The industry still exposes “Approved” prominently because POS acceptance must be fast and understandable at the checkout. But modern payment platforms increasingly model the transaction as a lifecycle: Received → Authorised → Captured/SentForSettle → Settled, with separate states for cancellation, expiry, refusal, error, refund, and chargeback. Adyen’s reporting documentation explicitly shows that reports contain payments at different lifecycle stages, including Received, Authorised, SentForSettle, Settled/Refunded, Cancelled, Expired, Error, and Refused.

This matters even more in SoftPOS, app-to-app, cloud POS, and mobile SDK integrations. The terminal UI, SDK callback, merchant backend, acquirer host, and PSP reporting system may observe different parts of the lifecycle at different times. A mobile app might receive an SDK result, lose connectivity before finalizing with the merchant backend, or return control to a third-party app before backend reconciliation is complete. In those cases, “approved” can become operationally ambiguous even if the card network authorization was valid.

⸻

Main benefits of separating “approved” from “settled”

1. Better customer experience

Separating authorization from settlement allows merchants to support tips, hotel deposits, car rental deposits, fuel pre-authorizations, delayed shipping, and split fulfillment. Visa explicitly supports estimated and incremental authorizations when the final amount is not known at the start of the purchase.

2. Better risk control

Authorization checks whether funds are available and whether the issuer approves the transaction at that moment. Capture and clearing allow the merchant or acquirer to submit the final amount later, often after goods are delivered, tips are added, or the service is completed.

3. Better operational reconciliation

A lifecycle model gives finance and support teams the ability to answer: Was it authorized? Was it captured? Was it sent for settlement? Was it settled? Was it refunded? Was it reversed? Adyen’s reports separate statuses across lifecycle stages, which reflects the operational need to track more than one “success” state.

4. Better exception handling

Because authorization and settlement are separate, systems can cancel, reverse, expire, retry, or investigate a payment before it becomes final. This is essential for unstable networks, mobile terminals, interrupted app sessions, and host-to-host integration failures.

⸻

Main risks and limitations

1. False sense of finality

Confirmed fact: Adyen recommends waiting for a payment to be captured before delivering goods or services in the Authorised state.

Interpretation: The business risk is treating authorization as final payment. This may be acceptable in low-risk card-present retail, but it is dangerous for delayed fulfillment, high-value goods, app-to-app flows, or any flow where capture/finalization can fail after authorization.

2. Pending holds and customer complaints

Confirmed fact: Visa warns that missing or non-matching data between authorization messages and clearing can cause funds to remain held longer or in duplicate, which cardholders may interpret as an extra charge and may trigger complaints.

Interpretation: To the customer, a pending hold often looks like a charge. This creates support pressure even when the merchant has not actually received funds.

3. Duplicate-charge risk

Duplicate-charge risk appears when the system loses certainty after authorization. For example, the POS app may get an approved result from the payment SDK, but fail before finalizing with the merchant backend. A retry with a new merchant reference can produce a second authorization or charge unless idempotency and recovery are designed correctly.

4. Expired authorizations

Confirmed fact: Adyen states that an authorization is valid for a period during which funds can be captured or cancelled; if not captured during the validity period, it expires. For cards, Adyen says this validity period is usually 28 days, with scheme-specific periods in some cases.

Interpretation: Authorization is not permanent. A system that delays capture too long may need a new payment attempt, not just a retry of settlement.

5. Amount mismatch

Tips, fuel, hotel stays, rentals, and partial shipments can create differences between the authorized amount and the final amount. Visa says merchants can use incremental authorizations when the customer spends more than expected, and partial reversals when the estimate exceeds the final amount.

6. Reporting ambiguity

A dashboard may show “Authorised,” “Captured,” “SentForSettle,” or “Settled,” while the merchant’s order system may show “Paid.” If these states are collapsed too early, finance and support teams lose the ability to distinguish operational success from financial finality.

⸻

Practical examples

Example 1: Restaurant with tip

A restaurant authorizes the base amount, then the customer adds a tip. Depending on region and scheme rules, the clearing amount may include a gratuity above the originally authorized amount. Visa’s TADG describes gratuity/tip options where the clearing amount can include tip after authorization, subject to local rules and limits.

Lesson: Approved at the table is not necessarily the final financial amount.

Example 2: Fuel station pre-authorization

At an automated fuel dispenser, the final amount is unknown before fueling. Visa describes fuel flows using status checks or initial authorization, followed by a sale completion for the actual amount or reversal of the unused portion.

Lesson: The authorization protects the merchant before the final amount exists; settlement must later reflect the actual dispensed amount.

Example 3: Hotel or car rental

A hotel may pre-authorize an estimated amount at check-in, add incremental authorizations during the stay, then submit a sale completion at checkout. Visa describes hotel/tourism flows where express checkout uses a sale completion for the final billing amount, often without the cardholder and card being present.

Lesson: Approval reserves capacity; settlement follows the final service outcome.

Example 4: E-commerce delayed shipping

An online store may authorize at checkout but capture only when goods ship. Stripe’s manual capture model is a technical example of this separation: the payment can be authorized first and captured later.

Lesson: Authorization is a promise-like hold, not proof of completed fulfillment.

Example 5: SoftPOS / Tap-to-Pay app crash after approval

A SoftPOS SDK returns “approved,” but the app crashes before the merchant backend receives the finalization call. The cardholder may have an approved authorization, while the merchant order remains open. If the app restarts and creates a new order reference, a retry can produce duplicate exposure.

Confirmed foundation: Authorization, clearing, and settlement are separate network activities.
Interpretation: SoftPOS systems must persist transaction references, recover mandatory SDK state, finalize idempotently, and reconcile against host/acquirer status before allowing a blind retry.

⸻

Opposing viewpoints and open debates

Viewpoint A: “In card-present retail, approved is good enough”

In many classic retail environments, authorization, capture, clearing, and settlement are highly automated. The cashier sees “Approved,” the customer leaves, and the merchant’s acquirer handles the rest. For low-value, immediate-delivery transactions, this model is operationally efficient.

Limitation: This viewpoint becomes weaker when payments are mobile, cloud-triggered, app-to-app, pre-authorized, delayed-capture, high-value, or dependent on unstable connectivity.

Viewpoint B: “The customer experience should hide payment complexity”

There is a valid UX argument that cashiers and customers should not be exposed to clearing and settlement terminology. “Approved” is simple and familiar.

Limitation: Internal systems should still model the full lifecycle. The UI can be simple, but backend state must be precise.

Viewpoint C: “Settlement is a finance problem, not a POS problem”

Some teams treat settlement as back-office accounting, outside the POS application boundary.

Limitation: POS design choices create settlement problems. Missing reversals, wrong transaction identifiers, duplicate merchant references, incorrect capture timing, and amount mismatches originate at the acceptance layer.

Open debate: real-time clearing versus batch settlement

Some payment methods and regions are moving toward faster clearing and settlement, but card systems still contain distinct lifecycle concepts. Faster processing reduces the time gap; it does not eliminate the logical difference between authorization, clearing, settlement, reversal, refund, and dispute.

⸻

What matters most for professionals

For POS architects

Model the transaction as a state machine, not a boolean. Minimum states should distinguish:

initiated → authorised → capture_requested → sent_for_settlement → settled → failed/cancelled/reversed/expired/refunded/disputed

For SoftPOS and SDK integrations

Persist the SDK transaction reference, merchant reference, amount, authorization result, and backend finalization state. Never rely only on an in-memory callback. If the app crashes after approval, recovery must know whether the original transaction can be finalized, reversed, or queried.

For backend engineers

Use idempotency keys and stable merchant references. A retry should complete or query the original transaction, not create a financially separate one.

For product managers

Avoid using one label, “Paid,” for every successful-looking payment state. “Authorized,” “Captured,” “Settled,” and “Paid out” are different business events.

For support teams

Train teams to distinguish pending authorization holds from settled charges. Visa explicitly notes that held funds or duplicate-looking holds can trigger cardholder complaints when authorization and clearing data do not match correctly.

For finance and reconciliation teams

Reconcile by lifecycle stage and reference identifiers, not only by order ID. Track authorization code, PSP reference, acquirer reference, retrieval reference number where available, capture ID, settlement batch, and ARN/refund references.

⸻

Confirmed facts vs interpretation

Area Confirmed fact Interpretation for POS professionals Authorization Mastercard defines authorization separately from clearing and settlement. “Approved” is not financial finality. Capture Stripe supports authorizing without capturing through manual capture. A platform can intentionally delay money movement. Lifecycle Adyen separates Authorised, SentForSettle, Settled, Cancelled, Expired, Error, and Refused. Payment systems need multi-state order logic. Reversal Visa says reversals notify issuers to release holds and adjust open-to-buy. Failed POS flows need explicit reversal handling. Sale completion Visa defines sale completion as financial settlement of a previously authorized transaction. Pre-auth flows must close with completion or reversal. Expiry Adyen says uncaptured authorizations expire after a validity period. Delayed capture has a deadline.

⸻

Corebaseit / LinkedIn angle

A strong article thesis would be:

In payments, “Approved” is a technical checkpoint, not the end of the transaction. The real engineering work begins in the gap between authorization and settlement: capture, reversal, recovery, idempotency, reconciliation, and customer-visible ambiguity.

A concise LinkedIn hook:

The POS screen says “Approved.” The finance system says “Not settled.” The customer sees a pending hold. All three can be true.

⸻

High-quality references

1. Mastercard — Switching Explained: clear distinction between authorization, clearing, and settlement.
2. Mastercard — Transaction Processing Rules, 10 June 2025: current scheme rulebook covering authorization and clearing requirements.
3. Visa — Authorization and Reversal Processing Requirements for Merchants, 2024: practical rules for estimated authorizations, incremental authorizations, reversals, and duplicate-hold risks.
4. Visa — Transaction Acceptance Device Guide, August 2025: POS/chip guidance on pre-authorizations, incremental authorizations, sale completions, fuel, hotels, tips, and reversals.
5. Adyen — Payments lifecycle: processor lifecycle states and the distinction between authorization, capture, settlement, expiry, and cancellation.
6. Adyen — Reports and the payments lifecycle: reporting view across lifecycle stages.
7. Stripe — Place a hold on a payment method: API-level explanation of separate authorization and capture.
8. PCI SSC — Mobile Payments on COTS MPoC: relevant for SoftPOS security context, especially where POS acceptance runs on commercial off-the-shelf devices.