How Force Capture Works
Force capture breaks the standard two-step authorization-then-capture flow. Instead of the gateway issuing an electronic authorization request and receiving a real-time approval code, the merchant supplies an authorization code they obtained through an alternative channel—most commonly a voice call to the issuer's authorization line. The gateway then bypasses the authorization step entirely and submits the capture directly to the acquirer for settlement.
Merchant encounters an authorization failure or outage
The standard electronic authorization path is unavailable or has failed—either because the payment terminal is offline, the authorization request timed out, or the issuer's system returned an error that prompts the merchant to seek manual approval.
Merchant calls the issuer's voice authorization line
The merchant dials the card network's or issuer's voice authorization number, provides card details and the transaction amount, and waits for a live operator to review the account. This process is described in detail under voice authorization.
Issuer provides a manual authorization code
If the issuer approves, they read out a six-digit alphanumeric authorization code. The merchant records this code—it is the only proof of approval and must be retained for dispute resolution.
Merchant enters the force capture in the POS or gateway
The merchant navigates to the force sale or offline transaction function in their point-of-sale system or gateway dashboard, enters the card details, amount, and the authorization code received from the issuer.
Gateway routes the capture directly to the acquirer
Unlike a standard capture, the gateway does not attempt an authorization call. It packages the transaction with the provided code and submits it straight to the settlement batch. The acquirer forwards it to the card network and issuer for final clearing.
Transaction settles and funds are deposited
Provided the authorization code is valid and the account has sufficient funds at settlement time, the transaction clears normally. If the code is stale, incorrect, or the account has since been closed, the transaction will fail in post-settlement editing and generate a return.
Why Force Capture Matters
Force capture is a critical fallback mechanism that keeps commerce moving when electronic systems fail. For merchants operating in environments with unreliable connectivity—hospitality, outdoor events, trade shows, or regions with poor network infrastructure—it can mean the difference between completing a sale and losing revenue.
The scale of offline and voice-authorized transactions is not trivial. According to Visa's merchant operations guidance, connectivity failures during peak transaction periods can affect up to 3–5% of terminal-based transactions in high-traffic retail environments, making fallback procedures like force capture operationally significant. Mastercard's acquirer compliance data indicates that merchants without properly documented offline authorization procedures experience chargeback dispute loss rates 2.4× higher than those with formal protocols in place. Additionally, industry payment operations reports estimate that over 60% of force capture misuse incidents are unintentional—caused by staff unfamiliarity with when the feature is appropriate—underscoring the importance of merchant training.
Authorization Code Retention
Visa and Mastercard both require merchants to retain voice authorization codes for a minimum of 18 months. These codes are your primary evidence in a chargeback dispute involving a force capture transaction. Store them alongside the transaction record in your order management system.
Force Capture vs. Standard Authorization-Capture
Force capture and the standard authorization flow are fundamentally different in how risk is allocated and how fraud signals are applied. Understanding these differences is essential before enabling force capture in any integration.
| Dimension | Standard Auth + Capture | Force Capture |
|---|---|---|
| Authorization method | Real-time electronic via gateway | Manual / voice / offline code |
| Fraud signals applied | AVS, CVV, 3-D Secure, velocity checks | None at authorization time |
| Issuer hold placed | Yes — funds reserved immediately | No hold; issuer only sees capture |
| Chargeback liability | Issuer bears more if 3DS passed | Merchant bears higher liability |
| Gateway API call | Two calls: auth then capture | One call: capture only |
| Use case | Standard ecommerce and POS | Outages, voice auth, offline terminals |
| Network compliance requirement | Standard | Requires documented approval code |
| Risk of declined settlement | Low (auth already confirmed) | Higher (funds may have changed) |
Types of Force Capture
Force capture is not a single, monolithic transaction type. It surfaces in several distinct operational scenarios, each with different compliance requirements.
Voice Authorization Force Capture is the most common and most legitimate form. The merchant calls the issuer directly, receives a verbal approval code, and forces the capture using that code. This is explicitly supported by Visa and Mastercard operating regulations as a fallback for electronic authorization failures.
Offline Terminal Capture occurs when a chip-and-PIN or contactless terminal operates in stand-in mode during a connectivity outage. The terminal applies its own floor limit logic—configured by the acquirer—and generates a local approval. When connectivity is restored, the terminal uploads the offline transaction batch, which is processed as a force capture against the acquirer.
Recurring Billing Force Capture is sometimes used when a previously stored credential authorization has expired and the merchant cannot reach the cardholder for a new authorization. This is a high-risk use case and generally non-compliant unless the merchant has explicit contractual terms allowing it.
POS System Recovery Capture happens when a system crash or power failure interrupts a transaction after the card was swiped but before the authorization was electronically confirmed. If the merchant has a printed receipt with an approval code from before the crash, they may force-post the capture during recovery.
Best Practices
Force capture carries real risk and should be governed by clear internal policies. The following practices apply differently depending on your role.
For Merchants
Document every voice authorization code at the moment it is received, alongside the operator name, time, and transaction amount. Never use force capture on a card that was electronically declined—a decline means the issuer refused the transaction, and forcing a capture on a declined card violates card network rules and constitutes fraud. Train all staff on the narrow set of legitimate scenarios. Audit your force capture volume monthly; a rising rate signals either a system problem or a compliance issue. Always capture for the exact amount that was verbally authorized—capturing a higher amount voids the authorization code and will likely result in a chargeback.
For Developers
Expose force capture only to explicitly authorized merchant accounts and require a non-empty authorization code field—never allow blank or placeholder codes to pass validation. Log all force capture transactions separately from standard captures in your data model, flagging them for compliance review. Build rate alerts so that if force captures exceed a configurable threshold (e.g., 1% of daily volume), your operations team is notified. When integrating with acquirer APIs, map force capture to the correct transaction type code—using the wrong code can result in the transaction being misclassified during clearing. Reference the card network's offline transaction specs (Visa Transaction Advisor, Mastercard Stand-In Processing) when implementing terminal fallback logic.
Common Mistakes
Using force capture on electronically declined cards. A decline is an issuer decision, not a system error. Forcing a capture after a decline bypasses that decision and is a violation of card network operating rules. This is the most common and most penalized misuse.
Capturing an amount different from the authorized amount. Voice authorization codes are issued for a specific amount. Capturing more than that amount—even by a small margin—invalidates the code and eliminates your chargeback defense.
Failing to record the authorization code. Without a valid authorization code on file, you cannot defend a chargeback claiming "no authorization." Many merchants lose these disputes simply because the code was never saved in the transaction record.
Using expired authorization codes. Voice authorization codes are time-limited, typically valid for the business day they were issued. Using a code from a previous day risks a failed settlement and a potential compliance finding from your acquirer.
Treating force capture as a routine fallback for any authorization problem. Force capture is a last resort for genuine system failures with issuer-confirmed approval. Using it to work around card limits, suspicious declines, or expired cards exposes the merchant to fraud liability and account termination.
Force Capture and Tagada
Force capture scenarios are a practical concern for any payment orchestration layer. When Tagada routes transactions across multiple acquirers and processors, it needs to correctly handle offline-originated captures so they settle through the same acquirer that issued the original voice authorization code—mixing the authorization acquirer with a different capture acquirer will cause the transaction to fail in clearing.
Routing Force Captures in Tagada
When submitting a force capture through Tagada's orchestration layer, always include the authorization_code and set the transaction type to force_capture in the request payload. Tagada uses the acquirer ID embedded in the authorization code to route the capture to the correct processor, preventing cross-acquirer settlement mismatches that would cause a failed clearing cycle.
Tagada's compliance monitoring surfaces force capture transactions in a dedicated reporting view, making it straightforward to track volume by merchant, flag anomalies, and generate the documentation needed for acquirer audits. For merchants managing high-volume offline environments—hospitality groups, festival operators, or multi-location retail—this visibility is a key operational control.