Pre-Authorization Holds: Reserving More Than You Charge | HL Hunt
Pre-Authorization Holds: Reserving More Than You Charge
A pre-authorization reserves funds before the final amount is known, which means it almost always reserves too much. A $340 estimate authorized at 120% holds $408 against a final charge of $295, leaving $113 of the customer’s money unavailable. At 600 transactions a month that is about $67,800 held at any one time, none of it owed to you, and failing to release it promptly is the source of nearly every dispute and support call the practice generates.
What you'll learn
Why the hold exceeds the charge
A pre-authorization reserves funds before the final amount is known. A hotel does not know the minibar total, a fuel pump does not know the fill, a repair shop does not know what it will find. So the merchant authorizes an estimate, usually with a margin, and settles for the real figure later.
The margin is the problem. Take a service estimate of $340 authorized at 120%:
- Amount held: $408
- Final charge: $295
- Excess held: $113
Per our authorization analysis, the capture settles at $295, and the $408 hold does not disappear at that moment unless it is explicitly released. Until then the customer has $113 of their own money unavailable against a purchase that cost less than they expected.
That figure reframes the practice. A pre-authorization margin is not a free safety buffer. It is a large volume of other people's money sitting idle at your request, and per our latency analysis the cost of that falls entirely on whichever customer has the least headroom.
What it costs the customer
The harm is concentrated, not spread, which is what makes it a conduct question rather than an inconvenience.
- A customer with a $60 buffer and a $408 hold against a $295 charge can overdraft on a purchase they could afford. Per our overdraft analysis, a $35 fee on that is a charge created by your authorization practice rather than by their spending.
- Available credit is reduced, which can cause an unrelated transaction to decline, per our declines analysis.
- The hold is invisible in most banking apps as anything other than a pending charge for the wrong amount, so the customer sees an overcharge.
- Debit cards are worse than credit cards here, because the funds are actually unavailable rather than notionally so.
- It arrives without warning unless you disclosed the margin, which almost nobody does.
The first bullet is the one worth sitting with. The customer was right about what they could afford. The authorization margin made them wrong, and the fee lands on them.
The dispute you will lose
A pending charge larger than the agreed amount is among the easiest disputes for a customer to raise and the hardest to defend, because on its face the record shows you authorized more than you were owed.
| Situation | Defensibility |
|---|---|
| Hold released promptly after capture | Strong; the record shows the correct final amount |
| Hold still live days after capture | Weak; it looks like a duplicate charge, per our chargeback analysis |
| Margin not disclosed at the point of authorization | Weak; per our consent analysis, undisclosed is unagreed |
| Incremental authorizations without notice | Weak, and it also looks like repeated charges |
| Abandoned transaction, hold never reversed | Indefensible, and per our split payment analysis it is the same failure as an unreversed leg |
The second row is the common one and the entirely avoidable one. An authorization reversal costs nothing and takes one call to the processor. The reason it does not happen is that it sits in a cleanup process rather than in the capture path, so it runs late or not at all when something errors.
The last row is the one with the worst ratio. A customer who walked away from a service they did not buy, left holding a reservation against their account, will dispute it, will win, and the dispute counts against your ratio. Per our account review analysis, that ratio is what drives processor reviews, and inflating it with holds on transactions that generated no revenue is the worst available trade.
Sizing the margin honestly
The margin exists to cover the gap between estimate and actual. The right size is a question your own data answers.
- Measure your own overrun distribution. What share of jobs exceed the estimate, and by how much? Most businesses assume rather than measure this.
- Set the margin at a high percentile of actual overruns, not at a round number. If 95% of jobs come in within 8% of estimate, a 20% margin is holding more than twice what it needs to.
- Prefer an incremental authorization to a large initial one where the rails support it. Authorize the estimate and add to it if the work grows, which per our authorization analysis holds less for less time.
- Authorize a nominal amount where you only need the card on file, per our stored credential analysis, rather than reserving the full expected value.
- Vary the margin by job type. A diagnostic has a wide distribution and a scheduled service does not.
Item two is where almost every operation is holding too much. A 20% margin is a convention rather than a calculation, and replacing it with your own 95th percentile typically cuts the held amount substantially without increasing the number of transactions that come in short.
Item one has a secondary benefit worth noting. Per our quoting analysis, the overrun distribution you need for this is the same figure that should be feeding your estimates, so computing it once improves both.
The release is the whole obligation
Everything else in this article is optimization. Releasing the unused portion of an authorization immediately on capture is the non-negotiable part: it costs nothing, it takes one API call in the same code path as the capture, and failing to do it is the source of nearly every dispute, support contact, and overdraft this practice causes. If you change one thing, change this.
Telling the customer
Disclosure is cheap, it is rarely done, and it converts a complaint into an expectation.
- State the amount being authorized, not just that a hold will be placed.
- Say when it will be released and that the final charge may be lower.
- Say it before authorizing, not on a receipt afterward.
- Put it in writing where the transaction has any lead time, per our booking disclosure analysis, because the same evidence that defends a no-show fee defends a hold.
- Offer an alternative for customers who ask. A smaller hold with a card on file, or payment on completion, resolves the objection for the customers who raise it.
The second bullet prevents most of the support volume. A customer who knows the hold exceeds the expected charge and will release within a stated period does not call when it does. A customer who does not know calls on day one and again on day three.
Hold less, for less time, with the record to prove it
HL Hunt Pay releases unused authorization amounts in the same code path as the capture, supports incremental authorization so the hold grows only as the work does, stores the disclosure shown at authorization against the transaction, and reports held customer funds as a figure you can actually see.
What to check this week
- How long after capture does your average hold release? If nobody knows, it is longer than you think.
- Is the release in the capture path or in a nightly job? Move it.
- What happens to holds on abandoned transactions? This is the indefensible case and it is usually unhandled.
- What is your margin, and where did the number come from? If the answer is convention, compute your own percentile.
- What does the customer see before you authorize? Read your own flow as a customer would.
- How many support contacts mention a pending amount? Per our complaints analysis, that count is the size of this problem in your own operation and nobody tags for it.
- Total customer funds currently held. Compute it once. It is usually larger than expected and it changes the conversation internally.
Item seven is the one to take to whoever sets the margin. A policy expressed as "we authorize 20% above estimate" sounds prudent. The same policy expressed as "we are currently holding $67,800 of our customers' money, none of which we are owed" is a different discussion, and it is the same policy.
Stop holding money you are not owed
Get started with HL Hunt Pay for authorization margins derived from your own overrun data, abandoned-transaction holds reversed automatically, and a running figure for customer funds currently held so the margin becomes a decision rather than a convention.
Frequently asked questions
It reserves an estimate plus a margin before the amount is known. A $408 hold against a $295 charge leaves $113 unavailable until the hold is released.
A customer with a thin buffer can overdraft on a purchase they could afford, see what looks like an overcharge, and have unrelated transactions decline.
Release the unused amount in the same code path as the capture. Cleanup jobs run late or not at all, and a live hold after capture looks like a duplicate charge.
Set it at a high percentile of your own measured overruns. If 95% of jobs land within 8% of estimate, a 20% margin holds more than twice what it needs to.
Key takeaways
- A $408 hold against a $295 charge leaves $113 of customer funds unavailable until the hold is explicitly released.
- At 600 transactions a month with a $113 average excess, about $67,800 of customer money is held at any one time.
- A customer with a thin buffer can overdraft on a purchase they could afford, and the fee was created by your authorization practice.
- Release the unused amount in the same code path as the capture, never in a nightly cleanup job.
- A hold still live days after capture looks like a duplicate charge and is very hard to defend.
- Holds on abandoned transactions are indefensible and inflate the dispute ratio that drives processor reviews, on transactions that generated no revenue.
- A 20% margin is a convention; set it at a high percentile of your own measured overrun distribution instead.
- Stating the amount and the release timing before authorizing prevents most of the support volume it otherwise generates.
This guide is educational and does not constitute legal, compliance, or payments advice. All figures are stylized illustrations using assumed estimates, margins, transaction volumes, and release timings, and do not describe any particular merchant or processor. Authorization and reversal capabilities, incremental authorization support, hold expiry behaviour, disclosure obligations, and dispute rules vary by card network, by acquirer, by card product, and by jurisdiction, and change over time. Confirm current requirements and capabilities with your acquirer before changing any authorization practice.