Refund policy pages and payment gateway approval in India

A merchant application is rarely rejected because the business is unsound. It stalls because the website is missing a refund page, shows a mobile number that does not match the application, or advertises products the account was never approved for. Understanding how payment gateway approval in India works, and what a reviewer opens first, saves days of back-and-forth before your first rupee is collected.

This article covers the website side of onboarding: which pages are expected, what a human reviewer typically checks on each, and the mismatches that cause a file to come back marked incomplete. Treat it as practical preparation, not legal advice on the regulations behind it.

Why the gateway cares about your website at all

Payment aggregators sit between your customer's bank and your account, and they carry the risk when something goes wrong. If a buyer disputes a charge, the aggregator has to establish what was sold, on what terms, and whether the merchant offered a route to resolve the complaint.

Your policy pages are that evidence. They also help the aggregator meet its own due diligence obligations as a regulated intermediary: confirming the business exists, sells what it claims, and can be contacted by a customer.

Chargebacks make this concrete. When a customer claims they never received an order, the merchant's published delivery and refund terms are what the aggregator uses to assess the case. A site with no such pages leaves the aggregator exposed, which is why the check happens before approval rather than after.

The pages reviewers expect to find

Requirements vary between providers, but most onboarding checklists look for the same set, reachable from the site footer without logging in:

• Refund and cancellation policy: eligibility, timelines and how money is returned
• Terms and conditions: what you sell and on what commercial terms
• Privacy policy: what customer data you collect and how it is handled
• Shipping or delivery policy: for physical goods, covering areas, charges and timelines; service businesses usually describe service delivery instead
• Contact us: a working phone number, an email address on your domain and a physical address
• Pricing or product pages: actual prices in rupees, not "call for price" alone
• About us: a real description of the business and who runs it

A live site over HTTPS is effectively assumed. An expired certificate, a browser warning or a page stuck behind a coming-soon screen tends to end the review immediately.

What a reviewer actually checks on each page

Consistency with your application

The single most common cause of rejection is a mismatch. The business name on the website should match the name on your PAN, bank account and registration documents, or you should be able to explain the trading name. The address, phone number and email should match what you filed. If the website says one city and the application says another, expect a query.

Specific, not generic, policies

Placeholder text gives the game away: a policy that still names another company, mentions currencies you do not accept, or states a return window that contradicts the product page. Reviewers read enough of these to spot a template that was never edited.

Clarity on what is sold

The product or service description must make the business model obvious. Vague pages that could describe anything are treated as a risk, particularly for high-value or subscription billing. If you sell services, explain what the customer receives and when.

Category restrictions

Every aggregator publishes a list of restricted or prohibited business categories, and the review includes checking your site against it. Products that look unrelated to your stated business, unexpected foreign-currency pricing, or claims about guaranteed financial returns commonly cause a file to be paused for clarification.

A reachable complaint route

Reviewers look for a grievance or support contact with a stated response time. Some also confirm the phone number is answered.

A pre-application checklist

Work through this before you submit, and the review usually takes days rather than weeks:

1. Site is live on your own domain, loads over HTTPS with a valid certificate, and has no coming-soon or password screens.
2. Footer links to refund and cancellation, terms, privacy, shipping if applicable, and contact.
3. Every policy names your business correctly and is dated.
4. Prices appear in Indian rupees, with GST treatment stated.
5. Contact page shows a working number, a domain email and a full postal address with PIN code.
6. Business name, address and contact details match your KYC and bank records.
7. Product and service pages describe what a buyer receives, with images that are yours to use.
8. Refund timelines on the policy page match what your terms and product pages say.
9. Nothing on the site falls into the provider's restricted categories.
10. Checkout, if already built, shows the policy links before payment.

Print the list and tick items on a phone as well as a laptop, since reviewers often open the site on mobile.

Common reasons applications come back

Alongside mismatched details, the recurring causes are simple. Policy links that lead to a 404 page. A refund policy that exists but never mentions timelines or method. A shipping page for a business selling digital services, or no delivery information at all for one selling goods. Contact details limited to a form with no phone or address. Screenshots of prices instead of real product pages. Marketing copy promising outcomes the business cannot guarantee.

If your application is queried, fix the website first, confirm the change is live, clear any caching, and only then respond. Replying while the old page is still served restarts the cycle.

Prepare the site, then apply

Treat gateway onboarding as a small project rather than a form to fill. Spend an afternoon getting the five policy pages accurate and consistent, confirm every detail matches your KYC records, and submit once. That order of work avoids the stop-start pattern where a launch date slips because payments were left until last.

If you are setting up a store and want the policy pages, checkout links and HTTPS handled together, our team builds this into projects such as an online shopping portal; you can also check pricing before you plan the timeline. For the legal wording of the policies themselves, take a qualified lawyer's review.

Frequently asked questions

Do I need a shipping policy if I only sell services?

Not in the courier sense, but reviewers still want to know how and when the customer receives what they paid for. A short service delivery section inside your terms usually satisfies that.

Can I apply for a gateway before my website is finished?

You can start the paperwork, but approval generally requires a live site with working policy pages. Applying too early usually means resubmitting later.

Is a GST registration compulsory for a payment gateway account?

It depends on your business and the provider's requirements; some merchants are onboarded without it while others are asked for it. Confirm with your provider and your accountant rather than assuming.

Why was my account approved but later put under review?

Ongoing monitoring continues after onboarding. Adding products outside your approved category, a spike in chargebacks or customer complaints about refunds can all trigger a fresh review. Keeping policies accurate and honouring refund timelines is the best prevention.