Home
Razorpay logo
Razorpay · Agentic Product Case Study

From Discovery to First Payment

How three AI agents turned a 5-day merchant onboarding journey into a 30-minute conversation, and why the only metric that mattered was the user's first payment collection.

There's a question that most fintech onboarding never asks. Teams measure signups, KYC completion rates, activation numbers, each team celebrating its own conversion. But nobody asks the question that actually determines whether a merchant was worth acquiring: did they collect their first payment?

At Razorpay, we started asking that question. The answer was uncomfortable.

Merchant activation funnel · before intervention

Visitors
100%

↓ 88% drop-off

Signed up
12%

↓ 95% drop-off

Activated
0.6%

↓ 62% never transact

First payment
~0.2%

88% of visitors left before signing up. Of those who did sign up, 95% abandoned the process. But the number that kept me up was the last one: of merchants who had completed every step we asked of them, every document uploaded, every compliance gate cleared, every credential received, only 38% ever collected a payment.

These merchants were “done” by every internal dashboard. But done and activated are not the same thing. A merchant who cannot confidently accept money from a real customer has not reached value. The median time to first payment was five days. For most, it was never.

The decision was to own the full journey, from the moment a merchant lands on the website to the moment they collect their first rupee, and measure everything against that single outcome. What emerged, across 200+ merchant conversations and months of behavioural data, was not a problem in one stage. It was a compounding failure across an entire journey that nobody owned end to end.

Imagine you are a merchant arriving at Razorpay for the first time.

You want to accept payments. That's it. A simple, clear intention. But the website you land on features over 80 products: Payment Gateway, Payment Pages, Payment Links, Smart Collect, Route, each with its own page, its own jargon, its own signup flow. The catalogue is organised by Razorpay's internal architecture, not by what you're trying to do. You don't know what a “Payment Gateway” is versus “Payment Pages.” You just want to get paid. There is no one to ask. No guided discovery, no recommendation system, no way to say “I run an online store and I want to accept cards” and get a straight answer. A quarter of the people arriving are developers evaluating the platform for their companies. 40% are employees sent by their boss. Everyone sees the exact same static experience. 65% of first visits are from mobile phones, but mobile converts 37% worse than desktop because the experience wasn't built for it. You're overwhelmed. You leave. You are one of the 88%.

But suppose you don't leave. Suppose you pick a product, guess correctly, and sign up.

Now you enter the onboarding flow. It is 20 to 25 screens long. Over 50 manual input fields. The system demands information in a rigid sequence that reflects how the database is structured, not how you think. It wants your CIN before it will accept your Aadhaar. You are a solo founder on your phone. You expected something you could finish in ten minutes, the way you sign up for anything else. What you get instead is a 45-minute government form. The same form a funded company with a compliance department sees. You get confused halfway through and want to ask about pricing. There is no way to do that without abandoning your progress. Two internal compliance teams, working independently, make overlapping demands: one asks you to clarify your use case, the other asks you to update unrelated pages on your website. Neither knows what the other has already asked. You are exhausted. You close the tab. You are one of the 95%.

But suppose you are extraordinarily persistent. You finish the form. Your KYC clears. Your account is activated.

And then the silence begins. During the sales process, there were calls, emails, human warmth. Now, nothing. You are dropped into a transactional dashboard with no guidance, no context, no sense of what to do next. You are terrified to accept a real payment. What happens if it fails? How do you issue a refund at midnight? When does the money actually land in your bank account? The number on your dashboard doesn't match the number in your bank. Nobody explains why. The trust gap between “account activated” and “confident enough to accept real money” is enormous. And the system does absolutely nothing to bridge it.

Now your developer needs to integrate. They open their IDE and start switching between four disconnected surfaces: the Razorpay dashboard for API keys, the documentation site for guides, the IDE for code, and the browser for testing. Every switch costs 10 to 15 minutes of mental reconstruction. There is no real-time feedback. Signature verification errors, the single most common problem, are discovered hours later when a test payment silently fails. And you, the founder, the person who actually cares whether this business gets paid, have zero visibility into any of it. The Razorpay dashboard shows nothing. No progress bar. No status. The first signal anyone receives is an attempted test payment, which might come after 2 hours of work or 20 hours of frustration. Over 2,000 integration support tickets arrive monthly. 60 to 70% of them are about first-time setup.

This was not one broken stage. It was a system designed to exhaust, not intentionally but through years of accumulation, where each team optimised its own gate and nobody optimised the journey.

We were forcing humans to speak database instead of making our system speak human.

That sentence, spoken by a merchant during a research call, became the design principle for everything that came next. The insight was simple: every stage of this journey, discovery, onboarding, integration, was a place where an intelligent agent could replace friction with conversation, rigidity with adaptation, and silence with real-time guidance. Not automation for its own sake. Agents because the problem was fundamentally about understanding intent and acting on it.

Three agents. Three stages. One metric.

Agent 1 · Product Discovery

The obvious fix for the 88% drop-off was redesigning the website, simplifying the product catalogue, restructuring navigation, building a better pricing page. But the discovery work told a different story. The problem wasn't that merchants couldn't find the right product. It was that they shouldn't have to look.

Merchants think in outcomes. “I want to accept payments on my website.” “I need to send invoices.” “I want international cards.” No amount of cleaner navigation would bridge the gap between how a merchant thinks and how 80 products were organised. And the developer segment, 25% of visitors and often the person who decides which payment provider their company uses, had no way to interact with the platform before committing. Competitors offered live API playgrounds. Our documentation had hardcoded snippets. Developers left for Postman and didn't come back.

So instead of redesigning navigation, we eliminated it. The solution was an AI concierge, Smart Assist, that lets merchants describe what they need in natural language and maps their intent to the right product stack in real time. It draws from Razorpay's entire knowledge base using a retrieval-augmented approach, supports voice and text in English, Hindi, and Hinglish, and proactively nudges users when it detects friction: when someone lingers too long on a page or keeps returning to the same section. It doesn't wait to be asked. It reads the behaviour and intervenes.

Before

80+ products in an internal taxonomy. No guided discovery. Static docs with hardcoded snippets. Same experience for everyone. 5–10s page loads. 65% mobile traffic, 37% lower mobile conversion.

After

Conversational AI mapping natural-language intent to products in real time. Multilingual voice and text. Proactive nudges on friction. 4× engagement over the legacy rule-based system.

+13%
Visitor-to-signup
Engagement vs. legacy
+6–7K
Incremental merchant IDs

The surprise was multi-product adoption. Merchants weren't just finding the right product, they were discovering capabilities they didn't know existed. Adoption rose from 1.83 to 1.89 products per user. The agent was doing what a great salesperson does: listening first, then recommending a complete solution rather than the first thing that fits.

Agent 2 · Onboarding

When you see a 95% drop-off in a 25-screen form, the instinct is to cut screens. Fewer fields, progressive disclosure, a cleaner UI. That would have helped. It would not have been enough.

The problem wasn't the number of screens. It was the interaction model. Forms are adversarial by design: they demand information in a fixed order, punish mistakes with error states, and offer no way to ask a question or get context without breaking your flow. Our merchants were people who ordered dinner on Swiggy and returned shoes on Amazon. They expected that level of fluidity from a payments platform. What they got was closer to filing a tax return.

The segmentation made this harder. Registered businesses, just 5% of KYC submissions but 90% of all GMV, needed professional efficiency and upfront checklists. Individual merchants and sole proprietors, 90% of volume and 70% on mobile, needed radical simplicity. A single static flow could never serve both. The system needed to understand who it was talking to and adapt in real time. That is fundamentally what agents are for.

The form was replaced with a conversation. The solution was an agentic onboarding platform, an AI agent named Shreya, that collapses the entire journey into 3 to 5 conversational steps. When a merchant shares their Business PAN, Shreya reaches into government databases and auto-fetches everything else: company address, CIN, date of incorporation, directors' details. If a document has a mismatch, she catches it instantly through real-time OCR and asks for a correction on the spot, no more waiting days for a human reviewer to raise a clarification ticket.

Shreya adapts. If a merchant asks “What are your pricing charges?” mid-flow, she answers the question, holds the context, and walks them back to where they left off. If they close the browser and come back three days later, she picks up exactly where they stopped. She speaks English, Hindi, and Hinglish. She meets people where they are, on their phone, in their language, at their pace.

Before

20–25 screens. 50+ manual fields. Rigid sequences reflecting database logic. One flow for freelancers and funded companies alike. Siloed compliance teams. 45-minute average. Manual verification taking days.

After

3–5 conversational steps. Auto-fetching from government databases. Real-time OCR. Adaptive flow by merchant type. Persistent state. Multilingual voice and text. Context-aware mid-flow Q&A.

45m → 2m
Onboarding time
77%
Zero document uploads
+22%
Signup-to-activated

77% of merchants completed onboarding without uploading a single document. Shreya fetched everything she needed. When you remove the work, you remove the drop-off.

Agent 3 · Integration

Here is the insight that changed the shape of the entire project: a merchant who has cleared KYC and received their API keys but hasn't completed the technical integration has still not collected a payment. By every internal measure they are activated. In reality, they are stuck. And Razorpay couldn't even see them.

The obvious answer was better documentation, clearer guides, more examples, a revised quickstart. But the problem wasn't the quality of the docs. It was the model. Documentation assumes a developer will read, understand, and implement. In practice, developers were drowning in context switches across four disconnected surfaces, discovering errors hours after making them, and working in a local environment invisible to the rest of the company. The founder, the person who actually cares whether the business gets paid, had no idea if their developer was 30% done or completely stuck.

And the ground was shifting. 40% of incoming developers were already using AI-native tools: Cursor, VS Code Copilot, Windsurf. That number is projected to reach 60 to 70% within two years. These developers don't want to read documentation. They want to describe what they need and have it built. The opportunity was to meet them exactly where they already work.

The answer was to bring Razorpay into the developer's environment. The result was an MCP-powered autonomous integration agent, Razorpay AutoPilot. A developer types a natural-language prompt in their IDE: “Set up Razorpay Standard Checkout for my Node.js app using test keys.” The agent detects the project stack, generates the backend routes and frontend components, installs dependencies, configures environment variables, and validates the entire integration in real time, checking key formats, simulating order creation, and verifying webhook delivery, so that errors that used to surface hours later now surface before the developer has moved on.

But the most important piece solved the visibility problem. As AutoPilot completes each step inside the developer's IDE, it syncs progress to the merchant's Razorpay Dashboard through WebSockets. A live tracker updates in real time, Backend Ready ✅, Webhooks Verified ✅, giving the business owner a window into a process that was previously a complete black box. For the first time, a founder can see what's happening without interrupting their developer.

Before

Four disconnected surfaces. 10–15 min lost per context switch. Errors found hours later. Zero visibility for business owners. 2,000+ support tickets monthly. 60–70% of new merchant tickets about first-time setup. 6–8 hours typical, often days.

After

Natural-language prompts in the IDE. Autonomous code generation, config, and validation. Live progress syncing to dashboard. Secure OAuth key provisioning. Core generation under 3 minutes.

~3 min
Core integration time
+75%
Merchants reaching live
~2 wks
Revenue acceleration per merchant

A merchant who describes their intent to an AI concierge instead of scrolling through 80 product pages. Who completes onboarding in a two-minute conversation instead of a 45-minute form. Who integrates through an autonomous agent in their IDE instead of 20 hours of context switching and silent debugging.

That merchant collects their first payment in about 30 minutes.

The old median was five days. For most, it was never.

5d → 30m
Time to first payment
+13%
Visitor-to-signup
+22%
Signup-to-activated
+75%
Activated-to-live

The temptation in product work is to optimise the stage you own. Improve the signup page. Streamline the KYC form. Write better docs. Each one is a reasonable project. None of them, alone, would have moved the number that mattered.

The most impactful decision wasn't choosing what to build. It was choosing what to measure. First payment collected. That single metric reframed discovery, onboarding, and integration from three separate products into one continuous journey, making it impossible to declare victory at any stage where the merchant hadn't yet collected their first rupee.

The product doesn't end at activation. It ends at value delivered.

What this taught me

“Choosing what to measure is the highest-leverage product decision you can make. KYC completion and signup rate are metrics any team can celebrate in isolation while a merchant is still stuck. First payment collected is different: it's a forcing function that makes gate-keeping impossible. When no team can declare victory until the merchant has gotten paid, everyone starts asking the same question. What's still in the way?”