REFERENCE
Payment Data Flow
The PDE payment sequence — what data gets created, in what order, in which systems. The green safe zone has zero committed state. The amber commitment point only executes after payment is confirmed.
Data flows through the payment sequence — steps 1–4 are the green zone with zero committed state. Step 5 is the amber commitment point. Step 6 is final reconciliation. If anything fails in the green zone, just stop.
| Step | Our DB | Stripe | Can Roll Back? |
|---|---|---|---|
| 1. Customer Intent | nothing | nothing | N/A — nothing exists |
| 2. Validate | nothing | nothing | N/A — nothing exists |
| 3. PaymentIntent | nothing | PaymentIntent only | Yes — cancel PaymentIntent |
| 4. Confirm | nothing | PaymentIntent confirmed | Yes — cancel PaymentIntent |
| 5. Commit | subscriptions written | Subscription created | Complex — but payment is confirmed |
| 6. Reconcile | final state | final state | N/A — everything consistent |
Steps 1–4 have zero committed state in our database. The only external artifact is a Stripe PaymentIntent, which can be cancelled trivially. This is the key insight of PDE: confirm first, commit second. There is nothing in between to clean up.
- 4
- steps with zero state
- 0
- rollbacks needed
- 1
- commitment point
Interim state while payment resolved. No longer needed because payment is confirmed before any state is committed. The entire package becomes dead code.
Retrying charges against already-committed subscriptions. No longer needed because subscriptions don't exist until payment succeeds. The retry logic and its failure modes disappear.
The ordering inversion eliminates an entire class of failure modes. Confirm first, commit second — there is nothing in between to clean up.