SEMANTIC BILLING
Payment Loop
The full cycle from subscription change through payment confirmation through state commitment. The old model commits then charges then rolls back on failure. The new model confirms payment first using payment intents, then commits state. If payment fails, nothing was committed — nothing to undo.
PDE must ship before credit notes can reference clean invoices
registrar uses unified checkout which depends on PDE
subscription state determines when to collect
PayPal breaks the confirm-before-commit pattern
Today the system commits state before payment confirms, then attempts rollback on failure. This commit-then-pay ordering is the root cause of state drift, uncollected invoices, and rollback failures. Inverting to pay-then-commit eliminates the entire class of problems.
The old model committed state before payment confirmed — provision entitlements, publish events, attempt payment, then try to rollback on failure. Incomplete rollbacks left accounts in inconsistent state.
Subscription rollbacks per day. Current: ~200/day. Target: 0.
Payment confirms before state commits. If payment fails, nothing was committed. No rollbacks needed. This is the universal pattern that PDE enforces on every payment path.
PDE implements confirm-before-commit via Stripe's default_incomplete payment behavior. Subscription changes return a client secret. The frontend collects payment. State commits only after payment confirms.
The full payment sequence from subscription change through state commitment in six steps. Each step has clear preconditions and postconditions.
The payment method becomes a side effect of paying, not a prerequisite for subscribing. Users should be able to subscribe without a PM on file; the system collects payment at the moment of change.
On-session payments happen while the user is present (upgrades, new subscriptions). Off-session payments happen without the user (renewals, retries). Different Stripe payment behaviors apply to each.
Confirm-before-commit on all 5 payment paths. 6 phases — schedule elimination first, then payment path migration, then dead code deletion. Critical path for the entire Payment Loop.
Three workstreams in strict sequence: PDE Completion → Deferred Collection → Unified Checkout. Users can subscribe without a PM on file. The system collects payment at the moment of change.
Engineering dependency runs opposite to priority ranking. P4 (PDE rollout) must finish → payment method gate removed → P2/P3 checkout work → P1 Registrar migrates onto new checkout.
The most dangerous mistake: removing the PM gate before PDE completion. Without confirm-before-commit on all paths, removing the gate means the system commits changes and hopes payment works.
Q3 answered the existential question: can we flip the payment ordering without breaking on-session flows? Yes — rollbacks went to near zero.
Confirm payment before committing state. If payment fails, nothing was committed — nothing to undo.