Customers charged twice

Your preparation

0 of 0 safeguards ready

Incident worksheet

Make the next decision with evidence

Stop duplicate capture, identify every affected payment, and refund or void once without creating a second accounting error.

EvidenceDecisionActionProof

Capture before evidence disappears

Preserve payment, intent, invoice, order, idempotency key, webhook, retry, timeout, deploy, provider request ID, and ledger events.
Find pairs by customer, amount, currency, time, order, cart, invoice, and provider status—then verify whether both settled.
Record taxes, fees, credits, subscriptions, fulfillment, payouts, disputes, and customer messages tied to each duplicate.

Decisions that change the response

Question	Act when	Action
Void or refund?	The duplicate is authorized but not settled versus already captured.	Void pending authorizations where possible; refund settled duplicates through the original payment path.
Pause checkout?	New duplicates continue or request outcomes cannot be reconciled.	Disable the affected path and expose clear status rather than accepting ambiguous payments.

Proof that recovery worked

The provider, internal ledger, order, invoice, refund, tax, and customer balance agree for every affected case.
Retries, duplicate webhooks, browser resubmits, and timeout ambiguity cannot create another charge.
Customers receive one factual notice and one refund outcome, not repeated automated messages.

Controls to put in place

Use a stable business idempotency key from order creation through provider capture.
Treat webhooks as repeatable events and reconcile provider state before retrying ambiguous requests.
Alert on same-customer same-order payment patterns and ledger imbalance.

Tabletop drill

Force a payment timeout and duplicate webhook in a sandbox. Reconcile provider state, prevent second capture, refund one settled duplicate, and verify the ledger and receipt.

Escalate when

Use urgent processor support when capture or refund state is ambiguous, and involve finance or counsel when the incident affects large cohorts, taxes, reserves, or consumer obligations.

What this means

Duplicate charges damage trust and can trigger disputes and fees. A visible duplicate order is not proof of a settled duplicate payment, so verify at the processor.

Warning signs

Customers report two charges for one purchase.
Payment creation count exceeds completed orders.
Identical amounts and customers appear seconds apart.
Retry logs show missing or changing idempotency keys.

Recover now

First 15 minutes

Stop the affected charge path or retry worker.
Identify processor charge IDs, status, customer, amount, and cause.
Prevent further retries before issuing refunds.
Do not refund both charges without confirming which payments settled.

Today

Refund confirmed duplicates through the original processor.
Notify affected customers with amount, timing, and refund expectations.
Reconcile orders, invoices, accounting, tax, and access.
Fix idempotency, locking, webhook deduplication, or operator workflow.

Verify recovery

Duplicate creation has stopped.
Every affected charge has one documented disposition.
Refunds and customer records reconcile with processor state.
Repeating the original request cannot charge again.

Prepare now

Access

Refund permissions are limited and separately audited.

Backups and evidence

Business operation IDs map to processor charge and refund IDs.

Contacts and ownership

A payment incident owner can pause charges and communicate.

Practice

Concurrent and retried payment requests are tested for idempotency.

Common mistakes

Refunding before stopping the duplicate path.
Using a new idempotency key for each retry.
Ignoring invoice and accounting reconciliation.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.