Card Auth Expiry: Visa vs Mastercard Capture Rules

Four major PSPs give four different answers to one question: how long can I hold a customer-initiated Visa authorisation online before I have to capture it? Stripe says 7 days, Braintree 8, Adyen 10, and Checkout.com says 7 on one page and 10 on another. Visa's own rulebook says 10. If your order service has CAPTURE_DEADLINE_DAYS = 7 somewhere in a config file, that constant came from one PSP's docs page, not from the card schemes, and it is wrong for about half the transaction types you probably process.

Most of the pages ranking for "how long does an authorization hold last" answer with a range: "a few days to a week", "up to 30 days". This guide works from the primary sources instead: the Visa Core Rules dated 18 April 2026, Mastercard's Transaction Processing Rules (December 2025 edition), the American Express merchant rules, and the API docs of Stripe, Adyen, Checkout.com and Braintree as they stand in September 2026.

How Long Does a Card Authorisation Hold Last?

It depends on three things: the scheme, the authorisation type you asked for, and who initiated the payment. The scheme sets the rule. Your PSP then usually applies a shorter window of its own, and the issuer releases the hold on the cardholder's side on its own schedule.

The short version, by scheme rule:

Discover publishes no public rulebook. Stripe and Adyen both document 7 to 10 days for card-not-present, so treat it as 7 unless your acquirer tells you otherwise.

Visa Authorisation Validity Periods Since April 2024

On 13 April 2024 Visa merged two separate clocks, authorisation validity and the clearing deadline, into one "authorization-to-clearing time frame" (Visa Business News AI13522, October 2023). The current numbers sit in Table 5-12 of the Core Rules, section 5.7.3.5. Every window starts from the date of the approval:

• 30 days: cardholder-initiated card-not-present with an extended authorisation indicator; estimated authorisations at cruise lines, lodging and vehicle rental (Visa defines the last as MCCs 3351–3500, 7512 and 7513).
• 10 days: cardholder-initiated card-not-present; estimated authorisations at a second tier of rental merchants (aircraft, boats, bicycles and e-scooters, equipment, furniture, motorhomes, campgrounds).
• 5 days: all other card-present, and every merchant-initiated transaction (instalment, recurring, unscheduled card-on-file).

Table 5-13 then carves out country exceptions that matter if you acquire outside the UK: Japan domestic gets 30 days, India domestic untokenised card-not-present gets 2, and in Europe intraregional contactless must clear within 2 calendar days, with mobility and transport exempt. Fuel dispensers (MCC 5542) are the extreme case: complete or reverse within 2 hours.

The detail most people miss: the merchant-initiated window is half the customer-initiated one. If you take a card-on-file payment with an MIT flag, for a subscription top-up or a delayed marketplace charge, you have 5 days, not 10. Stripe implements that as exactly 4 days and 18 hours.

Mastercard Pre-Authorisation vs Final Authorisation

Mastercard's model is simpler to state and easier to get wrong. There are now two authorisation types that matter:

• Pre-authorisation (TPR 2.5): clearing must be presented "within 30 calendar days". In Europe, Maestro and ATM pre-auths get only 7.
• Final authorisation (TPR 2.7): clear within seven calendar days, and "the presented Transaction amount must equal the authorized amount". In Europe a final auth "must not be reversed" except at the cardholder's request or on a technical failure.

The trap is the equality rule on final auth. Adyen and Checkout.com both default to final authorisation. If you authorise £80 as final and then capture £72 because an item was out of stock, you have broken the rule; the US fee schedule I found (Fiserv, April 2026) prices that at 0.25% of the amount, minimum $0.04. The fix is either to request a pre-authorisation when the amount might change, or to accept the fee on edge cases. What you should not do is leave every authorisation typed as final by default when you run a partial-shipment business.

Estimated vs Incremental Authorisation: What Resets the Clock?

This is where Visa and Mastercard genuinely diverge, and where most PSP docs go vague.

The PSP APIs expose this asymmetry directly:

Note the semantic split. Stripe, Adyen and Braintree take the new total. Checkout.com takes the delta. If you are abstracting over more than one PSP, that difference is a double-charge waiting to happen, and it belongs in a unit test.

Adyen's extend-by-same-amount trick carries one sharp edge: its docs warn that if the issuer declines the extension, "this ends the initially authorized payment". An extension request can cost you the hold you already had.

Stripe vs Adyen vs Checkout.com vs Braintree: Capture Windows Compared

Here is what each PSP actually documents for the default hold, next to the scheme rule:

The PSP numbers are shorter because a capture is not a clearing record. The PSP batches captures, submits them to the acquirer, and the acquirer presents them to the scheme. Each hop takes time, so the PSP deducts a buffer. Stripe's 4 days 18 hours for Visa MIT and 29 days 18 hours for Visa extended auth are the visible edge of that buffer.

Two PSP behaviours are worth knowing before you choose:

• Stripe needs opt-ins for everything beyond 7 days: request_extended_authorization, request_incremental_authorization, request_multicapture and request_overcapture, all set to if_available. Extended auth, multicapture and overcapture require IC+ pricing. Outside travel and lodging, Visa extended auth costs an extra 0.08% per transaction and only works on CIT.
• Adyen expires pre-authorisations on its own platform after 28 days by default, two days shorter than the 30-day scheme windows in its own table. Support can change that per merchant account.

What Happens When an Authorisation Expires?

Three different things happen, in three different systems, not always at the same time.

Stripe       status=canceled, webhook charge.expired
             expiry timestamp in payment_method_details.card.capture_before
Adyen        EXPIRE webhook (success always true)
             capture on an expired auth -> CAPTURE_FAILED, "Transaction is expired"
Checkout.com expiry timestamp in expires_on on the increment response
Braintree    status=authorization_expired (no dedicated webhook documented)

The right move after expiry is almost always a fresh authorisation, flagged as merchant-initiated with the original network transaction ID, if the customer agreed to card-on-file terms. In the UK and EEA that MIT flag is also what keeps the new attempt out of SCA scope; see the SCA exemptions guide for why. If the re-auth declines, it falls under Visa's retry categories like any other decline.

Authorisation Reversal Rules and Misuse of Authorisation Fees

Letting a hold expire quietly is not free. Both schemes require an active reversal.

The fees for getting it wrong are published per acquirer, not by the schemes, and the only current schedule I could verify is US-only (Fiserv, April 2026):

UK acquirers pass through equivalents, but I have not found a public GBP schedule, so check your own interchange-plus statement for the line items. On Stripe you void an uncaptured PaymentIntent with POST /v1/payment_intents/{id}/cancel; on Adyen it is /cancels, Checkout.com /voids, Braintree transaction.void. Each of those sends the reversal for you.

Should You Hard-Code a 7-Day Capture Window?

No. My position: the capture deadline is data, not configuration, and your system should read it from every authorisation response.

Stripe gives you capture_before. Checkout.com gives you expires_on. Adyen and Braintree make you derive it, which is worse, but you can still compute it once at authorisation time from scheme, type and initiator, and store it alongside the payment. A per-payment capture_deadline column, indexed, with a scheduler that captures or voids 12 hours before it, handles every row of the tables above. A global constant handles one row.

I have seen the constant approach fail both ways. Set it to 7 and your Visa MIT captures land after the 5-day window, producing 11.3 exposure on your whole card-on-file book. Set it to 10 because "Visa gives 10" and your Mastercard final auths clear late on days 8 to 10, paying the processing integrity fee on every one.

I also expect the gap between scheme rules and PSP defaults to widen, not close. Stripe already ships automatic_delayed capture in private preview, which captures "about 6 hours before the expiry time" with capture_by: auth_expiry. Once the PSP owns the deadline, it will tune its buffer for its own batching, not your fulfilment SLA. That is fine as long as you read the timestamp and never assume it.

What This Means for Payment Engineers in the UK

1. Store a deadline per payment. Populate it from capture_before (Stripe) or expires_on (Checkout.com), or derive it from scheme + auth type + CIT/MIT. Never from a global constant. 2. Choose the auth type deliberately. Final auth for fixed-amount checkout. Pre-auth or estimated auth where the amount can move: hotels, car hire, grocery substitutions, split shipments. Mastercard's equality rule on final auth is the most common silent fee. 3. Test increment semantics per PSP. Checkout.com adds the amount you send; Stripe, Adyen and Braintree set a new total. And only Mastercard increments extend the clock. 4. Void explicitly within 24 hours of cancellation. Both schemes require it. An expiring hold is a fee, not a clean-up strategy. 5. Treat expiry as a re-auth trigger. Re-authorise as MIT with the original network transaction ID rather than capturing late into a Visa 11.3 chargeback. 6. Watch the European exceptions. Visa intraregional contactless clears in 2 days, and a Mastercard final auth in Europe cannot be reversed except at the cardholder's request.

The scheme tables change roughly once every few years, and the last big shift was April 2024. PSP defaults change whenever the PSP feels like it. Build against the timestamp and you only need to care about the first. If you are working through adjacent problems, the idempotency keys guide covers the other half of making capture jobs safe to retry. More from Tom Wang on payments engineering is on the homepage.