Debugger

This is a classic TOCTOU (time-of-check-to-time-of-use) race condition. The check-then-charge pattern is not atomic:

Request A: check payment exists? → No
Request B: check payment exists? → No  (A hasn't committed yet)
Request A: create payment → success
Request B: create payment → duplicate charge! 💸

Fix 1: Database-level unique constraint (best, always do this):

-- Add a unique constraint on the idempotency key
ALTER TABLE payments ADD COLUMN idempotency_key VARCHAR(64) UNIQUE;

-- Application layer: generate key from (userId + orderId + amount) or use client-provided key

async function chargePayment(userId: string, orderId: string, amount: number) {
  const key = `${userId}:${orderId}:${amount}`;
  try {
    await db.payments.create({ data: { userId, orderId, amount, idempotencyKey: key } });
  } catch (e) {
    if (e.code === 'P2002') { // Prisma unique constraint violation
      return db.payments.findUnique({ where: { idempotencyKey: key } }); // return existing
    }
    throw e;
  }
}

Fix 2: Distributed lock for multi-step transactions:

const lock = await redlock.acquire([`payment:${orderId}`], 10000); // 10s TTL
try {
  const existing = await db.payments.findUnique({ where: { orderId } });
  if (existing) return existing;
  return await stripeCharge({ orderId, amount });
} finally {
  await lock.release();
}

Use both: the unique constraint as a safety net (always), and the distributed lock if you need to call Stripe before inserting (to avoid charging before you can record it).