State-machine Driven Payment Flow
summary
Tinder replaces a legacy payment stack with a state‑machine + DSL implemented in the open source StateMachine library to make purchase flow deterministic, self‑documented and unit‑testable. The system models immutable purchase data, a flow executor, set effects for calling repositories and a rules resolver that runs composable rules for prevalidation and postprocessing. It supports multiple billers via pluggable coordinators, runs in production after years of reuse across features, handles billions of swipes and millions of matches and reports measurable KPI improvements.
AI-written summary · about
chapters (11)
- 0:00Introduction to payment flow
- 3:20Why payment foundation matters
- 7:11What is a state machine
- 11:53Modeling payment states
- 15:23State machine DSL and flow
- 21:22State transitions and coordinator
- 24:54Supporting multiple payment methods
- 27:01Composable rules for validation
- 31:44Real-world rule examples
- 33:52State machine in other systems
- 34:36Outcomes and recommendations
related talks
36mState Machine in Elixir with Machinery
46mState Machines (The Good, The Bad and The Ugly)
28mState Machines
30mDesigning an Extensible Billing Platform using Domain-driven Design
25mMastering UIs with Finite State Machines
41mWhat If We Implemented a State Machine to Help the Little Mouse?
18mFoundational building blocks for transactional applications
45mState of the Art User Interfaces with State Machines