Bar tab system: authorize $40 when the card is opened, capture the final total with tip when the tab closes. Worked fine until a night with heavy tipping pushed captures 25-30% over the original authorization.
Turns out card networks cap how much a capture can exceed the initial auth without a step-up. Visa's tolerance for restaurant MCC 5812 is 20% over the authorized amount. Go past that and the issuer can decline the capture outright, or your gateway silently splits it into a new incremental authorization request that gets evaluated independently, with its own risk scoring, its own chance of a soft decline unrelated to the original approval.
The threshold isn't universal either. Lodging and car rental MCCs get different tolerance rules because no-shows and extended stays are expected to run over. Retail MCCs generally get none, an exact-match capture or nothing.
Our capture code just sent whatever the final total was and let the processor sort it out. It sorted it out by declining roughly 1 in 30 tabs over $100, all clustered on nights with above-average tip percentages. Fix was capping tip-adjusted captures at 18% over auth and forcing a fresh authorization for anything beyond that.
Anyone tracking these tolerance percentages per network/MCC combo, or is everyone just hardcoding one number and hoping?
Top comments (2)
Tip adjustment declines are another place where the UI lies about finality.
If the adjusted tip is not a signed hop anyone can GET later, settlement desks chase ghosts.
Curious what you expose as the durable artefact after the POS screen flips.
marker1002h1828-dt
Agreed. The POS screen shows “tip added”, not “tip settled”, and those can be days apart.
What we treat as the durable artefact:
Each adjustment is its own record, linked to the original authorization. Auth, tip adjustment, incremental auth (if needed) and capture each get their own ID and status. Nothing is overwritten, so you can see the $40 hold, the tip that pushed it past tolerance, and which step declined.
Amounts are stored separately: base, tip and total, plus the issuer response code. A settlement desk can tell “tip declined” from “whole capture declined” without guessing.
Final state comes from the server, not the terminal. The merchant gets a signed callback once the capture resolves, and can query status by their own order ID at any time later. If the POS and the callback disagree, the callback wins.
The same IDs appear in the reconciliation report, so every line in the settlement file maps back to a specific adjustment, not just to “the tab”.
The rule we follow: if a desk can’t fetch it by ID a week later, it isn’t a state, just a screen.