Nimbbl 1-Click Checkout

The sheet is not a page the buyer travels to: it opens over the merchant's own storefront, carrying the merchant's logo and order summary, so the buyer never feels handed off to a stranger holding their money.

The greeting does the real work: a recognised buyer is addressed by name and told their fast options are ready, before any method list appears. Everything below that line is a fallback for people the system doesn't know yet.

Recognition is the feature. The sheet doesn't treat every buyer the same: it checks what it already knows, from a device it's seen before down to nothing at all, and adjusts the flow rather than asking everyone the same questions.

The escape hatch matters just as much as the fast path. Shared devices are normal, so "not you?" is a first-class control rather than a support ticket.

Fast payments are the promise in the product's name: saved instruments the buyer can fire in a single tap. The interesting design problem is not the happy path but its absence.

A buyer with nothing saved must not be shown an empty shelf and left to guess. The zero state explains why it's empty and what to do instead, which is what keeps a first-time buyer from reading "1-click checkout" as a lie.

UPI looks like a single button and behaves like four different products. A saved VPA, a fresh VPA, an intent handoff into a payment app, and a non-intent collect request each have their own timing, their own failure modes, and their own idea of where the buyer's attention goes.

Designing this meant refusing to pretend they're the same. Each path gets its own sequence, and the buyer is told which one they're on, because a collect request that silently waits looks identical to a broken screen.

Cards carry the most steps of any method: number, validation, an issuer OTP on someone else's page, and a processing wait the checkout does not control. Every one of those is a place to lose the sale.

The design compresses what it can and narrates what it can't: validation happens inline as the number is typed, errors resolve in place, and the OTP and processing waits are given honest, legible states instead of a blank screen.

Credit at checkout is where Indian payments get genuinely hard. EMI plans vary by bank, tenure and category, and none of it is the checkout's to decide.

A tenure list with every bank in it is unusable, so the choice is staged: category first, then plan, with the cost of borrowing stated where the decision is made.

BNPL lenders each bring their own eligibility, auto-debit behaviour and authorisation model, and none of it is the checkout's to decide either.

The honest move was to surface the lender's rules as the buyer's states. "Delayed authorisation allowed" and "not allowed" are two different products behind one button, and the buyer is told which one they're standing in.

A checkout spends more of its life failing than most designers admit. Sessions expire, buyers hit the X, OTPs never arrive, and lenders time out mid-authorisation.

This is the part of the work I'd defend hardest. A session timeout with a visible counter, an exit that asks before it discards a cart, and a retry that offers alternatives rather than repeating the thing that just failed: these are what decide whether a payment is recovered or lost.

The fastest way to lose a buyer at the last step is a number that changes without explanation. Dynamic currency conversion and international cards both move the amount after the buyer has decided.

So both are disclosed before they're charged: conversion shows the before and the after, and international cards get their own summary rather than a surprise on the statement.

Convenience fees are the other number that can move at the last step. And offers, done badly, get buried in a coupon field the buyer has to go hunting for.

So a fee is named at the method that carries it, and stated as absent where it doesn't apply. Offers appear at the method that unlocks them instead.