Duplicate Payments: Why Customers Get Charged Twice and How to Prevent It

Three different problems that all look like "duplicates"

Where duplicate charges come from

Layer 1: design checkout so customers don't pay twice

• Disable the pay button after the first press and show progress. Re-enable it only when you know the outcome, not after a fixed delay.
• Keep one open order per basket. If the customer comes back to checkout, reuse that order and its payment rather than creating new ones.
• When a payment is pending, say so plainly: "We're waiting for your bank to confirm. Please don't pay again; we'll update this page." Then poll your own server for the result.
• If the customer does choose another method while one is pending, cancel or expire the pending one where the provider allows it, and keep the order able to accept only one success.
• For UPI collect or QR payments, expire the request after a short, clearly shown window, so an old request can't be approved after the customer has already paid another way.

Layer 2: one order, many attempts, at most one success

CREATE TABLE payment_attempts (
  id            uuid        PRIMARY KEY,
  order_id      uuid        NOT NULL REFERENCES orders (id),
  provider      text        NOT NULL,
  provider_ref  text,
  amount_minor  bigint      NOT NULL CHECK (amount_minor > 0),
  currency      char(3)     NOT NULL,
  status        text        NOT NULL
                CHECK (status IN ('created', 'pending', 'succeeded', 'failed')),
  created_at    timestamptz NOT NULL DEFAULT now()
);

-- A partial unique index: only rows with status 'succeeded' are indexed,
-- so a second success for the same order is rejected by the database.
CREATE UNIQUE INDEX one_success_per_order
  ON payment_attempts (order_id)
  WHERE status = 'succeeded';

Layer 3: idempotency keys on every money-moving request

1. The client generates a key once per intent to pay, such as a random UUID created when the customer presses pay, and stores it with the order. Every retry of that request reuses the same key.
2. The server stores the key, scoped to the merchant or account, together with a fingerprint of the request: the method, path and body.
3. If a request arrives with a key it has already completed, the server returns the stored response. No second call to the provider is made.
4. If the key is known but the fingerprint differs, the server rejects the request. The IETF draft suggests HTTP 422: the client is misusing the key.
5. If the original request is still in progress, the server returns a conflict, HTTP 409 in the draft, and the client retries later.
6. Keys expire after a published period, long enough to cover realistic retries.

async function createPayment(req: Request): Promise<Response> {
  const key = req.headers.get("Idempotency-Key");
  if (!key) return json(400, { error: "Idempotency-Key header is required" });

  const merchantId = await authenticate(req);
  const body = await req.text();
  const fingerprint = sha256(req.method + " " + new URL(req.url).pathname + "\n" + body);

  // Claim the key atomically: only one concurrent request can insert it.
  const claimed = await db.query(
    "INSERT INTO idempotency_keys (merchant_id, key, request_hash, status) " +
      "VALUES ($1, $2, $3, 'in_progress') " +
      "ON CONFLICT (merchant_id, key) DO NOTHING RETURNING key",
    [merchantId, key, fingerprint],
  );

  if (claimed.rowCount === 0) {
    const prior = await db.one(
      "SELECT request_hash, status, response_code, response_body " +
        "FROM idempotency_keys WHERE merchant_id = $1 AND key = $2",
      [merchantId, key],
    );
    if (prior.request_hash !== fingerprint) return json(422, { error: "Key reused with a different request" });
    if (prior.status === "in_progress") return json(409, { error: "Original request still in progress" });
    return json(prior.response_code, prior.response_body); // replay: no second charge
  }

  const result = await createWithProvider(JSON.parse(body), { idempotencyKey: key });
  await db.query(
    "UPDATE idempotency_keys SET status = 'completed', response_code = $3, response_body = $4 " +
      "WHERE merchant_id = $1 AND key = $2",
    [merchantId, key, result.status, result.body],
  );
  return json(result.status, result.body);
}

Layer 4: never answer a timeout with a new payment

• Treat a timeout as "unknown", not "failed". Keep the attempt in a pending state.
• Resolve unknowns by asking the provider for the payment's status, using your own reference or the provider's ID, before doing anything else.
• Retry only with the same idempotency key, so a repeat to the same provider can't create a second payment.
• Move to another provider only when you know the first attempt failed, or when the first provider confirms it has nothing for your reference.

When you use more than one provider

Catching the duplicates that get through

• Alert when an order has more than one successful attempt. If you added the unique index above, this is every time it rejects an update.
• Run a daily check for the same customer, same amount and same merchant within a short window, across all orders. Not every match is a duplicate (people do buy the same thing twice), but every duplicate is a match.
• Match provider settlement reports against your orders. A settled payment with no order, or two settled payments for one order, shows up as an exception. Our payment reconciliation guide explains the routine.
• Track duplicates as a metric, broken down by cause. The cause tells you which layer to strengthen.

What to do when a customer has been charged twice

1. Confirm both charges succeeded and settled, not that one is a pending authorisation or a failed payment awaiting automatic reversal.
2. Refund the later charge in full, to the original payment method, through your provider's refund flow, and record it against the order.
3. Tell the customer what happened, the refund reference and when to expect the money. Card refunds and UPI refunds take different routes back, so give the reference that their bank can trace.
4. Record the cause, so it feeds the metric above.

A checklist for your integration

• The pay button can't send two requests, and a pending payment is shown as pending.
• One open order per basket, reused on return.
• Orders and payment attempts are separate, with at most one success per order enforced by the database.
• Every create-payment, refund and payout request carries an idempotency key, generated once per intent and reused on retry.
• The server stores the key, a request fingerprint and the full response, and handles in-progress and mismatched keys.
• Timeouts are treated as unknown and resolved with a status check, never with a new payment.
• Scheduled charges have a unique key per billing period.
• An alert fires on a second success for one order, and reconciliation flags duplicate settlements.

Frequently asked questions