Design a Payment System, stage 4 of 13: model
Which transitions can happen?
An attempt's states are created, processing, succeeded, failed and refunded. Information about it arrives from three directions: the provider's synchronous response, webhooks, and the reconciler. Decide which of these statements about transitions are true.
System so far· 4 parts
Select a component to see what it is responsible for and which state it owns.
- 1Buyer's browser → Payment provider: Card entry and 3-D Secure in hosted fields
- 2Buyer's browser → Checkout API: Pay (Idempotency-Key header); poll status
- 3Checkout API → Postgres: Claim attempt; conditional transitions
What you need to know
A state machine lists which moves are allowed. Two rules make one robust when information arrives from several directions:
- Move only on facts. A decline is a fact; a timeout isn't.
- Move forward only. Each transition names the state it starts from, so a late or repeated message can't drag the state backwards.
In SQL, each move is
UPDATE … SET status = 'succeeded' WHERE id = $1 AND status = 'processing'. See State machines for business state.Check
An attempt is 'succeeded'. A delayed 'processing' webhook for it arrives. With forward-only transitions, what happens?Money coming back after a success isn't "succeeded became failed". It's a new move,
succeeded → refunded(or a dispute), recorded as its own event. History is appended to, never rewritten.Think first
The API response, a webhook and the reconciler all learn that attempt 77 succeeded, at about the same moment. Each calls the same conditional transition. What happens?