Razorpay Guide: India's Entity Requirement and Subscription Implementation

Razorpay Guide: India's Entity Requirement and Subscription Implementation

Planning India as one more payment method to connect is the usual first reaction and the first mistake. Entry into India is fundamentally an entity question: an overseas entity usually cannot connect directly to a local acquirer, so it either establishes a local entity or connects indirectly through a cross-border aggregator. The second difficulty hides inside subscriptions. India auto-debit channels have gone through repeated rule tightening, which affects three stages: authorisation, first charge and retry. Those three have to be designed per channel, and copying a card-based subscription implementation almost always fails. This guide separates these two problems and gives a comparison of three entity routes plus concrete subscription design points.

1. Where It Fits: Indian Local Acquiring

1.1 The problem it solves

India payment structure differs sharply from mature markets. UPI holds the leading position in online payments, cards and bank redirects still matter but are no longer the only entry point, and local wallets remain active among particular segments and scenarios. A merchant connected only to an international card scheme loses a meaningful share of orders that would otherwise complete in India.

The value of a local acquiring platform sits here: it bundles UPI, cards, bank redirects and wallets into one interface and one account structure, so the merchant does not connect to each separately. Razorpay, whose home ground is the Indian market, belongs to this category, covering those mainstream methods and offering subscription and split settlement product capability.

1.2 What it is not

First, it is not a general gateway you can open casually. Its onboarding flow and entity requirements are built around a local Indian entity. That reflects the local entry structure rather than a product choice.

Second, it is not the simplified picture where UPI is just one more button. UPI confirmation, failure reasons, refund paths and reconciliation rules are entirely different from cards, and treating it as a card variant is the first problem to surface after go-live.

Third, it is not a cross-border acquiring platform. An overseas entity wanting to collect in India usually needs an indirect route, which is a different organisational approach from connecting cards on a global platform. For the wider picture of regional methods start with the Local Payment Methods by Region Guide.

2. Onboarding and the Entity Barrier

2.1 Why an overseas entity cannot get in

For Indian local acquiring platforms, the central variable in onboarding is not technical capability but the entity. The flow verifies a locally registered operating entity, a local bank account, tax identification and evidence of business substance. The purpose is direct: to confirm that the recipient of funds is traceable, regulatable and accountable locally.

An overseas entity sits in a mismatched position within that structure. It can prove it is a genuine operating company, but proving local operating substance is much harder. This is not a matter of preparing better documents; it is a structural mismatch. So the answer to whether you can get in usually depends on whether you have a local entity, not on how good your website is.

This differs from Latin America. Latin American local acquirers can often process transactions through their own local entity, letting overseas sellers participate indirectly. Indian local acquiring platforms more often serve entities already established locally. That structural difference directly determines which route to take.

2.2 Comparing three routes

Since direct access usually requires a local entity, three routes remain in practice. The table below puts prerequisites, suitable teams and main limits together.

There is no standard answer for the trade-off. Judge on three things: the weight of India in your overall business, whether you can absorb the fixed cost of maintaining an entity, and how much control you need over pricing and the buyer relationship.

For general entity and account design see the Cross-Border Seller Entity and Account Structure Guide, and for licensing and filing on the compliance side see the Payment Compliance and Licence Filing Guide.

3. Integration and Account Structure

3.1 Account structure and KYC

The account structure of an Indian local acquiring platform usually hangs off one KYC cleared entity. Sub-accounts, multiple business lines and multiple storefronts are organised inside the platform, but the underlying entity is single. For a multi-line business this means transactions from different product lines leave traces under the same entity, and sub-accounts cannot be used to isolate operational risk.

The depth of KYC is worth anticipating. Beyond entity documents, the business model description, product pages, refund policy and support channel are all verified. This is not one-off: material changes to entity information, business scope or model usually require resubmission.

So prepare two things before integrating: a material pack that explains the business, and an internal agreement on who updates it when something changes. The second is often forgotten and is exactly where problems appear once things are running.

3.2 Three things the server must get right

Whichever acquirer you integrate, the server has to get three things right: idempotency, the state machine and reconciliation.

Idempotency means the same creation request arriving twice must not produce two payments. Webhooks from UPI-style methods can be delivered more than once, so a creation endpoint without an idempotency key easily produces double payments on one order. For patterns see the Payment Order Number and Idempotency Design Guide.

The state machine means created, awaiting payment, in progress, succeeded, failed, expired, refunding and refunded states must close properly. UPI usually confirms quickly, but its failure reason categories are finer than cards, and the state machine has to carry those categories or support cannot give accurate explanations.

Reconciliation means order records must match the settlement report line by line. India adds one more layer: subscription charges and one-off payments appear in the same report and need a shared identifier to separate them, or reconciliation rules stay muddled indefinitely.

4. Core Capabilities and Market Coverage

4.1 What is covered is method types

When assessing an Indian local acquiring platform, do not ask how many methods are supported. Ask which of the methods your target customers actually use are supported.

UPI is the lead and the depth of its coverage decides whether most orders complete. Cards still matter, especially for cross-border audiences and high ticket sizes. Bank redirects hold a meaningful share in particular segments and categories. Local wallets remain a useful supplement in some scenarios. These methods differ in failure reasons, refund paths and reconciliation rules and cannot be handled with one flow.

Also watch for structural differences in success rate. Different methods perform very differently across customer segments, and an overall success rate hides the problem. For analysis method see the Payment Success Rate Optimization Guide.

4.2 Subscriptions and auto-debit

Subscriptions are the most underestimated part of the Indian market. Many teams assume that storing a card enables automatic renewal, and that is not how it works. India auto-debit channels have gone through repeated rule tightening, and the changes hit authorisation, first charge and retry, whose implementation differs across channels.

Subscription design therefore has to be modelled per channel rather than copying card-based subscription logic. The table below separates the key points, constraints and design suggestions.

For subscription methodology see the Subscription Billing API Integration Guide, and for recovery after failed charges see the Subscription Dunning and Recovery Guide.

5. Fee Structure and Real Cost

5.1 Fee components

Fees for Indian local acquiring are a set of components rather than one number.

Current rates and conditions belong to the official quote and the signed contract. Any percentage appearing in an article will go stale, and budgeting from old numbers is the most common error of all.

5.2 How to judge the real cost

Comparing headline rates side by side is the easiest mistake at this stage. The right method is to build a transaction mix that matches your business: the same method share, the same customer segments and the same amount bands, then compare total cost and final received amount.

In India two extra dimensions apply.

The first is entity maintenance cost. If you establish a local entity, registration, bookkeeping, audit, tax filing and annual maintenance are fixed expenses that never appear on a rate card. The second is the hidden cost of subscriptions. Authorisation failures, first charge failures and retry failures translate directly into churn, and comparing rates without subscription retention is biased.

On an indirect route, add settlement timing and FX exposure to the calculation, because a longer path means funds spend longer in transit. That affects cash flow more than the rate difference usually does.

6. How It Divides Work With Other Options

6.1 Against cross-border aggregators

The value of a cross-border aggregator is covering several emerging markets through one interface, which suits the market validation stage. In India their local method coverage usually depends on partner channels. The method list may be sufficient, but success rate and refund experience may not match a local acquiring platform.

Ask four things when choosing: which methods are covered, where settlement lands, how refunds flow, and whether failure reasons can be broken down. Those four decide whether the indirect route can actually run.

6.2 Against global platforms and local peers

The strengths of a global acquiring platform are mature interfaces, complete documentation and standardised multi-currency support. They suit mature-market card volume better, and local method depth in India is usually not their strong point. When evaluating, compare the market focus and settlement structure of Adyen and Stripe.

Indian peers also differ in focus. Where the business touches wallets or specific scenarios, look at the product positioning of Paytm, PhonePe and Payu. The basis for choice is not who is larger but whose method depth and settlement path fit your target customers.

For the wider regional picture see the India Payment Guide, which lays out mainstream methods and onboarding traits for the market.

7. Who It Fits and Who It Does Not

7.1 Good fit

First: teams already established in India with a local entity and a long-term commitment. This is the natural audience for a local acquiring platform, where the entity, bank account and business scenario sit in the same jurisdiction and the route is shortest.

Second: teams with a high share of subscription business that need authorisation and retry designed per channel. Local platforms have deeper accumulated capability in this product area.

Third: teams running platform or marketplace business that need split settlement. Split rules and the timing of fund arrival are tightly linked, and a localised implementation fits the local settlement structure better.

7.2 Weak fit

First: teams without an Indian entity that only want small-scale market validation. Direct access usually does not work, and an indirect route or merchant of record model should come first.

Second: teams selling mainly into mature markets with India as a tiny slice. Carrying entity maintenance cost for a tiny increment does not pay off.

Third: teams demanding very strong control over pricing and the buyer relationship while refusing local tax and invoicing responsibility. Under most routes these two requirements are mutually exclusive, so decide which side you take first.

Fourth: teams that understand subscriptions as storing a card and renewing. That route almost certainly fails in India; build authorisation and retry design capability before discussing launch.

8. Rollout Notes and Common Misreadings

8.1 Rollout notes

The first point matters most. Many teams do technical selection first and only later find the entity route does not hold, forcing a redesign. The route question has to be settled at selection time.

8.2 Common misreadings

The first misreading is assuming an overseas entity can connect directly the way it would to an international acquiring platform. Onboarding for Indian local acquiring platforms is built around a local entity, and an overseas entity is structurally mismatched. This is not a documentation problem.

The second misreading is assuming that storing a card enables automatic renewal. Auto-debit rules change frequently, and authorisation, first charge and retry all need per channel design. Copying card-based subscription logic most often shows up as a successful first charge, a failed first renewal and a wave of churn.

The third misreading is assuming split settlement replaces a fund compliance architecture. Splitting decides how funds are allocated across parties. It does not decide who is entitled to collect the money or which jurisdiction taxes it.

The fourth misreading is assuming UPI is just another payment button. UPI failure categories, refund paths and reconciliation rules all differ from cards, and treating it as a card leaves support and finance confused at the same time.

More acquiring and local payment options are listed under Payment, organised by acquiring capability, local method and market region.

Note: this article is based on public information and general provider mechanics. Current rates and onboarding conditions are subject to the provider official pages and the signed contract.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.