A checkout retry charged the customer twice: prove and resolve both payments

Collect the customer order, checkout session and processor payment references. Inspect the status, amount and currency of every attempt. A pending authorization, a failed attempt and a completed charge are different events. Two entries on a customer screenshot or two rows in an export do not, on their own, prove that the merchant received the money twice.

Stripe documents that a PaymentIntent can have multiple Charge objects associated with payment attempts and that their outcomes can be inspected. Use the successful payment evidence and resulting balance activity to identify actual duplicate collection. Preserve the failed attempts as part of the incident history rather than counting every attempt as a sale.

Confirm whether the customer intended one order or two. Compare line items, fulfillment records, timing and customer communication, using processor identifiers to distinguish transactions. Identical amounts can be legitimate repeat purchases. If there is one intended order and two completed collections, record the excess collection as an unresolved customer amount until the approved correction is completed.

In a hypothetical incident, one $80 order has two successful $80 payments. The processor has collected $160, while the intended purchase is $80. An $80 refund against the identified extra payment returns net collected principal to $80. Any retained processor fees or other adjustments must be explained separately rather than changing the order price to make the payout agree.

Check for a customer dispute before issuing the remedy and coordinate any existing case through the provider's process. The same excess payment should not produce an uncoordinated refund and dispute reimbursement. Keep the original valid charge, extra charge, refund and any dispute reference linked in the case record.

Initiate the approved correction through the relevant provider and monitor its actual outcome. A refund request is not proof of completion. Give support the transaction reference and status it needs to explain the correction accurately to the customer. Investigate a failed or pending refund instead of issuing another payment simply because the first has not yet appeared.

Reconcile the valid order, both original collections and the completed remedy to processor activity and the accounting records. This is a real money-movement correction, separate from deleting a duplicate imported sales row. Have the accountant review the posting treatment and affected periods while preserving the original payment identifiers and incident evidence.

Give the checkout owner the incident timeline and payment references. Stripe describes idempotency as a way to retry an operation without performing it twice and recommends reusing the existing PaymentIntent when an interrupted checkout resumes. The integration owner should verify the actual checkout design and provider guidance, including how retries retain the original purchase identity.

Search the incident window for other orders with the same symptom, then verify each candidate individually. Test the repaired timeout and retry path before closing the incident. Finance and support should retain a resolved-case list so delayed complaints can be checked against completed remedies and the next settlement review can confirm that no affected customer payment remains unexplained.