A chargeback is three ledger events, not one

What it is

A chargeback, or dispute, is the cardholder's bank taking a payment back from the processor without asking the merchant. It is not a refund: nobody on your side issued it, the order stays paid in the storefront, and the goods are usually already gone. Card networks let the cardholder open one for roughly 120 days after the payment, longer for goods or events delivered later, so a dispute can land on an order from a quarter you have already closed.

On the processor it produces three separate movements. When the dispute opens, the disputed amount and a dispute fee are debited from your balance at once. If you contest and win, the disputed amount is credited back; whether the fee comes back depends on the processor and your country, and on Stripe the receipt fee is non-refundable outside Mexico while a separate contest fee is returned on a win. If you lose, nothing further moves: the debit that happened on day one is the loss. Shopify Payments works the same way, with the disputed amount and fee taken from the next available payout, and an inquiry, where the bank asks for information first, takes nothing until it escalates.

Reconciling a chargeback means proving that each of those movements is either in your books with the right sign and date or expected and still pending. Most stores record the loss once, at the end, and then cannot explain why a payout two months earlier was short.

How it happens

Fraud on a stolen card. The genuine cardholder sees an unknown charge and disputes it. The order looks normal in every system; the only signal, if any, was an early fraud warning from the network before the dispute opened.

Product not received or not as described. The parcel was late, went to a wrong address, or the customer contacted nobody and went straight to the bank. A tracking number that shows delivery and a signed proof are what win these, which is why the shipment record matters here as much as the payment.

A refund that was promised and never sent. The storefront shows a refund, the processor call failed, the customer waited and then disputed. The dispute then exists next to a store-side refund record, and a naive reconciliation counts the money out twice.

A subscription or repeat charge the customer forgot. The bank may open one dispute for the sum of several charges against just one of them, so the disputed amount does not match any single payment in your ledger.

A partial refund already given. The customer received a partial refund for one damaged item, then disputed the whole payment. The dispute amount can also differ from the charge through currency conversion when the order was priced in one currency and settled in another.

Why it matters

The money leaves on day one, not when the case closes. For an open case, hold = disputed_amount + dispute_fee, deducted from the balance and therefore from the next payout. That is why a payout reconciliation that ignores open disputes shows a shortfall that nobody can attribute.

When the case closes, the same rows change class. Lost: verified_loss = disputed_amount + dispute_fee, plus the unit cost and outbound shipping already spent if the goods shipped. Won: the disputed amount returns, and the net cost is whichever fees the processor keeps; on Stripe that is the receipt fee, and the contest fee only if the case was lost. Accepted without contesting: the same as lost, but with no contest fee.

There is a second-order cost that is not in any row. Each dispute raises your dispute rate with the card network, and a rate above the network's threshold brings monitoring programs with their own monthly charges, and eventually the loss of the ability to take cards. That is why the count of disputes per month is worth tracking alongside the amounts, and why a small dispute is worth refunding before it opens when a fraud warning arrives on a low-value order.

Finally, a dispute blocks the ordinary fix. While a dispute is open you cannot refund the charge outside the dispute process, so a support agent who issues a store-side refund to calm the customer creates a record with no money behind it.

How to diagnose

1. Export the disputes for the period from the processor, with dispute id, charge id, amount, currency, fee, reason, status, opened date, evidence due date and closed date. On Stripe the dispute is its own object and the charge it belongs to carries the disputed flag; on Shopify Payments the chargeback is listed under the order and in the payouts report.

2. Join each dispute to the order through the charge's order reference, then attach the shipment row: carrier, tracking, delivered date, and any proof of delivery. Sort by evidence due date. Anything due within a few days is today's work regardless of amount; a missed deadline is an automatic loss.

3. For each dispute, list the refunds on the same order, storefront and processor, with dates. A refund dated before the dispute opened and present on the processor is evidence to submit. A refund dated after the dispute opened, or present only in the storefront, is a record that must be reversed or written off so the money is not counted out twice.

4. Reconcile the debits to payouts. Take the processor's balance transactions of type dispute and dispute reversal for the period, sum them per payout, and place them in the payout identity next to captures, fees and refunds. Every payout that was short by exactly the disputed amount plus the fee is now explained; anything left over is a different problem.

5. For closed cases, check the reversal landed. Won: a credit for the disputed amount, and any refundable fee, dated at the decision. Lost: no further movement, and the order is written down as a loss with the fee. Watch for the rare late win, where a case marked lost is credited weeks later by the issuer.

6. Group the period's disputes by reason code, by product and by shipping method. Fraud clustered on one product or one destination points at a checkout rule; not-received clustered on one carrier or one warehouse points at fulfillment, not at customers. Fix the source before the rate crosses the network's threshold.

What AXIOTRA does with it today

Nothing reads disputes. The Stripe connection reads charges, refunds and, when the key allows it, payouts; dispute objects, dispute fees and their reversals are not read, and the CSV importer has no dispute kind. A disputed charge still arrives as a succeeded payment with its original amount, so the order looks fully paid and no detector raises it.

Two detectors are affected by that gap. The payout detector expects captures minus fees to equal payouts; it does not subtract refunds or disputes, so a period with open disputes shows a difference equal to the disputed amounts plus fees, on top of any refunds. Read that finding as a prompt to run the reconciliation above, not as a loss figure. The refund detector never sees a dispute either: a lost dispute where the goods were not returned looks exactly like a paid order, and a store-side refund created after the dispute opened is treated as an ordinary refund.

What you can do with the product now is the join in steps 2 and 3. Orders, payments, refunds and shipments imported from CSV or a connection are matched on the order reference, and the Refunds and Shipments screens show the rows a dispute case needs, so the evidence for a not-received claim can be assembled from one place. The dispute list itself stays a processor export until a dispute kind ships; when it does, this page and the limitations page will say so.