Case study: Paytm Payment Gateway
Lightning Checkout lets a shopper pay on a merchant’s website with a mobile number, a one-time code and a saved address. I led its design from the first screen to the failure states.
Shoppers retype the same name, address and payment details on every site. Baymard’s survey data shows 17% of shoppers who abandon a cart blame a long or complicated checkout.1
Identify the shopper by mobile number, verify with a one-time code, then reuse their saved addresses and preferred ways to pay.
I owned the flow architecture, interaction design, visual design and the states for when things go wrong.
Merchants who sell online need a checkout they can add to their storefront without building one. Lightning Checkout adds an accelerated flow on top of Paytm Payment Gateway. It recognises a returning shopper, brings their saved addresses and preferred payment methods, and keeps offers in view.
Online shoppers re-enter the same contact, address and payment details on every merchant site. That slows them down, invites address mistakes and gives them more places to quit. Merchants have no ready-made checkout that remembers a shopper they have never met.
I combined published usability research with public benchmarks for accelerated checkouts. This is secondary research. Figures published by vendors are marked as vendor claims, and I note where a source does not give its sample.
Average cart abandonment rate across 50 studies from 2006 to 2025.
Baymard Institute1Average form fields in a checkout. Baymard says most sites need only 8.
Baymard Institute, 20242Conversion gain the average large site could get from checkout design fixes.
Baymard Institute, based on tests of large US and EU sites1Share of e-commerce orders placed as cash on delivery.
ET Prime Research, 2024, as cited by Razorpay7COD orders returned to origin, against 2–3% for prepaid orders.
Razorpay. The article gives no source for this figure7UPI transactions in July 2026, the highest month in UPI’s first decade.
PTI via YourStory, Aug 20268Shoppers could name more than one reason, so the bars add up to more than 100%. The “where this flow responds” tags are my own mapping.1
18% of abandoners left because a site asked them to create an account. I identify shoppers by mobile number and OTP, with no password to invent or remember.
The average checkout asks for 11.3 fields. A returning shopper in this flow types two inputs, a mobile number and a code. A first-time shopper fills seven address fields, inside Baymard’s 8-field benchmark.
Extra costs are the top reason to leave, at 40%. Delivery date and charge appear on the address step, and the order total stays on screen from start to finish.
Card declines and site errors each cost sales. Every failure state names the problem and offers a way forward, usually another payment method.
UPI runs at national scale, and most orders are still cash on delivery. UPI apps get first-class treatment in the payment step. COD is an option with a visible fee, because returns on COD orders cost merchants far more than on prepaid ones.
Impact figures below are published by the vendors or the merchants themselves. They are claims, not independent studies, and none of them describes Lightning Checkout.
| Product | How it knows the shopper | What it does for them | Reported impact |
|---|---|---|---|
| Shop Pay4 | Recognises a shopper with a Shop Pay account after one click, or without any action if they used it recently | Pre-fills their information | Up to 50% conversion lift over guest checkout and about 4x faster, per Shopify (2023) |
| Link by Stripe5 | Email address, then a one-time code by SMS on a new site or device | Fills saved payment details | 14% average conversion increase for returning users, per Stripe |
| Razorpay Magic Checkout6 | Not described in the case study | Puts all payment methods on one screen, validates addresses, can disable COD for high-risk orders | One merchant reports order conversion up 75% and prepaid share rising from 30% to 70% (2023) |
| Lightning Checkout | Mobile number, then a six-digit OTP | Brings saved addresses and preferred payment methods, keeps offers in view | Not yet measured |
Baymard’s tests give specific, checkable findings. I used them as a review checklist.23
| Published finding | What this flow does |
|---|---|
| 89% of sites split the name into several fields, and 42% of test participants typed a full name into the first-name field at least once | One Name field |
| 35% of sites that have a promo field show it by default | The promo field lives inside the offers sheet, not on the main path |
| 84% of sites do not delay account creation | There is no account step. Identity comes from the OTP |
| 28% of mobile sites have neither postal-code detection nor address lookup | PIN code comes first, and city and state follow it |
| Auto-detected fields can be overlooked or wrong, and need a fallback | City and state stay editable. I flag how visible the change is in the review |
These three segments are hypotheses built from the research above. I would confirm them in interviews.
I organised the flow by what the shopper has to decide at each step. Secondary tasks such as the offers list, the address list and the add-address form open as bottom sheets, so the main path is never lost. Order context stays on screen throughout.
Always on screen: merchant name with Verified badge, order total and summary, offers strip, and a secure-payment footer.
Ask for what we cannot know. Fill in the rest.
The total, the offers and the delivery cost never hide.
Side tasks open in sheets and return to the same place.
Say what happened, then offer the way out.
The map follows a returning shopper through seven steps, and notes where a first-time shopper’s path differs. It is built from the flow and the research, and the feelings are hypotheses to test, not measurements.
Swipe sideways to see all seven steps.
| Row | Step 1Place order | Step 2Identify | Step 3Verify | Step 4Deliver | Step 5Offers | Step 6Pay | Step 7Result |
|---|---|---|---|---|---|---|---|
| Goal | Buy what is in the cart | Get through quickly | Prove it is me | Get it to the right place on time | Not miss a saving | Pay the way I trust | Know the order went through |
| What they do | Tap Place order on the merchant site | Enter a 10-digit mobile number | Wait for and enter a six-digit OTP | Confirm the saved address and pick a delivery option. First-timers add an address | Check offers and apply a coupon | Choose a preferred card or UPI app and tap Pay Securely | See success, or retry after a failure |
| Screens | Entry | Number entry | OTP, OTP error | Address, address list, add address, suggestions | Offers sheet | Payment, UPI | Payment failed |
| How they feel |
Solid green line: the order goes throughDashed red line: the payment fails |
||||||
| Risks | An unfamiliar checkout under an unfamiliar brand | A mistyped number, and not knowing why it is needed | The code is late, wrong or expired | A wrong default address, an undeliverable PIN, a surprise delivery charge | Leaving to hunt for codes elsewhere | An unclear total, an unfamiliar method, a bank step-up | A failure that feels like a dead end |
| Design response | Merchant name, Verified badge, order total, “5000+ orders last month” | +91 prefilled, numeric keypad, consent text beside the button | Autoread, 30-second resend, Change number, specific errors, alternate verification | Delivery promise, priced options, seven-field form with PIN first | Offer strip, one sheet, applied offers stay visible | Preferred methods first, cashback chips, sticky Pay button with the amount | Plain-language reason and one-tap retry with another method |
| How I would measure it | Entry to number-submit rate | Submit rate, invalid-number rate | OTP success rate, resend rate | Time on step, address edit rate, unserviceable-PIN rate | Offer view rate, coupon application rate | Payment success rate, method mix | Retry-to-success rate, abandonment after failure |
Typed inputs for a returning shopper: a mobile number and an OTP. Autoread can remove the second.
Typed inputs for a first-time shopper: number, OTP and seven address fields.
Average form fields in a checkout.2 That count covers the whole checkout, so treat this as a rough yardstick.
A selection of key screens from the flow. Scroll sideways.
Why. Forced account creation made 18% of abandoners leave.1 A mobile number and OTP is a check Indian shoppers already know from banking and delivery apps. One field and one button leaves little to get wrong.
Trade-off. A shopper meets an OTP on each new site or device. Review finding 1 looks at skipping it.
Why. The OTP is the one step the shopper cannot do alone. The number is shown with a Change link, the resend timer is visible, and the error appears next to Resend OTP. I also designed states for an expired code, too many attempts and alternate verification.
Trade-off. Six separate boxes look clear but need careful autoread and paste handling in build.
Why. Extra costs (40%) and slow delivery (20%) are two of the top reasons to leave.1 The saved address carries a delivery promise, and the four delivery options show date and price before payment. An address that cannot be served is tagged in the list.
Trade-off. Delivery options add a decision to the address step. I pre-select the option that matches the promise.
Why. The average checkout has 11.3 fields and most sites need 8.2 This form has seven, with PIN code first so city and state can follow it.3 Typing a house number suggests saved addresses, and Save as lets a shopper label the result.
Trade-off. Auto-filled city and state can go unnoticed or be wrong, so they stay editable.
Why. Shoppers who hunt for a code often leave to find one. An offer strip shows the count, one sheet holds everything, and an applied offer stays visible on every step. The promo field sits inside the sheet, which matches Baymard’s advice to hide it.2
Trade-off. Coupons and payment offers share a sheet but behave differently.
Why. Saved cards sit at the top with their cashback, UPI apps are one tap away, and the Pay button states the amount. When a payment fails, the sheet gives the reason in plain words and offers other methods. Card declines (10%) and thin method choice (9%) both cost sales.1
Trade-off. Offering cash on delivery as a retry saves the order but raises delivery risk. See review finding 2.
More than a quarter of the screens are error, recovery or edge states. Each one says what happened and what to do next.
Returning shoppers still verify each time. Offer “remember this device” with consent, so a recognised shopper can skip the code. Shopify says Shop Pay recognises many returning shoppers without any action, though that is its own claim.4
It rescues orders when UPI fails, but Razorpay reports 25–30% of COD orders are returned against 2–3% for prepaid, though it gives no source.7 Make COD and its fee a merchant setting, and track returns by the way the order was recovered.
| Metric | What it tells us |
|---|---|
| Checkout completion rate | Whether more shoppers who tap Place order finish paying |
| Payment success rate | Whether payments go through once attempted |
| Time to pay | How fast the flow is for each segment |
| OTP success and resend rates | Whether the verification step is a hurdle |
| Address-related delivery failures | Whether address help reduces bad deliveries |
| Retry-to-success rate | Whether the failure sheet recovers orders |
Moderated sessions with five to eight participants per segment, on real phones. Tasks:
I would record whether each task is finished without help, time on task, and where people hesitate or misread a screen.
Pages read in October 2026. Vendor and merchant figures are claims, not independent studies.