Rollback or cleanup logic exists if post-payment database updates fail

When a Stripe charge succeeds but the subsequent database write fails, you have taken the customer's money without creating their order record. Without compensation logic, this is a silent failure: your system shows no order, the customer sees no confirmation, and no automated process triggers a refund or retry. CWE-362 (Race Condition / Improper Synchronization) applies when the payment and fulfillment steps are not treated as an atomic operation. In high-volume stores, even a 0.1% database failure rate translates to dozens of unreconciled charges per day — each requiring manual support intervention, chargeback risk, and reputational damage.

Wrap all post-payment database writes in a transaction, and provide explicit compensation (refund or retry queue) if the transaction fails.

// In your webhook handler after verifying signature
if (event.type === 'payment_intent.succeeded') {
  const pi = event.data.object as Stripe.PaymentIntent

  try {
    await db.transaction(async (tx) => {
      await tx.orders.create({ stripePaymentIntentId: pi.id, status: 'confirmed' })
      await tx.inventory.decrement(/* items */)
    })
  } catch (err) {
    console.error('Post-payment DB failure', { paymentIntentId: pi.id, err })

    // Compensation: refund the charge so the customer is not stuck
    await stripe.refunds.create({ payment_intent: pi.id })

    // Or: push to a dead-letter queue for manual review + retry
    await queue.push({ type: 'fulfill-order', paymentIntentId: pi.id })
  }
}

Use Stripe's metadata field on the PaymentIntent to store the internal order ID, so any retry or support lookup can correlate the charge to your records.