Manual Capture: The Two-Step Logic Behind Tap to Pay and Modern Card Payments

A card payment is usually described as a single act: the customer pays, the merchant gets the money. In practice, many card-payment systems distinguish authorization from clearing and settlement, and those stages can be separated in time. Authorization asks the issuer to validate the transaction and reserve funds. Capture is the later instruction that submits the authorized amount for clearing and settlement. Manual capture is the discipline of controlling that second step explicitly instead of allowing the payment platform to trigger it automatically.

This post treats manual capture as an architecture problem rather than a feature toggle. It defines the boundary where the authorization domain ends and the backend lifecycle begins, models the post-authorization states a transaction can occupy and the host, network, or internal action associated with each transition, and examines the timing and amount constraints that can turn a clean capture into a costly or unsuccessful one. The mechanisms here (ISO 8583 authorization and completion messaging, hold expiry windows, reversals, and a deterministic capture state machine) are drawn from the card-present transaction lifecycle as implemented in production POS and acquiring systems, and covered in depth in Chapter 13 of Point-of-Sale Systems Architecture.

Two phases behind many card payments

In an auto capture flow often presented to the merchant as a plain sale or purchase authorization and capture appear as one application-level operation. The payment platform handles the seam automatically. In manual capture—also called delayed capture, deferred capture, or authorize now, capture later—the merchant controls the second stage explicitly, normally for an amount no greater than the amount currently authorized.

The reason to separate them is control over timing and final amount. The recurring cases are familiar:

E-commerce that charges only when goods ship.
Hotels and car rentals that pre-authorize an estimate at check-in and capture the final amount, including incidentals, at checkout.
Fraud or order review that needs a window before committing the charge.
Partial or split captures against a single authorization.

In ISO 8583-based environments, a host may represent authorization, financial completion, advice, reversal, and clearing through message pairs such as 0100/0110, 0200/0210, 0220/0230, or 0400/0420. However, those MTIs do not form a universal manual-capture contract. Their exact business meaning depends on the acquiring host, processing code, scheme profile, and required data elements. For example, DE3 001000 may identify a pre-authorization on some hosts but mean something different—or be unsupported—on another. Always follow the acquirer or processor interface specification.

The architectural seam: where the card leaves the field

The most important line in manual capture is the one between the two phases, because responsibility changes sides when you cross it.

Manual capture across two phases: Phase 1 is card-present (NFC tap, EMV contactless kernel generating ARQC and CVM, online authorization 0100 to 0110); the card then leaves the field; Phase 2 is deferred and card-free (merchant triggers capture, capture request to acquirer for an amount no greater than the authorization, then clearing and settlement via 0220 advice or batch)

Everything above the seam is the acquisition domain: NFC read, EMV contactless kernel, cardholder verification (CVM), cryptogram generation, and assembly of the authorization request. In a typical integration, the certified SDK owns card acquisition and EMV processing, while the merchant backend owns the later capture decision. The precise handoff depends on the PSP and SDK contract. The The integration must retain the identifiers and authorization data required by its PSP or acquiring host. Depending on the platform, these may include a provider transaction ID, merchant reference, authorization code, network reference such as the RRN, original authorized amount, and the processor’s current capturable amount.

Everything below the seam is a backend concern. The card has left the field, so the remaining steps are card-free backend operations linked to the original card-present authorization, keyed off stored references rather than the card itself. The capture lifecycle is then driven by the merchant application, transaction service, PSP, and acquiring host, normally through API or host calls with no second tap. The backend must persist the identifiers and original authorization data required to correlate every capture, reversal, status query, and retry with the original card-present transaction.

Modeling the capture lifecycle as a state machine

Once authorized, a transaction is not “done.” It sits in a hold and has to reach a defined terminal state. Modeling that explicitly matters because different transitions may trigger host messages, API operations, internal state changes, or time-driven expiry, each with different timing, reconciliation, and cost consequences. Scattering that logic across handlers is how holds get stranded and interchange gets downgraded.

Capture lifecycle state machine: AUTHORIZED (active hold) fans out to four paths. Partially captured (amount less than auth) advances to Captured then Settlement; Captured (full or remainder) flows to Settlement; Reversed actively requests release of the unused authorization; Expired represents the authorization reaching the end of its validity window without capture

AUTHORIZED is the entry state, reached when the issuer approves the request and reserves the funds. In a simplified business model, the authorization has four principal outcomes: full capture, partial capture, reversal, or expiration. A production state machine may also require pending, failed, retryable, incremental-authorization, and reconciliation states.

Two outcomes submit money for clearing and settlement. A capture for the full currently authorized amount moves the transaction to CAPTURED. A smaller capture may move it to PARTIALLY_CAPTURED. Where multi-capture is supported, additional captures can be submitted against the remaining authorized balance. On platforms that do not support multi-capture, a partial capture may be treated as final and the unused remainder may be released automatically or require a separate reversal. Captured amounts then proceed through clearing, settlement, and reconciliation.

The other two principal outcomes close the authorization without capturing the unused amount, and the distinction between them is operationally important. REVERSED is active: the merchant, PSP, or acquirer submits a reversal or cancellation referencing the original authorization so the issuer can release the unused hold. A message such as 0400 or 0420 may be used in some ISO 8583 host profiles, but the exact implementation is host-specific. EXPIRED is time-driven: the authorization reaches the end of its validity window without being fully captured or explicitly canceled. The issuer or processor then releases the remaining hold according to its own processing rules.

That asymmetry is the lesson worth internalizing. Expiration is not an explicit release initiated by the merchant; it is the result of the authorization reaching the end of its validity period. When the merchant already knows that the funds will not be collected, an explicit reversal is normally the cleaner operational outcome. It allows the issuer to begin releasing the hold sooner, although the cardholder may not see the balance update immediately. The same active-versus-passive decision applies to any uncaptured remainder after a partial capture: reverse it explicitly where required, or confirm how the PSP handles the remaining authorization automatically. Where a reversal sits relative to refunds and chargebacks is covered in reversals, refunds, and chargebacks, and the duplicate-charge risk that idempotent capture defends against in double charges.

Amount and timing: the constraints that cost money

Manual capture buys flexibility and bills you for it in constraints. Three are worth designing around explicitly.

Capture amount has a controlled ceiling. In the general case, the cumulative captured amount should not exceed the amount currently authorized. Merchant categories with variable final totals—such as hospitality, vehicle rental, fuel, and restaurants—may use estimated, incremental, or adjusted authorization flows under scheme- and acquirer-specific rules. Instead of implementing a generic percentage tolerance, enforce:

captured_amount ≤ currently_authorized_amount

The currently_authorized_amount should include any approved incremental authorization. Any attempt to exceed that amount should be rejected or routed through the authorization-adjustment process defined by the acquirer.

Authorizations have a finite validity period, but there is no single capture window that applies to every Tap-to-Pay transaction. The deadline depends on the processor, scheme, card type, region, transaction type, merchant category, and whether extended authorization is supported. The system should therefore store the authoritative capture deadline—such as a PSP-provided capture_before value—rather than hard-code a generic number of days. If the deadline is missed, the hold may be released and the original authorization protection may be lost. A new authorization could then require the customer to present the card or wallet again.

Capture quality can affect acceptance, authorization protection, reconciliation, and cost. Late completion, missing data, or an amount that does not reconcile correctly with the authorization may lead to rejection, loss of authorization protection, compliance issues, or less favorable qualification under the applicable network and acquirer rules. This is a strong operational reason to capture promptly once the final amount is known, while treating the processor’s interface and qualification rules as the authoritative source.

How this maps to Tap to Pay

Tap to Pay changes the acceptance device, not the payment model. Instead of presenting the card to a dedicated terminal, the cardholder taps an NFC-enabled phone running a certified application. The phone and SDK handle the card-present interaction (contactless read, EMV processing, CVM when required, secure transmission, and delivery of the authorization result), and then the card-present part is over.

When manual capture is configured, an approved Tap-to-Pay transaction is stored in an authorized-but-not-captured state, and the later capture runs through the merchant application or backend, not by asking the customer to tap again. The cleanest way to hold the two ideas apart:

Tap to Pay answers how the card is accepted. Manual capture answers when the merchant completes the charge. They live in different layers and compose cleanly, which is exactly why the seam between them has to be explicit in the design.

Implementation guardrails

A few rules belong in the system, not in an operator’s memory:

Make each logical capture operation idempotent. Persist a unique capture-operation ID linked to the original authorization, merchant reference, capture sequence, amount, final-capture indicator, and processor transaction reference. Every retry of the same logical capture must reuse that ID, while a legitimate second partial capture must use a new one. Backend idempotency patterns are detailed in Chapter 15 of the book.
Track the processor-provided capture deadline and trigger alerts or reversals before it lapses. Where automated reversal is supported, use it to release authorizations that the merchant already knows will not be captured.
Distinguish AUTHORIZED from CAPTURED everywhere it is shown. An approved authorization is a reserved hold, not a completed payment, and a dashboard that blurs the two will mislead reconciliation and support.
Reverse rather than abandon where the platform requires an explicit release. Submit reversals for canceled orders and uncaptured remai

A single rule under all of it

Manual capture is what lets payment collection line up with fulfillment, dynamic totals, and risk review. The cost of that flexibility is a second lifecycle that you now own end to end, with its own messages, timers, and failure modes.

So the question to ask of your own flow is narrow: once a transaction is authorized, does your system guarantee that it reaches a defined and reconciled outcome—captured, reversed, or deliberately allowed to expire—rather than drifting there without ownership? An “approved” transaction is a beginning, not an end.

Key takeaways

Many card-payment systems distinguish authorization from clearing and settlement. Manual capture exposes that separation to the merchant: authorize now and capture later, normally for an amount no greater than the amount currently authorized.
The authorization/capture seam is an architectural boundary. The SDK and payment application own card acquisition and EMV processing, while the merchant backend and PSP manage the later card-free continuation of the original card-present transaction.
A simplified lifecycle can be modeled as AUTHORIZED → CAPTURED / PARTIALLY_CAPTURED / REVERSED / EXPIRED. Some transitions produce host messages or API calls, while others are internal or time-driven. Production systems may require additional pending, failure, retry, and reconciliation states.
Reversal is an active request to release an unused authorization; expiration is a time-driven outcome. When the merchant knows the funds will not be collected, an explicit reversal is normally preferable. Uncaptured remainders must be handled according to the PSP’s partial-capture rules.
Respect the constraints: capture no more than the currently authorized amount, use the processor’s authoritative capture deadline, submit complete and consistent capture data, and make every logical capture operation idempotent.