How Pre-Authorization Works
Pre-authorization is a two-step payment flow that separates reserving funds from collecting them. When a cardholder presents their card, the merchant sends an authorization request that locks a specified amount against the card's available balance — but does not debit the account. The charge only settles when the merchant submits a capture request, typically after the service has been delivered or the final amount is known.
Authorization request submitted
The merchant's terminal or payment gateway sends an authorization request to the card network — Visa, Mastercard, or Amex — specifying the hold amount. The request includes card credentials, merchant ID, and the amount to reserve.
Issuing bank evaluates the request
The cardholder's bank checks available funds or credit, applies fraud scoring, and returns an approval or decline code. An approval immediately places a hold on the specified amount, reducing the cardholder's available balance without any funds transferring.
Merchant delivers goods or services
With the payment path secured, the merchant fulfills the order — checking in the hotel guest, handing over the rental car, or dispatching the shipment. The authorization code is retained and linked to the pending transaction.
Final amount confirmed and captured
Once the exact amount is known, the merchant submits a capture request. The captured figure can differ from the original hold within network-permitted tolerances. The transaction then moves into settlement and the funds transfer to the merchant's account.
Hold released or authorization expires
If the merchant never captures — or sends an explicit void — the issuing bank returns the reserved funds to the cardholder's available balance. Card networks enforce automatic expiry between 7 and 30 days depending on merchant category code, after which the hold dissolves without merchant action.
Why Pre-Authorization Matters
Pre-authorization underpins billions of transactions across hospitality, mobility, fuel retail, and ecommerce every year. Its importance goes beyond operational convenience — it is a critical risk management tool that determines whether merchants get paid and whether cardholders trust the payment experience.
Visa's global rules require that pre-authorizations for lodging and vehicle rental be captured within 30 days of the original authorization date. For all other card-present categories, the standard window is 7 days — after which the hold expires and merchants must re-authorize. Industry benchmarking data consistently shows that authorization approval rates drop 2–4 percentage points on re-authorization attempts after an expired hold, because the cardholder may have spent or blocked the funds in the interim. That decline rate translates directly into missed revenue for merchants who do not manage expiry windows proactively.
In fuel retail, petrol stations typically pre-authorize between $1 and $175 — the ceiling varies by operator and network rules — before dispensing a single litre. The station then sends a completion message with the actual pump total. For hotels, the average incidental hold runs 15–25% above the room rate, meaning a $500 booking may temporarily tie up $575–$625 of a guest's available credit. Pre-authorization also functions as an early fraud filter: a declined hold surfaces card problems — insufficient funds, a flagged account, or velocity breaches — before goods are released, unlike a chargeback that arrives weeks after delivery.
Pre-Authorization vs. Authorization Hold
Pre-authorization and authorization hold are closely related — often used interchangeably in casual conversation — but the distinction matters for accounting, dispute management, and integration design.
| Dimension | Pre-Authorization | Authorization Hold |
|---|---|---|
| Initiated by | Merchant, as a deliberate payment step | Issuing bank or network, sometimes automatically |
| Amount flexibility | Merchant sets the hold; can adjust at capture | Fixed at authorization time |
| Primary use case | Hotels, rentals, fuel, custom-order ecommerce | Fraud holds, balance verification, account blocks |
| Capture required | Yes — explicit capture call needed to settle | May auto-settle or auto-release on a bank schedule |
| Duration | 7–30 days governed by network rules | Varies; fraud holds can persist longer |
| Cardholder visibility | Appears as "pending" in most banking apps | Often labeled "hold" or flagged without a merchant name |
| Merchant control | Full — merchant releases, increments, or captures | Limited — bank controls release conditions |
The practical difference: a pre-authorization is a deliberate merchant tool built into the payment flow, while an authorization hold can be applied unilaterally by the issuing bank under fraud or compliance conditions that the merchant has no visibility into.
Types of Pre-Authorization
Pre-authorization is not a single fixed mechanism. It appears in several distinct forms depending on the industry, the timing of the transaction, and what is known about the final amount at the point of sale.
Incremental authorization allows merchants to increase a hold after the initial pre-auth. Hotels use this when a guest extends their stay or accumulates significant ancillary charges. Visa and Mastercard both support incremental auth for lodging, vehicle rental, and cruise lines — provided the merchant submits an incremental authorization message rather than a second full authorization.
Estimated authorization is used when the final amount is genuinely unknown at service initiation. Gas pumps and ride-hailing apps are the clearest examples: the merchant pre-authorizes a ceiling, then captures the actual cost once the service completes.
Zero-dollar authorization is a related technique that validates card details without reserving any funds. SaaS and subscription businesses use it at account creation to confirm the card is active and the billing address is correct before the first billing cycle runs.
Delayed capture is the standard hotel and car rental pattern: authorize at check-in or vehicle pick-up, capture at check-out or vehicle return — with up to 30 days between the two events for qualifying merchant categories.
Best Practices
Effective pre-authorization requires alignment between business operations and payment engineering. Poorly managed holds generate disputes, cardholder complaints, and silent revenue loss that rarely appears in top-line reports.
For Merchants
Set hold amounts that reflect your realistic exposure — not an arbitrary round number. Over-holding frustrates customers and can push borderline cardholders into a decline, especially when they have limited available credit. Under-holding leaves you exposed if the final bill exceeds the original auth tolerance and forces a second authorization request. Work with your payment provider to understand the network tolerance rules applicable to your MCC before setting default hold values.
Monitor authorization age actively. Build operational checkpoints that flag any open pre-auth approaching its expiry window, and trigger a re-authorization before the hold lapses. This is especially critical for hospitality operations where guest stays can extend unexpectedly. Release holds promptly on cancellations — a hold that lingers past the cancellation point is one of the highest-volume sources of cardholder complaints and avoidable bank inquiries.
For Developers
Implement authorize and capture as separate API calls from day one, even if your current business model does not require delayed capture. Some payment gateways default to immediate capture (auth_and_capture mode) — explicitly configure manual capture in your gateway settings and verify the behavior in your test environment before going live.
Store the authorization code, the authorized amount, and the authorization timestamp on every transaction record. Without the timestamp, you cannot programmatically track expiry windows or trigger re-authorization. Subscribe to webhook events for authorization expiry and issuer reversals — an expired auth that your system still considers valid will produce a cryptic decline code on capture, which is harder to debug without the event log. Handle partial captures explicitly: confirm your gateway passes the exact capture amount rather than defaulting to the full authorized figure, and log the delta for reconciliation.
Common Mistakes
Even experienced payment teams make avoidable errors with pre-authorization that surface as failed captures, cardholder disputes, and finance reconciliation gaps.
1. Treating all pre-auths as having a 7-day life. The 7-day window applies to most card-present categories, but lodging and vehicle rental merchants have up to 30 days. Building a single expiry rule across all transaction types will cause premature re-authorization attempts for hospitality bookings and unnecessary API calls.
2. Capturing outside the network tolerance band. Attempting to capture 40% more than the original hold without sending an incremental authorization request first often results in a soft decline or a mismatched settlement. Both outcomes increase dispute risk and can trigger issuer reviews of your merchant account.
3. Failing to release holds on cancellations. If a customer cancels and you do not send an explicit void or reversal, the cardholder's funds remain locked until the network expiry clock runs out. This is the single most common source of cardholder complaints in the hotel sector and generates support costs that far exceed the transaction value.
4. Using one authorization code across multiple capture events without network-permitted multi-capture. Some merchants attempt to split a single authorization across multiple shipments by capturing partial amounts against the same auth code. Outside of explicitly supported partial shipment flows, most networks prohibit this. Each distinct fulfillment event typically requires its own authorization.
5. Not logging authorization response codes and timestamps. Without these records, diagnosing capture failures, reconstructing the payment lifecycle for dispute responses, and auditing expired holds becomes guesswork. Every authorization event should write the response code, approval code, and timestamp to a durable store immediately on receipt.
Pre-Authorization and Tagada
Tagada's payment orchestration layer manages pre-authorization flows across multiple PSPs and card networks from a single API, removing the need to implement gateway-specific auth/capture logic for every processor in your stack.
Route pre-auth and capture across processors independently
With Tagada, you can authorize through your primary PSP and route the capture to a secondary processor if the primary is unavailable — without re-authorizing the card. Authorization state, expiry timestamps, and incremental auth history are maintained centrally. Re-authorization triggers fire automatically based on configurable expiry rules, so your team does not need to build or monitor expiry logic at the application layer.
This architecture is particularly valuable for merchants operating across multiple geographies, where the optimal capture processor may differ from the authorization processor due to interchange cost optimization, local acquiring relationships, or regional latency requirements.