At most one payment processor

Two active payment processors means two webhook handlers, two subscription state machines, two refund flows, and two customer records — and they will diverge. Stripe webhooks fire for events that PayPal never sees; subscription cancellations processed in one system leave active billing in the other. ISO 25010 functional-suitability is directly violated when billing logic is split: a customer who cancels via the Stripe portal remains billed through the PayPal path. In a regulated context, split billing records also complicate revenue recognition and refund auditing. This drift pattern almost always originates from AI sessions adding a "quick PayPal option" without reviewing the existing Stripe integration.

Pick the processor that handles the majority of your transaction volume as primary. Wrap it behind a unified billing interface so future processor changes don't require touching application logic.

// src/lib/billing.ts — single processor entry point
import Stripe from 'stripe'

export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2024-11-20.acacia',
})

// All subscription, refund, and webhook logic goes through here
export async function cancelSubscription(subscriptionId: string) {
  return stripe.subscriptions.cancel(subscriptionId)
}

If regional requirements genuinely force two processors, gate the second behind a RegionBillingAdapter interface and ensure webhook handlers share subscription state in a single subscriptions table.