Generic error messages are shown to users; no raw exceptions or stack traces exposed

Returning raw exception messages, Stripe error objects, or database errors from payment API routes leaks internal system architecture to every browser that inspects network responses. A response like { error: "No such payment_intent: 'pi_3Ox...'" } tells an attacker your payment intent ID format, your Stripe account configuration, and the exact server-side path that failed. CWE-209 (Generation of Error Message Containing Sensitive Information) directly names this pattern. OWASP A05 (Security Misconfiguration) flags information leakage from unhandled exceptions as a reconnaissance vector. Beyond security, raw Stripe error messages contain decline codes and internal identifiers that help card-testing bots distinguish working cards from flagged ones.

Catch and classify errors in payment routes; return only generic user-facing messages while logging the full details server-side.

// app/api/payment/route.ts
try {
  const paymentIntent = await stripe.paymentIntents.confirm(id)
  return NextResponse.json({ status: paymentIntent.status })
} catch (err) {
  if (err instanceof Stripe.errors.StripeCardError) {
    console.error('Card error', { code: err.code, decline_code: err.decline_code, id })
    return NextResponse.json(
      { error: 'Your card was declined. Please try a different payment method.' },
      { status: 402 }
    )
  }
  console.error('Payment error', err)
  return NextResponse.json(
    { error: 'Payment could not be processed. Please try again.' },
    { status: 500 }
  )
}

Never return err.message, err.stack, or a serialized error object in the response body. The safe surface to the client is a human-readable string you control.