Payment Orchestration Layer

Problem

The client was locked into a single payment provider with unfavorable rates and no failover. When Stripe experienced an outage, all revenue stopped. The existing checkout code had payment logic sprinkled across the codebase, making provider switches a months-long engineering effort.

Approach

We designed a payment orchestration layer that abstracted provider-specific logic behind a unified API:

1. Core orchestration — A single POST /api/charges endpoint that routes to the configured provider
2. Provider adapters — Pluggable modules for Stripe, PayPal, and future providers
3. Circuit breaker — Automatic failover to a secondary provider on timeout or error threshold
4. Idempotency — Every charge request is idempotent, preventing duplicate charges

Architecture decisions

• Adapter pattern: Each provider implements the same PaymentProvider interface. Adding a new provider is a single file.
• Redis for rate limiting and circuit state: In-memory performance without state loss on restart (Redis persistence).
• Database-backed ledger: Every transaction is recorded in PostgreSQL for reconciliation and reporting.

Outcome

Metric	Before	After
Payment providers	1	3 (Stripe, PayPal, reserve)
Monthly volume capacity	$500k	$2M+
Provider switch time	months	hours (config change)
Stripe outage impact	100% revenue loss	0% (automatic failover)