Estimated and Incremental Authorizations: The Rules

Estimated authorizations let you hold an amount before you know the final total, and incremental authorizations let you top that hold up as the total grows. Hotels, car rental firms and cruise lines run on both. The rules around them are narrower than most merchants operating them realise.

They sit in sections 5.7.2.4 and 5.7.2.5 of the Visa Core Rules and Visa Product and Service Rules (18 April 2026), and the single most-broken requirement is about what you're not allowed to include in the number.

You Cannot Pad the Hold#

An estimated authorization amount has to be "a genuine estimation of what the Cardholder will spend" (ID# 0030936). Then the rules list what it must exclude:

"The Estimated Authorization Request does not include any amount covering potential damage, theft, other delayed charges, insurance premiums, or tips."

That rules out the padding a lot of properties treat as standard. Adding a cushion for incidentals, a damage buffer, or an anticipated tip to the authorization is not permitted. The hold is for the estimated spend, and nothing else.

The same exclusion carries into incremental requests, which "must not include any amount covering potential damage, theft or insurance premiums" (ID# 0030937).

There's one carve-out: a vehicle rental merchant using the Vehicle Rental Merchant Asset Protection Program isn't bound by the genuine-estimate requirement.

Telling the Cardholder Is Mandatory#

You must notify the cardholder of the estimated authorization amount, and that further authorization requests may follow.

Not a line in terms and conditions somewhere. A notification of the specific amount you're holding and the fact that it may grow.

This is the requirement that quietly prevents disputes. A guest who was told a $400 hold may increase doesn't call their bank when it becomes $600. One who discovers it on their app does.

The Flags Have to Be Right#

Three mechanical requirements decide whether these transactions are processed correctly:

• An estimated authorization request must carry the Estimated Authorization Indicator.
• An incremental request must carry the Incremental Authorization indicator and the same Transaction Identifier as the original estimated authorization, which is what links the two together.
• A single authorization request must never contain both indicators.

That Transaction Identifier link is worth checking with your gateway. If increments arrive detached from the original estimate, they read as separate authorizations rather than one growing hold, and the total held against the cardholder looks very different from what you intended.

Where Estimated Authorizations Are Banned Outright#

You may not submit an estimated authorization request for any of the following:

• Account funding transactions
• Cash disbursements, whether manual or through an ATM
• Installment transactions
• Advance payments
• Recurring transactions
• Quasi-cash transactions

If you run stored credential billing, note that recurring transactions are on that list. An estimated authorization is not a mechanism for a subscription whose amount varies.

Incrementals Need an Approved Estimate First#

An incremental authorization is only available "where it has obtained an Approval Response for a valid Estimated Authorization," and only when the original estimate is no longer enough to cover a revised estimate or the final amount.

So the sequence matters. You can't start with an ordinary authorization and increment it later. The first request has to be a properly flagged estimated authorization that came back approved.

Fuel Dispensers Work Differently#

Automated fuel dispensers run on their own model. An AFD transaction is processed as either a status check authorization or an initial authorization request, and in that flow the merchant is not required to submit the estimated authorization indicator and must not submit an incremental authorization request at all.

There's also a hard clock: the merchant must send the issuer a completion message or acquirer confirmation advice with the final amount "as soon as possible and, at most, within 2 hours" of the transaction completing.

Delayed Charges Are Restricted by Merchant Type#

A delayed charge is a separate mechanism, and not every business can use one. Section 5.8.8.3 limits amended amounts and delayed charges to a defined list:

• Lodging merchants
• Vehicle rental, motorcycle rental, aircraft rental, and bicycle rental merchants
• Cruise lines
• Boat rentals and leasing (MCC 4457)
• Motor home and RV rentals (MCC 7519)
• Trailer parks and campgrounds (MCC 7033)
• Equipment, tool, furniture and appliance rental and leasing (MCC 7394)
• Clothing rental, costumes, uniforms, formal wear (MCC 7296)

If your MCC isn't on that list, delayed charges aren't a tool available to you, whatever your billing system offers.

Charging for Damage Carries a Documentation Burden#

This is the part worth reading before you bill a guest for a damaged room or a scratched bumper.

For a delayed charge covering loss, theft or damage, the charge must be the actual cost of replacement or repair, or the insurance deductible, whichever is less. An advance payment can't be used to pay for damage, theft, or loss of use.

And you must provide your acquirer with all of the following:

• A copy of the rental agreement
• An estimate of the damage cost from an organization that can legally provide repairs
• The relevant civil authority's accident report, where applicable
• Documentation showing the cardholder consented to a delayed charge being processed on their credential for damages

That consent has a specific form. It's either the cardholder's signature on the same page as, and close to, the description of the charges a delayed charge may cover, or their signature on the agreement plus their initials on every page including that one.

A signature buried on the last page of a rental agreement whose damage terms appear on page three does not meet this. That's a document design problem, and it's one you can fix before you ever need to rely on it.