CLOUDFLARE FINTECH ENGINEERING
The PayGO Platform
The platform that processes every subscription change, payment attempt, and invoice across Cloudflare's self-serve business. Three domains cover the full surface — from customer identity to recurring revenue. This site maps the system, diagnoses the structural flaw, and tracks the work to fix it.
The PayGO billing system divides into three domains. Each owns a distinct responsibility. Together they cover the full surface from customer record to collected revenue.
The customer record — payment methods, billing address, email, account state. Holds the instruments but never charges them. Bad debt accrues here and consequences execute here (cancellation, service suspension).
subs-api → changes_calculator. What the customer is buying and the on-session payments that happen during checkout. Currently entangled — subscription state, payment processing, and entitlement provisioning are one indivisible ball.
System-initiated charges, invoice finalization, dunning retries, the usage pipeline, and threshold billing. No user in the loop — the system acts on its own. Uncollectible invoices feed bad debt back to Accounts.
Payments split across domains — user-initiated (on-session) lives in Subscriptions, system-initiated (off-session) lives in Billing. Accounts holds the payment methods but never charges them.
Six processes form a continuous cycle from customer action to revenue — and back again when things go wrong. The cycle crosses all three domains. Every failure in one domain eventually surfaces in another.
The loop closes when dunning exhausts retries and escalates to account-level consequences — bad debt, payment method enforcement, service cancellation. Revenue failure in Billing becomes identity crisis in Accounts.
Internal models mirror Stripe's models. PayPal is shimmed. Every seam between domains leaks state because there is no shared truth — only local copies that drift. The evidence is not ambiguous.
The system's internal models are shaped by Stripe's API. This single design choice cascades into every failure mode — rollbacks, state disagreements, bad debt from uncollectible invoices.
Payment-driven entitlements, a unified dunning engine, provider abstraction, and own-the-lifecycle checkout. Each resolves a specific failure mode.
Critical path through PDE → Dunning → Checkout. What's shipped, what's in flight, and what's next. Sequenced so each step compounds the last.
Inverts the current model. Payment confirmation becomes the gate that entitlements must pass through — not an afterthought.
Replaces scattered retry paths with a single recompute engine. Graduated consequences from a unified view of account health.
A single checkout surface — payment method collection, 3DS authentication, and subscription creation as one atomic flow.
The Braintree Bridge for PayPal parity. Canary deployments for payment changes. Structured tracing across the pipeline.
The full sequence from intent to revenue — green zone, confirmation point, and commitment.
3DS, deferred collection, and the regulatory constraints on when the system can charge.
The timing gap between access granted and payment confirmed — and how PDE closes it.
The recompute model — deriving state from Stripe truth instead of tracking deltas.
Six stores, fragmented truth, and the target architecture that unifies them.
Composite state across dual subscriptions — the trickiest data problem in the platform.
Three domains, one structural fix. Start with the domains to understand the system, or the diagnosis to understand the problem.