ADR-002: Stripe Architecture
Date: 2026-09-15
Status: Accepted | Superseded | Deprecated
Deciders: Pete Carroll
Context
Status: Core flow, payment model, and the Stripe ownership question are all settled. Two real strategic questions remain open (Section 6). Not yet built.
Purpose: a single, durable reference for the cross-service signup design worked through across keystone-spike-build-log.md (Entries 12–13) and keystone-build-log.md (Entries 1–2) — those entries are the chronological record of how this was decided; this document is the settled what, kept current as the design evolves.
Decision
Payment is collected before any provisioning happens — nothing gets created until Stripe confirms the charge succeeded.
This is a deliberate, settled decision (Section 2), not an oversight: the original sketch of this flow had the form submission itself trigger everything, which risked real orphaned accounts if someone abandoned checkout. The corrected version starts the whole sequence from Stripe's own webhook instead.
Why Command Center orchestrates, not Keystone or RoundTrip: signup's primary decision is commercial (which product, which tier, what price) — credential creation is secondary to that. Command Center already owns the commercial data (Tenant, Subscription); Keystone deliberately owns nothing beyond credentials, and RoundTrip is just one of several products this flow can lead to.
Why the Keystone call happens before Tenant/Subscription creation, not after: the person's plaintext password should exist in memory for the shortest possible window — one request to Keystone — rather than being held anywhere in Command Center's own process while other steps run.
A real, honest UX tradeoff worth naming: the person now waits briefly on a "finishing setup" screen after Stripe redirects them back, rather than being instantly signed in the moment they submit payment — since the real orchestration only starts once the webhook arrives, asynchronous relative to the checkout redirect completing.
Alternatives Considered
What else did we evaluate and why did we reject it?
Consequences
What does this decision mean going forward? What becomes easier? What becomes harder?
Related
Linear tickets, other ADRs
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | month 2026 | Pete Carroll | description |