Razorpay Product Manager Interview: Questions & Prep (2026)

Razorpay PM interviews test whether you can build products where the regulator is a stakeholder and a 0.5% metric move is a big deal. The loop typically runs recruiter screen → product sense/design round → a metrics and execution round → a hiring manager round, often with a leadership or values conversation at the end. Expect every case to live in payments: payment success rates, the UPI ecosystem, merchant onboarding funnels, settlements, and disputes. Candidates report two cultural signals get probed repeatedly — ownership (did you carry outcomes, not just features?) and first-principles thinking (can you reason from the merchant's economics rather than quote a framework?). What makes Razorpay different from consumer PM loops is that RBI compliance shows up as a product constraint, not a legal footnote: KYC requirements shape onboarding flows, and recurring-payment rules shape subscription products. If you're earlier in the funnel, start with the broader guide on [how to get hired at Razorpay](/company_guide/how-to-get-hired-at-razorpay.html).

1. Payment success rate for one large merchant dropped from 92% to 87% this week. Walk me through your investigation.
2. Design an onboarding flow that gets a small kirana-store merchant live in under 10 minutes — while meeting KYC requirements.
3. UPI dominates Indian payments but earns near-zero MDR. How should a payments company build a business around it?
4. A top merchant demands a feature that would take your team a full quarter. How do you decide, and how do you say no?
5. What metrics would you own as PM of the checkout product? Define your north star and its guardrails.
6. New RBI guidelines change how recurring payments work. Walk me through how you'd redesign the subscription-billing product and migrate existing merchants.
7. Merchants complain settlements are slow. Diagnose whether this is a real product gap or a communication gap, and what you'd ship.
8. Should Razorpay build lending products for its merchants? Structure the opportunity from first principles.
9. How would you reduce merchant churn in the first 90 days after signup?
10. Design a fraud-review experience that protects the platform without freezing legitimate merchants' money.
11. Tell me about a product decision you made that went against what a senior stakeholder wanted.
12. Estimate the number of digital payment transactions in India on a normal weekday, and stress-test your own estimate.

Q: Payment success rate dropped from 92% to 87% for a large merchant. Investigate.

*Situation:* At my previous fintech company, our largest merchant's transaction success rate fell four points over a weekend.

*Task:* As the payments PM, I owned root-causing it before Monday's business review.

*Action:* I decomposed the metric before hypothesising: by payment method (UPI vs. cards vs. netbanking), by bank, by error code, and by platform. The drop isolated to UPI transactions failing at one issuing bank with timeout errors — a bank-side degradation, not our stack. I shipped two mitigations: automatic retry routing through an alternate path where eligible, and a status page for the merchant so their support team stopped escalating blind.

*Result:* Effective success rate recovered most of the gap within two days despite the bank issue persisting, and the merchant renewed at higher volume that quarter. The lesson I'd bring to Razorpay: in payments, decomposition order matters — method → bank → error code — because the fix differs completely at each level.

Q: Design merchant onboarding that is fast and KYC-compliant.

*Situation:* I owned onboarding at a B2B platform where activation took three days and 40% of signups abandoned before going live.

*Task:* Cut time-to-first-transaction without weakening verification.

*Action:* I split the flow into what must block activation versus what can be progressive: document collection moved to auto-fetch (PAN and bank verification via API-based checks), manual review became exception-based rather than default, and merchants could start with capped transaction limits while full verification completed in parallel.

*Result:* Median time-to-live fell from three days to under four hours, activation rate rose 18 points, and compliance flags actually improved because structured auto-checks beat manual data entry. The principle: treat compliance as a design constraint to sequence around, not a wall at the front of the funnel.

Q: Tell me about a decision that went against a senior stakeholder.

*Situation:* Our sales head pushed hard to build a bespoke reporting suite for one enterprise prospect worth a large annual contract.

*Task:* As PM, I had to decide whether to commit the roadmap or push back.

*Action:* I reframed the debate from opinions to economics: I sized the build at two engineer-quarters, then interviewed five existing enterprise customers and found three would pay for a generalised version of just two of the requested reports. I proposed shipping those two as platform features and declining the rest, and presented the trade-off with numbers to leadership.

*Result:* We won the deal anyway on the partial commitment, the two reports drove adoption across a dozen other accounts, and the sales head became the biggest advocate of the sizing exercise. First-principles beats hierarchy when you bring the data.

For success-rate and metric questions, decompose in payments-native order: payment method → issuing bank → error code → platform/app version — segment before you hypothesise. For product design, anchor on a specific merchant persona (a D2C brand doing 500 orders a day looks nothing like a kirana store) and reason from their unit economics: what does a failed payment or a delayed settlement cost them? For build-vs-not decisions, use first-principles sizing — market, willingness to pay, regulatory exposure, engineering cost — and state what you'd deliberately not do. For anything touching compliance, show the pattern of sequencing around the constraint (progressive KYC, capped limits) rather than treating regulation as blocking. Keep behavioural answers in STAR with one quantified result each.

Candidates report Razorpay interviewers listen for three things. Ownership: stories where you carried a metric or a product end to end, including the unglamorous parts — migrations, escalations, compliance reviews. First-principles reasoning: they typically push past framework recitations with "why?" chains, and candidates who reason from merchant economics fare better than those who quote CIRCLES. Payments fluency: you don't need to have worked in fintech, but you should understand the UPI ecosystem's structure, why success rate is the industry's obsession metric, and why MDR economics make monetisation non-obvious. Comfort discussing RBI constraints as design inputs — rather than complaining about them — reads as a strong senior signal.

Week 1: build payments literacy. Map the lifecycle of a UPI transaction and a card transaction end to end, learn the vocabulary (success rate, MDR, settlements, chargebacks, tokenisation), and read Razorpay's public blog posts on product launches to absorb how they frame merchant problems. Week 2: drill five metric-decomposition cases (success-rate drops, settlement delays, churn spikes) aloud, in the method → bank → error-code order, and two monetisation cases from first principles. Week 3: prepare six STAR stories mapped to ownership, first-principles decisions, stakeholder conflict, and failure — each with a number in the result — and do at least one mock with a PM who has worked in fintech. Alongside prep, keep your pipeline warm: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit PM roles, and drafts hiring-manager outreach, so interview practice doesn't come at the cost of applications.

Treating Razorpay like a consumer app and designing for end shoppers instead of merchants — the merchant is the customer. Hand-waving compliance ("legal will handle KYC") instead of designing around it. Quoting frameworks mechanically when the interviewer wants first-principles reasoning about payments economics. Not knowing the basics of UPI's structure or why success rate matters, which candidates report is an early filter. Metric answers that jump to hypotheses before decomposing by method, bank, and error code. STAR stories about shipping features with no owned outcome. And inventing Razorpay internals — hedge with "I'd validate this against your data."