Edge-state checkout flow
Declined cards, expired sessions and retries designed in from the start.
All Projects
Web · Embedded checkout & payments
Designing a checkout that survives a traffic spike, not just a demo
A checkout and payments flow redesigned around its worst-case load, not its happy-path prototype — conversion held steady through a 12x seasonal spike.
Start a Project- Client
- Orrery
- Industry
- E-commerce checkout & payments infrastructure
- Year
- 2025
- Duration
- 10 weeks
- Role
- Web engineering + load testing
- Team
- 4 engineers, 1 SRE
- Platform
- Web
The challenge
The existing checkout was designed and tested against a clean, low-traffic sandbox, so its failure modes — a declined card, an expired session, a retried payment — only surfaced under load no one had rehearsed for. A checkout that only works in the demo isn't a checkout, it's a prototype with a payment form attached.
Approach & solution
Approach
We started from the flow's worst-case state, not its happy path. Every screen was designed and built against declined cards, expired sessions and retried payments first, with the clean-path checkout falling out of that as the easy case rather than the only one considered.
Solution
A checkout flow redesigned around its own edge and error states, a payments component library the merchant team now builds new pages from, and a load test rehearsed against 12x normal traffic before the first real spike hit it.
What shipped
The capabilities behind the screens.
Edge-state checkout flow
Declined cards, expired sessions and retries designed in from the start.
Payments component library
The merchant team builds new pages from it instead of forking a screen.
12x load-tested
Rehearsed against seasonal peak before the first real spike hit it.
Safe payment retries
A retried charge resolves once, never as a duplicate.
Merchant-embeddable widget
Drops into a merchant's own storefront without a redirect hop.
Real-time conversion monitoring
Drop-off at each checkout step, visible the moment it happens.
Tech Stack & Architecture
The client-side architecture and interface layer shipped for this engagement.
3 tools · 1 primary
Services, APIs, and business logic running the system end to end.
3 tools · 1 primary
Datastores and pipelines chosen for this engagement's consistency and throughput needs.
2 tools · 1 primary
Deployment, orchestration, and delivery tooling running the platform in production.
3 tools · 1 primary
System architecture
Technical challenges
Rehearsing a 12x spike without a load test that lies
A synthetic load test with unrealistic traffic shapes would have passed cleanly and still failed on the real spike. Load was modeled on the merchant's actual prior seasonal traffic curve, not a flat ramp, so the rehearsal matched what would actually hit the system.
Handling retried payments without double-charging
A slow network response can make a shopper retry a payment that already succeeded. Every charge attempt carries an idempotency key tied to the cart session, so a retry resolves to the original charge instead of creating a second one.
Keeping a shared component library from forking per merchant
Merchant-specific checkout tweaks tend to calcify into one-off forks. Customization points were scoped to theming and copy only, with flow logic staying identical across every merchant embed.
How it was built
The stages this engagement ran
01
Brief & Strategy
1 week
Reviewed the prior season's traffic logs to find where the sandbox-tested checkout actually broke.
02
Strategy & Planning
1 week
Edge-state coverage and the 12x load target agreed before a screen was drawn.
03
UX & UI Design
2 weeks
Declined, expired and retried states designed first; the clean path came last.
04
Development
4 weeks
Checkout flow and component library built together, so no page skipped the shared states.
05
QA & Optimization
1.5 weeks
Load-tested against a modeled 12x traffic curve, not a flat synthetic ramp.
06
Deployment & Support
0.5 weeks
Shipped ahead of the season's traffic ramp, with the SRE on call through the first spike.
Results
What changed, in the numbers.
“The old checkout passed every demo and failed the first real Friday. This one has now survived three.”
Renata Silva · VP Product · Orrery
Selected screens
Orrery, in the product
Related work
Works you may also like.
Technical briefingNot a sales desk