StatusPLANNED — Q1 foundation in progress
DriverJared Goguen (engine), Frontend Engineering (UC expansion)
Repossubscriptions-api (PM gate), billing-webhooks (event handling), stratus (UC + frontend)
Staffing2 engineers backend, 1 engineer frontend

Q1 ships the foundation that makes everything in this spec safe. Act 1 sets Stripe parameters on every payment path so subscriptions confirm before committing state. The Continuation Workflow defers entitlement provisioning to payment success — if payment fails, nothing was granted, nothing to undo. Together they prove the core invariant: no entitlement without payment. With that proven, the PM gate becomes unnecessary.

0
rollbacks after Continuation
0
entitlements without payment

The Q1 foundation. Act 1 migrates all Stripe API call sites to confirm-before-commit parameters. The Continuation Workflow moves entitlement provisioning to the payment success path. Rollback code is deleted.

Two deliverables in sequence, one independent. Q1 foundation unlocks both.

Act 1 + Continuation confirm-before-commit payment-paths continuation-workflow Q1 ✓
Deferred Collection remove-pm-gate client-secrets subscribe-first UNLOCK
Unified Checkout one-component card-paypal-3ds stripe-js SURFACE
Stripe API default-incomplete pending-if-incomplete payment-intents PAYMENT BEHAVIOR
unlocks unlocks payment_behavior params Stripe.js / Elements
Q1 2026
Act 1 + Continuation
Early Q2
Deferred Collection
Q2 (parallel)
UC Q2 Cohort
6
endpoints with PM gate checks
402
HTTP status code (error 1210)
~160
tickets/month from PM-related blocks

Six endpoints check for a valid payment method before allowing subscription changes. If no PM exists, or the PM is expired/invalid, the request fails with HTTP 402 (error 1210). This blocks legitimate users from subscribing — especially new customers who haven't added a payment method yet.

After: the engine returns a client_secret instead of blocking. The frontend uses Stripe.js to collect payment with the customer present. The subscription activates on payment success.

PhaseWhatDetailReversible?
1PM validation softeningDowngrade 402 to warning in non-critical paths. Measure impact.Yes
2Gate removalRemove PM checks from all 6 endpoints. Return client_secret on missing PM.No — commitment point
3Frontend integrationDashboard renders Stripe.js when client_secret returned. Card, PayPal, 3DS inline.Yes (feature flag)
4Error handlingPayment failure UX. Retry flow. Expiry handling.Yes
5MonitoringAlert on payment failure rates, conversion rates, time-to-payment.Yes
6CleanupDelete PM gate code, old error paths, 402 documentation.No (forward only)

Deploy backend first (API returns client_secret instead of 402 — old frontend still works), then frontend (Stripe.js Elements renders when client_secret detected). 5 subscription endpoints change from 402 to client_secret. Exception: billing profile allows update without PM.

9
products joining UC in Q2
1
Stripe.js component for all products
3
checkout systems being replaced

Unified Checkout (UC) replaces three checkout systems: Multisku checkout, Billing Profile payment method management, and legacy per-product payment flows. One Stripe.js component handles card, PayPal, and 3DS for every product. Q2 adds 9 products. Independent of the PM gate chain — runs in parallel.

All 9 currently on Multisku. Medium complexity (usage-based pricing): Workers Paid, R2, Stream, Durable Objects. Low complexity (fixed pricing): Pages, Images, Queues, D1, Vectorize.

One new invariant enforced in Q2. The deliverable is not done until the invariant is enforced at all three tiers.

#InvariantProperty
I4No PM gate rejectionsZero 402/1210 responses across all 6 endpoints. client_secret returned instead.
I4 · Enforcement

Inline: gate code deleted — absence IS enforcement. Batch: not needed. Alert: pm_gate_rejection_rate metric — alert if > 0 for 15+ minutes.

W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
W13
W14
PM Gate + Frontend
Frontend · 1210 Prep
PM Gate · Observe & Prep
PM Gate · Remove
Frontend · Client Secrets Default
PM Gate · Cleanup
Unified Checkout
UC · Q2 Cohort (9 products)
DeliverableShipsDepends OnΔ/moEstimate
PM Gate RemovalEarly Q2Continuation (Q1 ✓)−201+1+2 weeks
UC Q2 CohortQ2 (parallel)9 products, ~1 week each
#DecisionOwnerBy WhenStatusRecommendationRisk if Wrong
1Complete list of error 1210 consumersEngineeringJun 16 (PM P2)OPENCode search + runtime monitoringCritical — broken UX
2PayPal UX through Stripe.js ElementsEngineeringJun 23 (PM P3)OPENEnd-to-end testHigh — PayPal users blocked
3Subscription conversion rate baselineProductJun 9 (PM P1)OPENInstrument before removing gateMedium — can't measure impact
4Multisku sunset — products remaining after Q2?Frontend EngMay 15OPENTrack remaining productsLow — Multisku persists Q3
RiskImpactOwnerMitigation
Premature gate removalCriticalEngine leadContinuation workflow must be proven first. Removing the gate without payment ordering causes drift.
Unknown 1210 consumersCriticalFrontend EngAudit all frontend and API consumers of error 1210 before Phase 2. Missed consumer = broken UX.
PayPal UXHighFrontend EngPayPal through Stripe.js Elements — test end-to-end. Redirects may not work inline.
Conversion regressionMediumProductPhase 1 metrics before Phase 2 commitment. Investigate if conversion drops.
WhatWhy
ProbationSeparate track. Probation customers already have service. Policy enforcement, not payment ordering.
Shadow billing / ReactorSeparate workstream. Validates the billing engine, but not part of this quarter's checkout scope.
Product-specific UC pricingEach product may have custom pricing/display logic. Frontend team handles per-product testing.
Dunning / bad debtCovered by the Honest Invoicing workstream.