The Liquidity Gate
When the payment provider goes down, revenue doesn't go with it.
The incident
The payment gateway had an outage on the biggest sales day of the quarter. Checkout returned errors for forty minutes. The postmortem's most painful line: a second, healthy provider was already integrated for a different flow — there was just no routing layer to fail over to it.
Why the obvious approach fails
Integrating one payment provider hardcodes a single point of failure into the revenue path — and provider outages, degraded card networks, and regional declines are routine, not exceptional. The naive fix, try/catch around the charge call, fails subtly: without idempotency across providers you risk double-charging on ambiguous failures, and without decline-code intelligence you retry hard declines that will never succeed. Failover is a routing problem with financial-safety constraints, not an exception handler.
The standard
- Payment execution goes through a routing layer, never directly to a provider SDK from business logic.
- 5xx and network-class failures fail over to the secondary provider automatically; hard declines (insufficient funds, stolen card) never retry anywhere.
- One idempotency scope spans providers: a failover retry cannot double-charge across gateways.
- Routing is also policy-aware — cost, currency, and method preferences are configuration (route local rails locally, international cards to the global provider).
- Provider health is tracked continuously; sustained degradation shifts primary routing before it becomes an outage.
How Cortex validates it
At plan time
The blueprint declares the provider set, routing policy, and failover semantics per payment method.
At validation
assert: charge_path.providers >= 2assert: failover_retry.idempotency_scope == "cross_provider"assert: hard_declines.retry == neverAssertion syntax is illustrative.
At review
The approver sees the failover drill: primary forced down, transactions completing on secondary, zero duplicates in the ledger.