How do you respond when a customer says they were charged twice for a single order?

First, find out whether it actually happened

A customer who says they were charged twice is usually looking at their banking app, and banking apps are not good at explaining what they show. There are four common explanations. A true duplicate: two successful charges for the same order, usually caused by a double-submitted checkout, a client retry without an idempotency key, or a webhook that created a second payment. A pending authorization plus the captured charge, which appears as two lines until the authorization drops off, a common sight when you authorize first and capture later or when a payment was retried after a decline. Two genuinely separate orders the customer forgot about. Or a subscription charge and a one-time purchase that landed on the same day.

Open the customer in Stripe and look at the actual charges before answering. Two succeeded charges with different IDs, the same amount, and timestamps seconds apart is a duplicate. One succeeded charge plus one that is uncaptured, canceled, or failed is the pending-authorization case. Two succeeded charges with different amounts, different order references, or hours apart are more likely separate orders. Note the charge IDs, timestamps, amounts, and statuses; you will need them for the customer reply and possibly for a dispute response. Answering the customer from memory or from the order system alone is how sellers end up refunding a charge that never settled. Related: Meeting Dispute Deadlines

Keep reading: Why Most Chargebacks Are Lost, Building a Strong Evidence Packet, Understanding Chargeback Reason Codes. See how DisputeLoom helps you chargeback evidence packager for stripe sellers.

When it is a true duplicate, refund fast and document it

Refund the extra charge immediately, before the customer has time to call their bank. Send them a short message with the refund reference, the amount, and an honest statement that refunds typically take several business days to appear on their statement, so they are not surprised by the delay. Keep that message. If the customer has already opened a dispute on one of the two charges, you cannot refund that particular charge in Stripe anymore; the mechanism for returning the money is to accept the dispute. Refund the other charge if it is still refundable and explain both actions to the customer in writing. Related: What Banks Look For in Evidence

If you refunded the duplicate and a dispute arrives on it anyway (banks sometimes file on a charge that was already refunded because the customer reported it before the refund posted), respond with the refund ID, the refund date, and your message to the customer. That is usually enough. If the dispute is on the charge you kept, the response should show that the other charge was refunded on a specific date and that the remaining charge corresponds to the order that was fulfilled. In both cases the narrative is simple and factual: an error occurred, it was corrected on this date, the customer was informed on this date, and here is the record. Related: When should a Stripe seller refund an early fraud warning instead of waiting for the chargeback?

When they are two real orders, prove they are distinct

Sometimes the customer placed two orders and remembers one. The card networks have a specific dispute category for duplicate processing, and Stripe's evidence object has fields built for the rebuttal: the ID of the other charge, documentation for it, and an explanation of why the two are not duplicates. Use them. The explanation should be one or two plain sentences: charge A on this date was order 1001 for these items, shipped with this tracking number; charge B two days later was order 1002 for these other items, shipped separately with this tracking number. Distinct order numbers, different items or quantities, separate timestamps, and separate shipments make the case. Related: How do you prove a subscriber actually used your software before disputing a renewal charge?

Attach the two order confirmations side by side, the two shipping records if physical, and any customer communication about either order. If the amounts happen to be identical, which is common with single-item stores, the timestamps and shipping details carry more weight, so make them prominent. If one of the orders was later refunded or cancelled, say so and show it, because the bank will see the refund and may otherwise assume it was the duplicate correction. Avoid arguing about the customer's memory; the point is that the records show two purchases, and the records are what the analyst will rely on.

Fixing the checkout so it stops happening

True duplicates are almost always a software bug, and they are cheap to prevent compared with what they cost. Use idempotency keys on every request that creates a payment, so a client retry after a timeout returns the original result instead of a second charge. Disable the pay button the instant it is clicked and show a processing state. Handle the return from a 3D Secure authentication so a refresh does not resubmit. Make your webhook handlers idempotent, keyed on the event ID, so a redelivered event cannot create a second order or a second charge. Reconcile orders against Stripe payments daily and alert on any customer with two successful charges of the same amount within a few minutes.

The pending-authorization confusion is a communication problem rather than a bug. A clear statement descriptor with the business name the customer knows makes both lines recognizable. If you authorize and capture separately, tell customers in the confirmation email that they may briefly see a pending hold alongside the final charge. Send exactly one confirmation email per order, with the order number, so the customer can match it to their statement. And train whoever answers support to check Stripe first, explain the difference between pending and posted, and offer the refund reference when a real duplicate exists. Most duplicate-charge disputes are filed after a customer got a vague or slow answer.