Website Requirements for a Payment Gateway

The paperwork is the easy half. The website is where applications stall

Every guide to getting a payment gateway in India is a guide to photocopying. PAN, GST certificate, cancelled cheque, certificate of incorporation, address proof, a board resolution if you are a company. That list is real, it is well documented, and you can assemble it in an afternoon because somebody else already has all of it in a folder.

Then there is a second list, which almost nobody writes down properly, and it is the one that actually holds applications up: a set of pages that have to exist on your live website, at their own URLs, saying specific things, before you submit. Not documents you upload. Pages you build.

This is the part people get wrong, and they get it wrong in a predictable way. They read that the site needs "a refund policy, terms of service, privacy policy and SSL", they paste four generated templates onto four pages, link them from the checkout, and submit. The pages exist. They say nothing. And the reason that fails is not pedantry: the person or the script reading your site is looking for particular facts — a number of days, a working phone number, a street address, a currency — and a template has none of them, because a template cannot know them.

So treat this as a build, with a sequence and a definition of done. Below is the sequence, what each page has to actually contain, and a check you can run on your own site before you submit. Every requirement is tied to the gateway's or the regulator's own published documentation, and every example is a page on this site, which we wrote for our own gateway review and which you can open and read.

What the gateway actually asks for

Start with the form, because the form is more specific than any blog post about the form.

When you add your business website in the Razorpay dashboard, you are not uploading a screenshot. You are filling in a set of URL fields, and the documentation lists them: Terms and Conditions, Privacy Policy, Shipping Policy, Contact Us, and Cancellation and Refunds. Adding a further site asks for About us, Contact us, Pricing details, Terms and conditions, Privacy policy and a Cancellation/Refund policy. The same page notes that "if you add or update your primary website, instant checks are run to validate your website, policy pages and business industry", and that you can add one main website and five additional websites.

Two things follow from that, and they decide most of the work.

Each one needs its own URL. A field that takes a link cannot take an accordion on your homepage, a modal that opens over the checkout, or a section you have to scroll to. If a policy does not have an address you can paste, it does not exist as far as the form is concerned.

A machine looks first. Instant checks run against the URLs you give and against the site itself. That is a very good reason not to hide a policy behind JavaScript, a cookie banner, a login, or a PDF download.

Other gateways ask for the same shape in different words. PhonePe's merchant guide to gateway registration asks for a privacy policy, terms and conditions, a refund policy "with clear timelines and eligibility conditions", and contact information "including business address, email address, and customer support details". Razorpay's own compliance guide is blunter still: display the legal entity name "as registered, not just a brand name", publish a physical address because "a PO Box will not suffice", and provide "a working email address and phone number".

Build for the strictest version and you have built for all of them.

Where the requirement comes from, and what changed in September 2025

This is worth two minutes because it changes who you are arguing with when something is refused.

For five years, the sentence everyone quoted was clause 7.2 of the RBI's Guidelines on Regulation of Payment Aggregators and Payment Gateways of 17 March 2020: "The merchant's website shall clearly indicate the terms and conditions of the service and time-line for processing returns and refunds." One line, directly addressed at your website, and the origin of every checklist you have read.

That circular is no longer in force. The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 — RBI/DPSS/2025-26/141, dated 15 September 2025 — consolidated the old guidelines and repealed them, the March 2020 circular included. And the new Master Direction contains no instruction at all about what a merchant's website must display. The word "website" appears in it three times: twice for the aggregator's own site, once for the Reserve Bank's.

What it does say still shapes your pages, just indirectly:

• The aggregator's agreement with you has to cover this ground. Clause 8(b): agreements between a PA, its merchants and its banks "shall clearly delineate the roles and responsibilities of the involved parties, inter alia covering manner of refunds, treatment of failed transactions, return policy, grievance redressal, reconciliation, etc."
• Extra charges must be visible before payment. Clause 10(c): a PA shall ensure "that any charges, other than the price of goods / service / investment amount, charged by a merchant, are distinctly displayed to the payer prior to the transaction."
• Refunds go back the way the money came. Clause 10(f): "All refunds shall be made to the original method of payment, unless specifically instructed by the payer to credit the refund to an alternate mode belonging to the same payer."
• The gateway has to check you out. Clause 13(c): "A PA shall undertake background and antecedent check of the merchant." Clause 13(h) adds that it must monitor your transactions afterwards to make sure they are "in line with latter's business profile". Clause 13(j) sets 1 January 2026 as the date from which every new merchant is onboarded under this due-diligence regime.

So the obligation did not disappear; it moved. It now reaches your website through the contract you sign with the gateway, and through consumer law, which applies to you whether or not you ever take a card payment. The Consumer Protection (E-Commerce) Rules, 2020, notified in the Gazette on 23 July 2020, require an e-commerce entity to display its legal name, the principal geographic address of its headquarters and all branches, the name and details of its website, and contact details for customer care and for a grievance officer; require a grievance officer to acknowledge a complaint within forty-eight hours and redress it within one month; and require a seller to show the total price in a single figure with the break-up, along with accurate information on terms of exchange, returns and refund, and on delivery and shipment.

The practical consequence: when a gateway refuses your site, you are not in a dispute with the RBI. You are failing a check written into a commercial agreement, which means the fix is always concrete and always on your side of the line.

The order to build them in

The pages are not independent, which is why writing them in the order the form lists them is slow and produces contradictions. Terms has to agree with the refund policy. The refund policy has to name a delivery event that the delivery policy defines. Both have to point at a contact route that exists. Pricing has to state a tax position that Terms repeats.

So decide the commercial facts first, then write them down once each.

1. Decide six things on paper. How many days a customer has to ask for a refund, and from what event. What you will not refund, and why. When the customer gets what they paid for. What you charge, in what currency, with what tax on top. Who answers the phone, and between what hours. Your exact legal entity name as it appears on your PAN or registration. Everything below is these six answers, formatted.
2. Contact, because every other page ends by pointing at it.
3. Cancellation and refunds, the page most applications are sent back over.
4. Shipping and delivery, including the case where nothing is shipped.
5. Terms, which can now reference the three pages above instead of restating them.
6. Privacy, which describes what the site and the gateway each do with data.
7. Pricing, once the numbers and the tax position are settled.
8. The footer, wiring all of them into every page. Last, and not optional.

On this site those six are /contact/, /refund-policy.html, /shipping-policy.html, /terms.html, /privacy.html and /pricing/ — open any of them and you are reading the worked example for the rest of this article. Flat, obvious, permanent paths are the right choice here: these URLs go into a dashboard form, into confirmation emails and into the footer of every page, so they are the last URLs on your site you should ever want to change.

Contact: an address, a phone number and a person

A contact form is not a contact page. The form is fine, and ours has one, but the reviewer is looking for three facts the form does not supply.

A full operational Indian address. Not a city. Not a PO box. Not "Bengaluru, India". Building or door number, street or locality, town, district, state and PIN code. If you trade from home, that is the address; a sole proprietorship operating from a residence is an ordinary thing and hiding it is what causes the problem.

A telephone number that is answered, with the hours it is answered between. A number nobody picks up is worse than no number, because contact-point verification is a real step in merchant due diligence and a dead line reads as a dead business.

An email address on your own domain. A Gmail address on a site that has its own domain invites the question of whether the site and the business are the same thing.

Then add the two things consumer law asks for and gateways increasingly check: your legal entity name exactly as registered, and a named route for grievances. Razorpay's compliance guidance expects a grievance officer's "full name, designation, email address, and phone number" published prominently; the e-commerce rules set the forty-eight-hour acknowledgement and one-month redressal clock on that role.

Our contact page is the shape of it: the registered business name and its MSME Udyam registration number, the full postal address down to the PIN code, one email, one phone number, the hours as "Monday to Saturday, 10:00 to 18:00 IST", and a stated reply time of one business day. Nothing clever. It just answers the questions.

Cancellation and refunds: a number of days, and a named condition

This is the page that gets applications refused, and it fails for one reason: it is written to avoid committing to anything. "Refunds are at the discretion of management." "Refunds may be processed in a reasonable time." A policy with no number in it is not a policy, and a reviewer reads it as a business that intends to argue.

Six things have to be in there, and all six are facts rather than positions.

A window, in days, measured from a named event. "Within 7 days of your first payment" works. "Within 7 days of delivery" works. "Within a reasonable period" does not. Say what starts the clock.

The conditions. What state must the goods be in; who pays return shipping; what counts as a service already delivered. For digital goods, say what makes a purchase non-refundable and when that kicks in.

What you will not refund, stated plainly. A policy that implies everything is refundable and then refuses in practice generates the chargebacks that end merchant accounts. It is better to write the limit down. Ours says that after the first seven days we do not refund the unused part of a month or a year, and that cancelling keeps your access until the period you paid for ends.

How to ask. An email address, what to include — ours asks for the Razorpay payment ID, which is in the customer's own confirmation email — and how fast you reply.

How long the money takes, and where it goes. Two different numbers: how long you take to approve, and how long the banking rails take after that. Ours says five to seven business days to the original payment method, and says openly that the timing after we issue it depends on the gateway and the bank. Note that the destination is not your choice: clause 10(f) of the 2025 Directions puts refunds back on the original method of payment unless the payer asks otherwise.

Cancelling and refunding are separate promises. On a subscription this is the commonest omission. Cancelling stops the next charge. A refund returns a charge already taken. Say both, because a customer who means one and reads the other becomes a dispute.

If you sell a subscription, our refund policy is a short worked example of all six, including the detail most pages forget: what happens to a renewal somebody meant to cancel and did not.

Shipping and delivery: yes, a software business needs this page

Look again at that list of form fields. Shipping Policy is one of them, and it is required of a business that ships nothing. This is the single most skipped page on the list, and skipping it leaves a blank field in an application that is otherwise complete.

The way through is to answer the question the field is really asking, which is not about couriers. It is: when does the customer get the thing they paid for, and what happens if they do not?

So say that nothing is shipped, in one line, and then answer it. Our shipping and delivery policy does exactly that: there is no courier, no delivery address and no shipping charge; the paid plan is switched on the moment payment succeeds; if it has not switched on within one hour of a successful payment, here is the address to write to and the payment ID to quote, and we will either activate it or refund in full. Client projects are delivered electronically in phases against a written scope. Delivery does not depend on where the customer is.

That is four short paragraphs and it closes the field properly. If you sell services rather than a product, the same page carries your turnaround: when work starts after payment, what the first deliverable is, and by when.

Pricing: a number, a currency, and what sits on top of it

"Contact us for pricing" is a reasonable way to sell custom software. It is a poor answer on a site applying for a gateway, because the reviewer is matching what you sell against the business category and merchant category code you declared, and cannot do that from a form.

Show a price. Then be exact about two things.

The currency. Write ₹ or INR. A bare number on a site that takes international cards is ambiguous.

The tax. Clause 10(c) of the 2025 Directions requires any charge other than the price itself to be distinctly displayed to the payer before the transaction, and the e-commerce rules ask for the total price in a single figure with the break-up. So pick one of three sentences and put it next to the price: tax is included in this figure, tax of x% is added at checkout, or no tax is added. If you are below the GST registration threshold, say so rather than leaving it blank — a missing tax line reads as an unanswered question, and it is the question a reviewer asks.

Our pricing page carries the whole position in nine words under the heading — "Prices are final: no GST is added" — and repeats it in the FAQ with the reason: BitsSolved Software is not registered for GST, so the price shown is the final price, and the gateway emails a receipt for every charge. Monthly and yearly are both shown, in rupees and in dollars, and the custom-project section says plainly that there is no price list and each scoped phase gets a fixed quote.

While you are there, make the plan comparison honest about what is not included yet. A feature listed as available that is not available is the kind of thing that looks like a small copy decision and reads, to someone assessing a business, like something else.

Terms and privacy: short, specific, and actually yours

These two are where generated templates do the most damage, because a template is plausible enough that nobody rereads it.

Terms needs to establish who is contracting with the customer. Your legal entity name and its registration, what the service is and is not, how billing and renewal work, what happens on cancellation, your liability position, and the governing law and jurisdiction — which should be in India, and specifically somewhere you could actually litigate. Our terms run to a dozen short sections and defer to the refund policy rather than restating it, which is the structure that stops the two drifting apart.

Privacy needs to describe what the site collects, why, who else sees it, and how long you keep it. The clause people miss is the gateway itself: it processes the payment, so card details go to it and not to you, and saying so is both true and reassuring. Then give a real route to ask for deletion or a copy, pointing at the same email as everything else.

The template trap is specific and easy to check. Open both pages and search for another company's name, a US state's governing law, a GDPR clause you have no relationship with, a "last updated" date from before your business existed, and any placeholder in square brackets. Each of those tells a reviewer the pages were pasted rather than written, and once that impression lands, the rest of the site is read in that light.

Put the links in the footer, on every page

Almost every write-up on this subject says the policies must be "accessible" or "not buried three clicks deep", and then stops. Here is the specific instruction: put all of them in the site-wide footer, as text links, on every single page, and keep them there.

Three reasons, in descending order of how much they cost you.

The check is automated and it reads URLs. Instant validation runs against the links you submit and against the site. A link that only renders inside a checkout flow, or only after a JavaScript bundle loads, is a link that may not be found.

A human reviewer crawls rather than shops. Someone assessing your business opens the homepage and looks for the policies. They do not add an item to a cart to find your refund terms. The footer is where they look because the footer is where every other site keeps them.

Customers need them when they are not buying. The person looking for your refund window at eleven at night has already paid. If the only route to the policy is a checkout they have finished with, they will email you instead, or raise a chargeback.

Four details decide whether this works:

• One canonical URL per policy, used everywhere. The same /refund-policy.html in the footer, in the dashboard form, and in the confirmation email.
• No redirect chains. A policy URL that 301s somewhere else is a URL that can quietly become a 404. The redirect checker shows the whole chain.
• Real HTML, not a PDF and not a modal. A policy inside a PDF is not indexable and is unreadable on a phone.
• HTTPS, with a certificate that is valid everywhere. Including www and non-www, and including the policy pages themselves. The SSL checker will tell you the expiry and the chain.

Ours sits in a "Policies" column in the footer of every page on the site: Privacy Policy, Terms of Service, Cookie Policy, Refund & Cancellation, Shipping & Delivery. Alongside it, in the same footer, the legal entity name, the Udyam registration number and the full registered office address, so that the identity facts are also on every page rather than on one.

The check to run before you submit

Open your own site and work down this list. Every item is something you verify rather than something you assume, and all of it takes under an hour.

1. Paste each of the six URLs into a private browsing window. Each must return the page, with no login, no cookie wall and no redirect. A policy you can only see while signed in is a policy the checker cannot see.
2. Read your business name on the site against your PAN or registration certificate, character for character. A brand name where the registered name should be is a mismatch, and mismatches are what a background and antecedent check is for.
3. Dial your own phone number from a phone that is not yours, during the hours you published.
4. Check the address is complete down to the PIN code, and that it is the address you actually operate from.
5. Find the number in your refund policy. If there is no number of days, you do not have a refund policy yet.
6. Find the currency symbol on your pricing page, and the sentence about tax.
7. Check the footer on five different pages, including a blog post and a 404, and confirm all the policy links are present and identical.
8. Run the whole site through the website health checker for the certificate, the redirects, the security headers and indexability in one pass, and fix what it flags before a reviewer finds it.
9. Load the site on a phone. A policy page that overflows horizontally on a 390px screen is a policy page half your customers cannot read.
10. Search your terms and privacy pages for a name that is not yours. This takes ten seconds and catches the single most embarrassing failure on the list.

If it comes back refused

The useful thing about an automated check is that it tells you which field failed. Read the response literally, fix the named page, and resubmit — the form is designed to be re-run, and the documentation describes it prompting you to enter valid URLs rather than closing the door.

Three causes sit outside the policy pages and are worth ruling out before you rewrite anything:

• A name mismatch between the site, the domain registration and the documents.
• A business category that does not match what the site sells. The gateway assigns a merchant category code and, under clause 13(h), keeps monitoring your transactions against the business profile you declared. A site that describes one business while the application declares another is a problem that outlasts onboarding.
• A site that is visibly unfinished. Placeholder text, stock hero images, a blog with one post dated three years ago, dead navigation links. None of these is on anybody's checklist, and all of them inform the judgement.

Worth knowing for later: a gateway account is tied to a KYC identity, so it cannot simply be reassigned if the person who opened it moves on. That is the last and most-forgotten tier in getting your website back from a previous developer — open the account in the business's name now and the problem never arises.

Start here

1. Write down the six commercial facts: refund window and conditions, delivery timing, price and tax, contact details and hours, and your exact registered name.
2. Build the pages in order — contact, refunds, delivery, terms, privacy, pricing — each at its own permanent URL.
3. Wire all of them into the site-wide footer, along with the legal name and the full address.
4. Run the ten-point check above on your own site, in a private window, on a phone.
5. Submit, and keep the pages accurate afterwards, because the business profile you declared is monitored after approval, not only before it.

None of this is difficult and none of it requires a lawyer. It requires deciding things that are easier to leave vague, which is why it is usually the last work to get done and the reason an application sits for a fortnight.

If you would rather not spend that fortnight, this is ordinary work for us: writing the six pages against your actual commercial terms, putting them at permanent URLs with the footer wiring, and handing you back a site that passes the check. For a new site that is web application development; for adding the pages to a site that already exists, website fixes and maintenance. And if you are about to commission the build itself, decide the gateway integration in the brief rather than after it — writing a software brief that gets an accurate quote covers where that belongs.

Either way, do step one today. The pages are quick once the decisions are made, and impossible before.