05
TL;DRProvider timeouts left paid orders without an eSIM → orders as a state machine with automatic refunds → failed provisioning resolves itself instead of becoming a ticket.
- Role
- Full-Stack Engineer
- Client
- Travel e-commerce · EU
- Year
- 2025
- Stack
- Next.js, TypeScript, Supabase, Stripe
In one paragraph
Orders as a state machine with automatic compensation on provider failure. Failed provisioning resolves itself through refunds instead of support tickets.
Context
An eSIM is delivered in seconds or the customer disputes the charge. Payment capture, provider provisioning and QR delivery had to behave as one flow.
Problem
The provider API sometimes timed out mid-purchase, leaving paid orders with no eSIM and a support ticket.
What I did
- 01
Orders as a state machine
paid → provisioning → delivered | refund-pending. Every failure mode has a defined next step instead of a stuck order.
- 02
Compensation
If provisioning fails after payment, the refund triggers automatically and support is notified in Telegram.
- 03
Delivery
Activation QR by email and Telegram, plus a self-service page to fetch it again.
Results
0
manual steps from checkout to activation
Stack
- Next.js
- TypeScript
- Supabase
- Stripe
- Telegram Bot API