Map 3
How payment status and token state move
Two state machines sit under the flow. The payment statuses on the left already exist in EOPTIONAL_ORDER_PAYMENT; the token on the right is new, and the shape drawn here is a recommendation: One live token per order, killed and replaced on every resend. A declined first attempt deactivates the token, and the guest keeps the open session.
- Person step
- System step
- External integration
- Decision
- Unknown or TBC
- Exception or loop-back
Payment status · EOPTIONAL_ORDER_PAYMENT.STATUS
Token · new, one live token per order (recommendation)
Numbered markers on the diagram (Q1, Q2, Q6) match the question table on the overview.
Facts
- The five payment statuses are what exists in the database today. 242191
- A resend kills the old token. 240008
- A declined first attempt deactivates the token but must not end the guest's active session. 240003
Open questions
- Expiry rule, awaiting Scott Sarris. 242191 · Q1
- PCI and GDPR constraints on token content, storage and retention. 242191 · Q2
- Whether a new payment status is needed for “link sent” or “expired”, or link state stays on the token. The recommendation is drawn above. 242191 · Q6
- Address verification. 240003 · Q3