Manual capture is the practice of splitting a card transaction into its two underlying phases and controlling the second one explicitly, rather than letting them fire together.

Every card payment really has two steps. Authorization asks the issuer to validate the card and place a hold on the funds — nothing actually moves yet. Capture is the instruction to the acquirer to move the money, which is what feeds clearing and settlement. In an auto capture (a plain “sale” or “purchase”), those happen in a single step. In manual capture (also called delayed or deferred capture, or “auth-only then capture”), you authorize first and then issue the capture later as a separate, deliberate action — and often for an amount up to the authorized total.

The reason you’d want that separation is timing and amount control. The classic cases are: charging only when goods ship in e-commerce, hotel and car-rental flows where you pre-auth at check-in and capture the final amount (with incidentals) at checkout, fraud or order review before committing the charge, and partial or split captures against a single auth.

A few constraints worth keeping in mind:

• Authorization holds expire. The window depends on scheme and MCC — often around 7 days, shorter for some categories — and if you don’t capture in time the hold drops and you may need to re-authorize.
• You can generally capture less than the authorized amount (partial capture), but capturing more is restricted, with narrow tolerances for things like restaurant tips or fuel.
• Late or amount-mismatched captures can downgrade interchange, since the schemes price on how cleanly the capture matches the authorization.

In ISO 8583 terms — closer to your world — this maps to an authorization request (0100/0110) followed by a separate capture, typically as an advice (0220) or in a batch, versus a combined financial request (0200) that authorizes and captures in one message. In card-present POS it’s less common than in card-not-present, but it shows up in pre-auth scenarios like bars, fuel pumps, and tip adjustment.

Want me to go deeper on any angle — the auth expiry windows per scheme, interchange downgrade mechanics, or how this typically gets modeled in a SoftPOS/Tap-to-Pay transaction flow?

Here’s the agnostic version — same flow, vendor-neutral labels.The architectural seam — the dashed line — is the part worth designing around, stated generically.

Everything above the line is the acquisition domain: NFC read, EMV contactless kernel, CVM, cryptogram generation, and assembling the authorization request. This is the SDK’s responsibility, and it ends the moment the authorization completes. Everything below the line is a backend concern — the acquisition layer has no further role. The capture lifecycle lives in your transaction service and the acquiring host.

So the clean responsibility split is: the acquisition SDK owns Phase 1 end-to-end and returns an authorization result — auth code, retrieval reference, online outcome, and a pending-capture amount. Your transaction service then owns the Phase 2 lifecycle as a state machine driven entirely by API calls, with no card and no SDK involvement.

The reason to model it explicitly as a state machine is that each transition emits a different network message and carries different timing constraints — late or mismatched captures downgrade interchange, unreleased holds surface to the cardholder, and authorizations expire if you sit on them. Encoding that as AUTHORIZED → CAPTURED / PARTIALLY_CAPTURED / REVERSED / EXPIRED keeps those rules in one place instead of scattered across handlers.

Here’s the Phase 2 lifecycle as a state machine. The color split is the quick read: teal is the live hold you start with, amber is the path where money actually moves, and gray is a transaction that closed without a capture.Reading the machine:

Authorized is the entry state — you land here the instant the authorization response comes back and the issuer places the hold. From here there are exactly four ways out, and that fan-out is the whole point of modeling it explicitly: each exit emits a different message and carries different timing risk.

The two amber transitions move money. A capture for the full authorized amount goes straight to Captured. A capture for less drops into Partially captured, which can then advance to Captured with a subsequent capture of the remainder (where multi-capture is supported) — same 0220-class message, just against the remaining balance. Once in Captured, the record flows into clearing and Settlement. These are your only happy-path terminal routes.

The two gray transitions close the transaction without moving money, and the distinction between them matters operationally. Reversed is active — you send a reversal (0420) to release the hold immediately, which is what you do on a canceled order or a failed fraud review. Expired is passive — no message is sent at all; the hold simply drops when the authorization window lapses on the issuer side. The asymmetry is the lesson: leaving a transaction to expire is never a deliberate “release,” it’s just neglect, and it leaves the cardholder staring at a phantom hold in their banking app until the window closes. Reversing is the intentional, clean exit.

A couple of edges I left off the diagram to keep it legible, but that belong in a real implementation:

• Partially captured → Reversed / Expired for the uncaptured remainder. After a partial capture, the leftover hold still has to go somewhere — you either reverse it explicitly to free the funds, or it expires on its own. Same active-vs-passive distinction as above, just applied to the balance.
• A guard on every capture transition enforcing captured_amount ≤ authorized_amount, since overcapture is only permitted inside narrow scheme tolerances and should be rejected at the state-machine boundary rather than discovered at clearing.

If you’re turning this into a written spec, the natural next artifact is a transition table — each row a (from_state, event, to_state, message_emitted, guard) tuple — which pins down the exact behavior far more precisely than the diagram and drops straight into a design doc. Want me to draft that table?

Operational Risk Assessment: The Financial and Structural Impacts of Manual Capture Lifecycle Management

1. Architectural Foundation: The Bifurcation of Authorization and Capture

Manual capture is a strategic payment architecture that meticulously separates a card transaction into two distinct phases. Rather than allowing authorization and settlement to fire simultaneously—as seen in “auto-capture” or standard “sale” transactions—manual capture creates an intentional “architectural seam” between the acquisition domain (Phase 1) and the backend transaction service (Phase 2). This separation provides merchants with critical control over the timing of settlement and the final amount collected, which is essential for business models where fulfillment is deferred or the final total is subject to post-service adjustments.

A critical security and UX boundary exists at this seam: once Phase 1 is complete and the authorization is secured, the card “leaves the field.” All subsequent lifecycle management steps are card-free, necessitating that the backend transaction service operates on deferred, card-not-present (CNP) logic using stored tokens or transaction references.

Domain Responsibility Split

Acquisition Domain (SDK/NFC) Transaction Backend Service NFC card reading and EMV contactless kernel execution Management of Phase 2 lifecycle (Deferred/Card-Free) Cardholder Verification Method (CVM) processing Execution of the Transaction State Machine Cryptogram generation and request assembly Directing acquisition host communications Delivery of initial Authorization Result (0100/0110) Issuing Capture (0220), Reversal (0420), or managing Expiry

The strategic triggers for utilizing manual capture are diverse but center on risk mitigation. For e-commerce, it ensures customers are only charged upon shipment. In hospitality and car rentals, it allows for a “pre-auth” at check-in followed by a final capture inclusive of incidentals at checkout. Furthermore, it provides a vital window for manual fraud review before a merchant commits to a financial charge. While this provides operational flexibility, it fundamentally shifts the burden of fund movement from the network to the merchant’s internal logic.

Successfully managing this bifurcation requires a rigorous understanding of the technical states a transaction must navigate once the initial authorization is secured and the cardholder has departed.

2. The Lifecycle State Machine: Navigating Transactional Transitions

Modeling the payment lifecycle as a formal state machine is a critical risk mitigation strategy. By defining explicit states, a system prevents logic fragmentation and ensures that every action taken—or omitted—results in a valid network message that complies with card scheme requirements. This centralized logic is mandatory because different transitions emit different message types and carry varying financial risks.

The AUTHORIZED Entry State and Exit Paths

The lifecycle begins in the AUTHORIZED state the moment an issuer approves a transaction and places a hold on the cardholder’s funds. From this entry point, there are four primary paths:

• Captured: The merchant instructs the acquirer to move the full authorized amount. This is the “happy path” terminal state, leading to clearing and settlement via an ISO 8583 0220-class advice message.
• Partially Captured: The merchant captures an amount less than the original authorization. Critically, a partial capture does not close the transaction; the “uncaptured remainder” must eventually navigate its own terminal state (Reversed or Expired) to release the residual hold.
• Reversed: The merchant actively cancels the transaction. This triggers a 0420 reversal message to the issuer, which releases the hold on the cardholder’s credit line immediately.
• Expired: The transaction reaches its terminal state passively. No network message is sent; the hold simply lapses when the issuer’s authorization window closes.

Gray Transitions: Reversed vs. Expired

The distinction between “Reversed” and “Expired” represents a significant operational risk. Reversing is an active choice; it is the intentional, clean exit that protects the customer experience by freeing funds immediately. In contrast, Expiration is passive. Allowing a transaction to expire is often the result of operational neglect. This leads to “phantom holds” where cardholders see a pending charge for days after an order is canceled, driving customer service friction and potential disputes.

These logical states do more than manage cardholder perception; they directly dictate the merchant’s cost of acceptance through interchange.

3. Financial Risk Analysis: Interchange Downgrades and Amount Mismatches

Card schemes are highly sensitive to the temporal and data integrity of a transaction. “Clean” captures—those that match the original authorization in timing and amount—are rewarded with optimal pricing. Deviations introduce immediate financial penalties in the form of interchange downgrades, which represent a non-refundable erosion of the merchant’s profit margin.

The Mechanics of Interchange Downgrades

Interchange downgrades occur when a transaction fails to meet specific scheme criteria, shifting it into a more expensive processing category.

1. Late Captures: Captures exceeding the permitted scheme or Merchant Category Code (MCC) window are flagged as high-risk, increasing processing costs.
2. Amount Mismatches: Schemes price based on how cleanly the capture matches the auth. Significant deviations (outside of permitted tolerances) signal inefficiency to the schemes and trigger higher fees.

Amount Guardrail Logic

To mitigate margin erosion, systems must implement “Amount Guardrail” logic at the state-machine boundary. The fundamental mandate is that the captured_amount must be less than or equal to the authorized_amount. Over-capture is strictly restricted to narrow scheme tolerances in specific sectors, such as restaurant tips or fuel pump adjustments. Attempting to over-capture outside these narrow windows will result in clearing rejections. By enforcing these guardrails in the backend, merchants avoid the operational cost of processing transactions destined for rejection.

These financial risks necessitate a deep understanding of the temporal constraints imposed by the card networks.

4. Operational Constraints: Authorization Expiry and Settlement Windows

An authorization is not a permanent guarantee of funds; it is a time-bound hold subject to rigorous scheme rules. Once that window closes, the merchant’s guarantee of payment disappears, and the transaction enters a high-risk “Expired” state.

Varying Expiry Windows

The duration of an authorization hold varies by MCC and card scheme. While 7 days is a common standard, many categories have shorter windows. If a capture instruction is not issued within this window, the hold drops.

The Burden of Authorization Lapses

When an authorization lapses, the merchant faces the risk of “Authorization Lapses.” If fulfillment has not occurred, the merchant may attempt a “re-authorization.” This is fundamentally riskier than the initial “Tap to Pay” interaction because the customer is no longer at the point of sale to re-present their card. This shifts the transaction into a “Card Not Present” (CNP) re-auth flow, which carries:

• Increased Decline Risk: The cardholder’s available balance or the issuer’s risk profile may have changed since the initial tap.
• Customer Friction: If the re-auth fails, the merchant must re-engage the customer, significantly increasing the likelihood of order abandonment.

5. Implementation Guardrails: Strategic Recommendations for Risk Mitigation

To manage these complexities, merchants must embed these rules as “compliance mandates” within the system’s state-machine boundary. Relying on manual intervention is insufficient for maintaining financial efficiency.

Non-Negotiable System Requirements

• Mandatory Idempotency: All capture requests and retries must be idempotent to prevent duplicate charges during network timeouts.
• Enforcement of Capture Windows: The system must track authorization age and trigger alerts or automated reversals before the expiry window lapses.
• Explicit State Distinction: Merchant dashboards must distinguish between AUTHORIZED (funds reserved) and CAPTURED (money moving). An “approved” auth must never be misrepresented as a completed payment.
• Automated Reversal Triggers: Systems must automatically trigger 0420 reversals for canceled orders or uncaptured remainders to release cardholder funds and prevent phantom holds.

Final Assessment: Flexibility vs. Complexity

Manual capture provides the flexibility to align payment collection with fulfillment, but it introduces significant operational and financial complexity. To manage this trade-off, a rigorous system design—centered on a formal transition table that defines behavior for every state change—is required to maintain a cost-effective payment ecosystem.

Decoding the Payment Lifecycle: A Beginner’s Guide to Transaction States

1. The Core Concept: Why Two Steps are Better Than One

In payment architecture, we distinguish between Auto Capture—where authorization and fund collection happen in one atomic action—and Manual Capture (also known as deferred or delayed capture). Manual capture is a strategic design pattern that splits a transaction into two distinct operational phases: Authorization and Capture.

This separation allows merchants to control the timing and finality of a charge, which is a business necessity in several high-stakes scenarios:

• E-commerce: To comply with consumer protection standards and manage inventory risk, merchants often authorize a payment at the time of the order but only capture funds when the physical goods are shipped.
• Hospitality & Travel: Hotels and car rental agencies use a “pre-auth” at check-in to reserve a base amount plus a buffer for incidentals. The final, actual cost is only captured upon checkout.
• Order Management & Fraud Review: High-risk merchants use the window between authorization and capture to perform manual fraud screening or stock verification, ensuring they only commit to a financial charge once the transaction is deemed safe and fulfillable.

Once we understand why we split a payment, we must look at the first action that happens at the point of sale.

2. Phase 1: Authorization (The “Digital Handshake”)

The Authorization phase occurs within the Acquisition Domain. This is the only part of the lifecycle where the physical card or digital wallet is required. For a Tap to Pay transaction, the payment SDK manages the interaction with the device’s NFC antenna and the EMV contactless kernel.

Technical rigor in this phase involves several critical steps:

• The NFC Read: Securely capturing card data from the chip or mobile wallet.
• EMV Processing: The kernel performs Cardholder Verification Methods (CVM) and generates an Authorization Request Cryptogram (ARQC) to ensure the transaction’s integrity.
• The Request: The system emits an ISO 8583 (0100/0110) message to the issuer to validate the account and risk profile.

What happens to the funds? During this phase, no money actually moves. Instead, the issuer places a “hold” on the cardholder’s funds. This “Digital Handshake” concludes when the SDK provides the merchant’s system with a set of “hand-off” artifacts: an Authorization Code (Auth Code), a Retrieval Reference Number (RRN), and the online outcome.

Once the “hold” is placed, the card is no longer needed, and the transaction enters a new lifecycle managed entirely by the merchant’s backend.

3. Phase 2: Capture (The “Money Mover”)

Phase 2 is a purely backend concern. There is a strict “architectural seam” here: once the card leaves the field, all subsequent actions are card-free. The transaction now lives as a record in the merchant’s transaction service, identified by the Auth Code and RRN received in Phase 1.

The Capture phase is the deliberate instruction to convert the “hold” into an actual transfer of money. The sequence typically follows this flow:

1. Merchant Trigger: A business event occurs—such as a package leaving the warehouse or a hotel guest checking out.
2. Capture Request: The merchant’s backend sends a capture instruction to the acquirer for an amount equal to or less than the authorized total.
3. Financial Movement: This triggers the clearing and settlement process, mapped to ISO 0220 (Advice) messages or inclusion in a settlement batch.

While “Capture” is the goal, an authorization can actually end in several different ways.

4. The State Machine: Four Paths from “Authorized”

To prevent fragmented data, architects model the transaction lifecycle as a state machine. When a transaction is in the Authorized state (the entry point after a successful Phase 1), there are exactly four exit paths.

State Name Action Required Impact on Funds Financial Message Emitted Captured (Full) Trigger capture for total authorized amount. Total funds move to merchant. ISO 0220 (Advice/Batch) Partially Captured Trigger capture for less than authorized amount. Part of funds move; remainder stays held. ISO 0220 (Against balance) Reversed Active cancellation of the transaction. Hold is released immediately. ISO 0420 (Reversal) Expired No action taken (Passive). Hold lapses after a set window. None (Passive lapse)

Terminal Logic for Partial Captures: It is critical to note that “Partially Captured” is often an intermediate state. The uncaptured remainder of the hold must eventually be handled. An architect must ensure the system advances that remainder to either “Reversed” (to free the funds immediately) or “Expired” (letting the balance lapse).

The most critical operational distinction for cardholder satisfaction is the difference between an active release and a passive lapse.

5. Critical Distinction: Reversed vs. Expired

There is a significant technical and psychological asymmetry between “Reversing” a transaction and letting it “Expire.”

Crucial Insight Reversed is a deliberate, active, and clean exit. By sending an ISO 0420 message, the merchant proactively tells the issuer to drop the hold. Expired is considered “neglect.” No message is sent; the merchant simply waits for the issuer’s internal timer to run out.

If a merchant fails to reverse a canceled order and lets it expire, the cardholder will see a “phantom hold” on their banking app. While the merchant has no intention of taking the money, the funds remain unavailable to the customer. This expiration window is typically 7 days, but it varies significantly based on Merchant Category Codes (MCC) and specific card scheme rules (e.g., travel-related MCCs may have longer windows than retail).

Summarizing the rules and constraints that keep these transitions in check helps ensure a healthy payment flow.

6. The Golden Rules of Transaction Management

Navigating the transaction lifecycle requires adhering to specific technical and financial constraints. Follow these “Pro-Tips” for professional-grade transaction management:

• The “Capture \le Authorization” Rule: You can almost always capture less than the authorized amount. However, capturing more (overcapture) is highly restricted and only permitted within narrow industry tolerances, such as restaurant tips.
• Interchange Downgrades: Timing and amount mismatches are costly. Card networks price transactions based on how cleanly the capture matches the authorization. “Messy” captures (delayed or mismatched amounts) often result in higher processing fees known as “downgrades.”
• Loss of Legal Guarantee: Once an authorization expires, the merchant loses the legal guarantee of funds. If you attempt to capture after expiry, the transaction may be declined, necessitating a re-authorization where the card is no longer present.
• Idempotency is Essential: All capture requests and retries must be idempotent. This ensures that network timeouts or retries do not result in a customer being charged twice for the same authorization.
• The Architecture Split: Remember that Tap to Pay determines how a card is accepted at the edge, but the state machine determines when the merchant actually gets paid.

An “Approved” transaction is a beginning, not an end; the journey to settlement requires careful management of the states that follow.

What does “manual capture” mean in card payments—and how does it work with Tap to Pay?

The name can be misleading.

Manual capture does not mean typing the card number manually.

It means separating a payment into two distinct stages:

1. Authorization

The customer presents their card or digital wallet.

The issuer verifies the account, available funds, risk controls, and cardholder verification. If approved, the amount is reserved—but the merchant has not yet completed the charge.

2. Capture

Later, the merchant confirms how much of the authorized amount should actually be collected.

This creates a simple lifecycle:

Customer taps ↓ Payment is authorized ↓ Funds are temporarily reserved ↓ Merchant fulfils the order or confirms the final amount ↓ Backend sends the capture request ↓ Transaction proceeds toward clearing and settlement

Why separate the two?

Consider a hotel that authorizes an estimated amount at check-in but captures the final bill at checkout.

Or a rental company that verifies funds before handing over a vehicle.

It can also help merchants that want to authorize an in-person order immediately but capture it only after confirming stock, completing a service, or preparing the goods.

So how does this map to Tap to Pay?

Tap to Pay changes the acceptance device, not the underlying authorization-and-capture model.

Instead of presenting the card to a traditional payment terminal, the customer presents it to an NFC-enabled phone running a certified payment application.

The phone and payment SDK handle the card-present interaction:

• contactless card reading;
• EMV processing;
• cardholder verification when required;
• secure transmission of the payment data;
• delivery of the authorization result.

When manual capture is configured, an approved Tap to Pay transaction is then stored by the payment platform in an authorized-but-not-captured state.

The later capture normally happens through the merchant application or backend—not by asking the customer to tap again.

That distinction is important:

Tap to Pay answers: How is the card accepted?

Manual capture answers: When does the merchant complete the financial charge?

They belong to different layers of the payment architecture, but they can work together.

There are also several operational rules to design for:

• the authorization does not remain valid indefinitely;
• capture must occur within the permitted window;
• some cards, payment methods, networks, and regions may not support delayed capture;
• the final captured amount may be lower than the authorized amount;
• an authorization that will not be captured should be cancelled or reversed;
• retries and capture requests must be idempotent;
• the merchant UI must distinguish AUTHORIZED from CAPTURED.

An “approved” Tap to Pay transaction is therefore not necessarily a completed payment.

Sometimes it only means:

The issuer has reserved the funds. The merchant must still capture them.

Would manual capture improve your payment flow—or introduce unnecessary operational complexity?

#Payments #TapToPay #SoftPOS #EMV #FinTech #PaymentArchitecture