The charge that was never really there
A customer emails you, or worse, doesn't email you at all and just files a dispute: "I was charged twice for one order." You open your dashboard. There is exactly one payment. One amount, one order, one settlement. Nothing is duplicated. And yet the bank has opened a chargeback, your account has been debited, and a deadline is now ticking.
Most of the time, this customer is not lying, and you did not make a mistake. What they saw on their banking app was real. What they concluded from it was wrong. The gap between those two things is one of the most winnable disputes in payments — once you understand the mechanism that produced it.
That mechanism is the authorization hold.
What actually happens when a card is charged
We talk about "charging a card" as if it were one event. It is almost always two.
The first step is authorization. When the customer hits pay, the card network asks the issuing bank a question: does this account have the funds, and is the card valid? If yes, the bank places a hold on the money. The funds are earmarked, set aside, made unavailable to spend — but they have not moved anywhere. No money has left the customer's account and none has arrived in yours. This is the pending line the customer sees almost instantly.
The second step is capture and settlement. This is when the money actually moves from the customer's bank to your acquirer and, eventually, to you. Depending on how your checkout is configured, settlement can happen seconds later or a day or two later.
For a clean, single-step purchase, the hold quietly converts into the settled charge and the customer only ever notices one line. But several ordinary situations break that smooth conversion — and each one leaves a second amount sitting on the customer's statement for a while.
The four ways one purchase shows two amounts
A failed first attempt. The customer's first try is declined or times out — maybe a typo, maybe a network hiccup — but the authorization hold still lands at the bank. They try again, it succeeds, and now there are two amounts: the abandoned hold and the real charge. The hold will fall off on its own, usually within a few business days, but the customer is looking at it today.
Pre-authorizations. Hotels, car rentals, fuel pumps, and some subscription trials place a hold for an estimated or nominal amount, then capture the final amount separately. The customer sees the pre-auth and the final charge side by side and reads it as two bills.
Tip or adjustment flows. A restaurant or salon authorizes the base amount, then captures the base plus tip. For a window of time, both figures are visible.
Slow settlement. The pending authorization and the posted charge briefly coexist in the banking app during the handoff, which can spook a customer who refreshes at the wrong moment.
In every one of these, there is only ever one settled transaction. The other amount is a hold that has not yet expired. But the customer's banking app rarely explains this. It shows two numbers, often without clearly labeling which is pending and which is posted, and the customer does the natural thing: assumes the worst and disputes.
Why this becomes a chargeback instead of an email
There is a behavioral wrinkle worth naming here, because it explains why you often don't get a chance to fix this quietly. Disputing a charge through a banking app is now frictionless — a few taps, no phone call, no waiting on hold. Contacting an unfamiliar merchant feels slower and more uncertain. So when a customer faces a choice between the fast, familiar action (tap dispute) and the slow, ambiguous one (find the merchant's email, explain the problem, wait), they default to the easy path. This is the same friction asymmetry that drives a lot of so-called friendly fraud: the easier channel wins, regardless of who is actually right.
The dispute then arrives under a duplicate-processing reason code — in the Visa framework, reason code 12.6.1, "Duplicate Processing" (Mastercard and the other networks have close equivalents). The code is the bank's shorthand for the customer's claim: this transaction was processed more than once.
And here is the good news buried in the bad. A duplicate-processing claim is a claim about a verifiable fact. Either you charged the card twice or you didn't. Unlike a "product not as described" dispute, which hinges on subjective impressions, this one is settled by your own records. You almost always have the truth on your side, in writing.
How to win a duplicate charge dispute
The winning argument is not "the customer is mistaken." Reviewers process thousands of disputes; an indignant tone earns you nothing. The winning argument is a clean, factual reconstruction that lets the reviewer see what the customer saw — and why it was a hold, not a duplicate.
Assemble these:
Proof of a single settlement. Pull the transaction record showing exactly one captured and settled charge for the order. This is your spine. Highlight the settlement status, not just the authorization.
The two transaction IDs, side by side, with their states. If a failed or abandoned authorization exists, show it explicitly: one record marked authorized-but-not-captured (or voided/expired), the other marked captured. When a reviewer can see one ID that never settled and one that did, the duplicate claim collapses on its own.
The lifecycle of the hold. Note when the authorization was placed and that it was never captured — meaning no second transfer of funds occurred or could occur. If the hold has already expired and the amount has returned to the customer, say so plainly.
A short, neutral narrative. Two or three sentences: the order, the single settled charge, and a plain-language explanation that the second amount the customer saw was a temporary authorization hold that released without ever moving money. No jargon the reviewer has to decode, no defensiveness.
The matching authorization data. If your AVS and CVV results matched on the genuine charge, include them. They reinforce that the real transaction was legitimate and customer-initiated.
The whole case rests on one distinction the customer didn't have access to and you do: pending is not posted. You are not arguing about taste or quality. You are showing a ledger.
Prevent the next one before it starts
Much of this dispute is an information problem, and information problems can be designed away. A confirmation screen and email that state the single charge amount clearly — and, if you use pre-authorizations, that explain a temporary hold may appear and will release — preempt the panic that leads to a tap. A billing descriptor the customer recognizes helps too; an unfamiliar descriptor next to a pending hold is twice as alarming as either alone. If your checkout retries failed payments, voiding the abandoned authorization promptly shortens the window in which two amounts are visible.
None of this requires you to change how money moves. It changes what the customer understands about how money moves — which is the entire source of the dispute.
Where Argeback fits
The frustrating thing about a duplicate charge chargeback is that the evidence to win it already exists, scattered across your transaction records — and the seven-day window to assemble it always seems to open on your busiest week. Argeback reads the incoming Stripe dispute, recognizes the duplicate-processing claim, pulls the settled charge alongside the authorization that was never captured, and drafts the side-by-side, fact-first response that reviewers actually credit — then files it before the deadline, from your phone. The truth was always on your side; this just makes sure it gets submitted in time. If duplicate-charge disputes have been quietly costing you money you should have kept, you can see how it works at https://argeback.lumenlabs.works.