Stripe in Production: Testing and Going Live

Most payment bugs are silent — a user's card gets declined but they see a spinner forever, or a webhook fails and nobody finds out until a subscriber discovers their account was never provisioned. Production Stripe means every failure path is handled and monitored.

Test Cards and Scenarios

Stripe provides test card numbers that simulate specific outcomes. These work in test mode only and are rejected in live mode.

4242 4242 4242 4242   → succeeds
4000 0000 0000 9995   → insufficient funds
4000 0000 0000 3220   → 3D Secure required
4000 0000 0000 0341   → attaches but charge fails
4000 0025 0000 3155   → requires authentication on payment

Stripe Error Taxonomy

Stripe throws different error types for different failure modes. Handle them at the right granularity.

try {
  const charge = await stripe.charges.create({...});
} catch (err) {
  switch (err.type) {
    case 'StripeCardError':
      // card declined — show user-friendly message
      break;
    case 'StripeRateLimitError':
      // too many requests — retry with exponential backoff
      break;
    case 'StripeInvalidRequestError':
      // bad parameters — fix your code
      break;
    case 'StripeAPIError':
    case 'StripeConnectionError':
      // Stripe-side problem — retry, alert your team
      break;
  }
}

Pre-Launch Checklist

Before switching to live keys, verify every item on this list:

• Webhook endpoint verified with live webhook secret, not test secret.
• All three critical events handled: checkout.session.completed, invoice.payment_failed, customer.subscription.deleted.
• Idempotency implemented — processed event IDs stored in database.
• Error handling covers card declines, rate limits, and API errors.
• Receipts and confirmation emails send on successful payment.
• Billing Portal enabled so subscribers can self-serve cancellations.
• Live key environment variables set in production, not test keys.
• Stripe Radar rules reviewed for fraud prevention.