DeviceDestination
Turned model-number chaos into a guided buying and checkout experience.
Electronics buyers arrive knowing the exact model number they want — a conventional catalogue is useless. They need to land on the right variant, confirm it, compare alternatives, check GST-inclusive price, pay and get an invoice.
ECOMMERCE
DeviceDestination
- Role
- Design, full-stack engineering and payments architecture
- Scope
- Product discovery and exact-model search, comparison, cart and checkout, GST-safe pricing, Razorpay integration, invoice generation, notifications, authentication.
- Outcome
- A buyer finds the exact model, compares it, pays safely and receives a correct invoice — and when the payment provider’s webhook is slow or fires twice, the order still ends up correct. The commerce behaviour does not lose money to edge cases.
- Technology
- Next.js, TypeScript, Drizzle ORM, Razorpay, Tailwind CSS, Vercel
Disclosure. Deployed ecommerce application. Verify the current deployment before publishing the link publicly.
Buyers in this category do not browse — they arrive knowing the exact model number they want. A conventional catalogue front page is useless to them. They need to land on the right variant, confirm it is the right one, compare it against the one they almost bought instead, check the GST-inclusive price, pay, and get an invoice they can file. Most storefronts optimise for browsing. This one had to optimise for certainty.
- Model-number-first buying behaviour
- GST-safe pricing that survives partial checkout and refund paths
- Payment reliability under webhook delay, duplicate callback and network failure
- Invoice generation that matches the payment state, not the request state
- Authentication that does not block the buyer from checking out
- Mobile checkout with a long specification list
The structural decisions that shaped the solution — explicit and arguable, not hidden inside a polished screen.
- 01
Discovery by model number
Designed discovery around exact-model search and guided comparison, not category browsing.
- 02
Checkout as a saga
Treated checkout as a saga with idempotent steps, not a single optimistic request.
- 03
Payment is source of truth
Made payment verification the source of truth — the order’s state follows the payment, not the other way around.
- 04
Invoice tied to verified payment
Kept the invoice tied to the verified payment record so a failed notification can never produce a phantom invoice.
- 05
Guest checkout
Let buyers check out as guests and claim the order later, so auth never costs a sale.
- Exact-model search with comparison against nearest alternatives
- Idempotent checkout keyed to the payment attempt
- Webhook recovery so a delayed or duplicate Razorpay callback reconciles instead of duplicating
- Invoices generated from the verified payment record, not the cart
- Notifications fired from order-state transitions with safe retry
A buyer can find the exact model, compare it, pay safely, and receive a correct invoice — and when the payment provider’s webhook is slow or fires twice, the order still ends up in the right state. The commerce behaviour is boring in the best way: it does not lose money to edge cases.
- Exact-model search
- Discovery built around model numbers
- Comparison
- Variant comparison before checkout
- GST-safe pricing
- Consistent across checkout and refund paths
- Payment verification
- Razorpay with idempotent reconciliation
- Webhook recovery
- Duplicate and delayed callbacks handled
- Invoice generation
- Tied to verified payment record
- Authentication
- Guest checkout with later claim
The payment succeeded but the notification failed on the first real order. That is the moment most ecommerce systems fall apart — the order exists in the payment provider but not in the database, or worse, exists twice. The whole architecture was built so that exact scenario reconciles instead of corrupting. It did.
Discovery
Built exact-model search and comparison.
Checkout saga
Designed idempotent checkout steps.
Payments
Razorpay integration with webhook recovery.
Invoices
Generated from verified payment records.
Technical material kept secondary — for the engineering reader who wants to look under the hood.
- Checkout modelled as a saga: each step (reserve, charge, verify, fulfil) is idempotent and reconcilable.
- Razorpay integration uses signature verification plus an independent server-side status poll so a missing webhook cannot orphan an order.
- Pricing is computed server-side from a single GST-aware function reused by cart, checkout, invoice and refund paths.
- Notifications are emitted from order-state transitions with at-least-once delivery and idempotent consumers.
DeviceDestination — wrap-up