ExpressBuy

PhonePe moves money for 400 million people inside one app. The buying itself happens elsewhere: on a small merchant's website, a Shopify storefront, an Instagram shop with a payment link. Between those two worlds sits a checkout form asking the shopper to type a name, an address, a phone number, and card details into a site they met five minutes ago. Most of them leave.

ExpressBuy was the bridge: one tap on the merchant's page, and PhonePe fills in the address and handles the payment while the merchant keeps everything else.

PhonePe at this point was a mature app. UPI Lite, UPI International, and the B2B payment gateway all came from the same push: use the scale and the data the app already holds to open new lines of business. ExpressBuy was one of those probes, and it was named a zero-to-one experiment on day one: build the smallest real version, put it in front of real merchants, and find out whether the business exists.

A large share of PhonePe users have saved their delivery addresses in the app; voluntarily, in one place. That combination is rare: payment behaviour on one side, self-declared delivery information on the other. The question behind ExpressBuy was direct. Can that database power a product of its own?

PhonePe's full B2B payment gateway serves merchants with volume; a D2C seller running a WooCommerce store or an Instagram shop cannot justify that onboarding. ExpressBuy took a thin slice of the same rails and added the two things a small seller cannot build alone: verified addresses and one-tap payment.

The pitch to the seller: concentrate on your product, hand the addresses, phone numbers, and payments to us. Logistics stayed with the merchant in version one; a courier partnership surface sat on the roadmap for later.

ExpressBuy's first screen belongs to the merchant. A cart page can stack several checkout buttons: the merchant's own gateway, Razorpay Magic, a UPI and cash-on-delivery checkout, and ours. Which buttons appear, and in what order, is entirely the merchant's call. The product has to win at a glance, on a surface it does not control, so the naming carried real weight; we iterated across Checkout with पे Express, Insta, and 1-click, in glyph-only and full-wordmark versions.

The placement pitched to preferred merchants was two buttons: the merchant's own checkout and ours. On an unfamiliar storefront the PhonePe button reads as the safe way to pay. The shopper trusts PhonePe with details they would hesitate to type into a stranger's site; the merchant recovers checkouts that would otherwise be abandoned at the payment step. Both sides get something from the same button.

The state of the shopper's phone decides the route.

• App installed, logged in: the cart hands off to the PhonePe app, and the user pays inside screens they already know.
• App installed, logged out: a bottom sheet on the merchant's page collects phone and OTP; the browser session signs the user into the app, so the crossover happens once, already authenticated.
• No app at all: the whole checkout runs on the web with PhonePe as an embedded sheet, ending on the standard NPCI PIN pad; the one screen every UPI user already knows stays untouched.

Every route runs on the same assets: the saved address, the saved payment instruments, the verified phone number. The web route also carries cash on delivery, because merchants asked for it.

Three rules ordered the flow. Detect before promising: the embedded script checks whether the app exists on the phone before offering it. Consent before takeover: a PROCEED button takes the user's explicit yes; the flow never pulls anyone into the app on its own. Transfer, then land: the cart context crosses over, and the user arrives on a Pay to screen with the merchant named, the order summarized, and the delivery address already filled in.

That prefilled address is the product in one screen: the thing the shopper did not have to type.

The split held on every screen. The merchant defines the cart items, the coupons, the shipping options and their prices; PhonePe holds the address and executes the payment. On the web route, coupon and cart data never leave the client. Inside the app, coupon data renders in PhonePe's screens while its rules, validity, and economics stay the merchant's throughout. The cart view is read-only on both sides.

This was deliberate. A payments company that can see a merchant's discount strategy is a payments company merchants hesitate to embed. Refusing data we did not need was part of the sales pitch.

A note on how the boundary closes the journey: the shopper started on the merchant's page, so the flow lands them back there, and the final screen ("Almost there! We are confirming your order," with a live countdown) belongs to the merchant's systems. PhonePe confirms the payment; only the merchant can confirm the order, and the design says so.

The coupon sheet carried one piece of intelligence: a Max Savings chip on the best code, so the system does the comparison the user would otherwise attempt across three near-identical offers. Full terms sit behind a Show More. Applying takes a visible beat of loading and lands on a message that names the saving in rupees; ₹150 is the number the user feels, and the code is just the key.

The applied coupon updates the order in place: a two-day shipping option drops to zero rupees with the discount explained on the option itself, and the total falls on screen. Manual code entry sits above the list, for the user who arrived holding one.

The landing screen already carried the merchant's identity, the cart summary, the address, and the coupons; asking for the payment there as well would have overloaded it. PhonePe also already had a payment surface: the bottom-sheet instrument list, which picks how money moves. Payment modes ask a different question: whether money moves now, at the doorstep, or on some future rail. Forcing modes into the instrument sheet would have meant retrofitting a system-wide component for one feature.

My call: a separate Payment Summary page. Modes live there as first-class options with room for what comes later: pay now, pay on delivery, pay later. The amount breakup stays visible without a tap: order amount, shipping charges, pay-now charges, total payable. Choose pay on delivery and the button changes its verb to PLACE ORDER, because no payment is happening now and the button should not claim one. Proceed to pay, and the standard instrument sheet opens, unmodified.

The post-payment screens are the fintech obligation. One anatomy across all states: transaction ID with a copy action, delivery details, items, the amount breakup, the debited instrument with its UTR. A green header for success, red for a failed transfer, orange for a payment in progress.

Every state carries the same note: "Your order will be delivered by BookMart Books. Please contact them for your queries." A shopper whose parcel is late will ask the payments company by default; the note redirects that question at the moment it forms. The action row repeats it in layout: merchant support, merchant website, merchant email first; PhonePe support last.

Ecosystem readiness. The product works only when several parties show up at once: willing merchants in volume, platform connectors, partner integrations. None of it is plug-and-play, and the product is only as strong as its weakest partner category.

Address quality. The database's accuracy was unproven: are user-entered addresses correct, current, deliverable? PhonePe had no machinery to verify them. Partnerships with address providers were floated, and every route ran into privacy: matching phone numbers is a breach, linking addresses to them is worse, and the clean path of explicit opt-in adds its own friction to the funnel. The data exists; using it safely costs conversion.

Unit economics. The numbers work only if D2C merchants actively want this, and market research at that scale was never commissioned during my time. The business case and the finances were waiting on each other.

A zero-to-one experiment exists to surface exactly these constraints. The organisation priced them against other bets and moved on.

ExpressBuy was built to answer one question: can PhonePe's saved addresses and payment rails carry a checkout on storefronts it does not own. The design answered its half of that question end to end: a button that earns the tap on a cart page stacked with rivals, three login states funnelling into one flow, a data boundary merchants could trust, and a payment surface with room for modes the app had never needed before. What slowed the project sat outside the screens: ecosystem readiness, address quality, and unit economics. The pilot ran, the project was de-prioritized, and the reasoning is on the record.