Table of Contents
Broad payment coverage gets shoppers to your checkout. Knowing which method to show them first is what gets them through it.
The first part is something the payments industry has worked hard on for years. At Cashfree, our checkout supports 180+ payment methods, and we keep adding to that list as new ways to pay emerge. Coverage is foundational, and we keep investing in it.
This blog is about the second part. Once a checkout supports the methods shoppers want, the question that follows is which one to surface first for each shopper. That’s where the intelligence side of checkout comes in, and we think it’s where the next meaningful gain in checkout conversion lives.
Coverage is the floor, not the ceiling
Here’s the math that makes the case for intelligence. A typical Indian shopper uses one or maybe two payment methods regularly. They land on a checkout that shows fifteen or more. Coverage is doing its job. Sequencing isn’t. The shopper still has to find their method, and that hunt is where attention frays and orders quietly die.
We covered the broader abandonment problem in our Checkout 2.0 piece: friction at checkout is rarely about one big failure. It’s the accumulation of small ones. And among those small ones, “the method I always use isn’t where I expected it” is one of the most fixable.
The question isn’t “do you accept their method”
For years, the central question merchants asked of their payment stack was “do you accept everything my shoppers might want to use?” That question is largely settled now. Most checkouts do.
The more interesting question, the one we think defines the next phase of checkout optimisation, is “do you show it at the very top of the checkout, exactly when the shopper is about to choose?”
The cost of a generic default is real. When the top of checkout doesn’t match what the shopper actually uses, they do one of three things. They hunt for their preferred method, which is a drop-off risk. They default to something they don’t usually use, which is a higher failure rate risk. Or they postpone, intending to come back later, and many don’t.
None of these are coverage problems. They’re sequencing problems. And sequencing is one of the problems payment intelligence is built to solve.
What payment intelligence actually does
Payment intelligence isn’t one thing. At Cashfree, it shows up across several layers of how a transaction works: retrying failed transactions on the path most likely to succeed, routing transactions across bank networks intelligently, flagging fraud signals before they hit settlement, and personalising what the shopper sees at checkout. Each of these is its own engine, with its own signals and its own outcomes.
This blog is about the last of those, the personalisation layer. And inside that layer, the most direct lever on conversion is what we call the Preferred Payment Methods engine. Its job is straightforward: for every returning shopper, surface the payment method they’re most likely to complete the order (using a particular mobile number), right at the top of checkout.
What’s underneath that is less obvious. The engine doesn’t operate at the level a merchant might configure manually. It looks at the shopper’s past successful transactions with Cashfree Payments, the specific PSP they used, the device they’re on, and a few other behavioural signals. It then makes a per-shopper recommendation that gets refined over time.
The insight that took us a while to articulate, and that we think reshapes how to think about payment optimisation, is this: preference is specific. It’s not “UPI.” It’s “GPay” It’s not “card.” It’s “the Apple Pay token I set up last quarter, on this iPhone.” Generic categories aren’t preferences. They’re starting points.
Most checkouts that claim to be intelligent still stop at the broad category. They might push UPI to the top because the shopper used UPI last time. That’s better than nothing, but it’s a fraction of what the data can do. Real intelligence goes a level deeper, to the specific app or instrument the shopper actually uses. Not just “UPI” but GPay. Not just “card” but the Apple Pay token saved on this iPhone.
Two upgrades that go a level deeper
We’ve recently extended the Preferred Methods engine in two ways that make this concrete.
The Preferred Methods engine now surfaces specific UPI apps too. Earlier, the engine didn’t surface UPI Intent Apps in the preferred methods section at all. The reasoning at the time was straightforward: the UPI Intent row already sits at the top of every checkout, so a shopper who preferred UPI could just tap their app from there. Adding it to Preferred Methods felt redundant. But when we looked at the data, that assumption was leaving conversion on the table. Surfacing a shopper’s specific UPI app, say GPay or PhonePe, as their personalized preferred option, in addition to the generic intent row, drove a measurable uptick in conversion. Recognition matters: a shopper seeing their own app recommended to them by name behaves differently than one self-selecting from a list.
Apple Pay now joins as a recognised preferred method. For shoppers on eligible Apple devices who’ve used Apple Pay before, it now surfaces as their preferred method. Not because they happen to be on iOS, but because their behaviour says so. The distinction matters. Device-based defaults assume; behaviour-based defaults know.
Both upgrades are live across SDK, web, and mWeb. Eligibility checks happen automatically, and merchants don’t need to configure anything.
A different audit question for merchants
If your checkout already has broad payment coverage, the question to ask of it is no longer “what’s missing?” It’s something more like:
- For my repeat shoppers, how often does the method at the top of checkout match the one they actually want to use?
- When my checkout recommends a method, is it pointing to a broad category like “UPI,” or to the specific app the shopper actually uses, like GPay?
- How quickly does my checkout learn from a shopper’s first successful transaction?
- Is there a difference in conversion between shoppers who see a personalised top option and those who see a generic one?
These aren’t questions about coverage. There are questions about intelligence. And the gap between a checkout that handles them well and one that doesn’t is, increasingly, where conversion is won or lost.
This is the thinking that shapes Cashfree’s Checkout. Coverage is the foundation, and we keep building on it. On top of it sits a set of intelligence engines: smarter retries on failed transactions, bank network routing, fraud signals, and the personalisation layer this blog has focused on. The Preferred Payment Methods engine is one piece of that personalisation work, and it’s the piece we’ve found has the most direct impact on conversion. If you’re auditing your checkout against the questions above and finding gaps, we’d be happy to walk you through how we’ve thought about closing them.
Coverage gets shoppers to your checkout. Intelligence gets them through it. The platforms that get both right, expanding what they support while getting smarter about what they show, are the ones that will quietly take share over the next few years.
