Payment Gateway Rejected Your Website? 5 Pages to Add (2026)

The worst week to find this out is the week you planned to launch. The stock is in, the ads are scheduled, the family has been told, and the payment gateway sends a mail that says the application could not be approved at this time, with no detail beyond that. Nobody at the gateway is refusing to do business with you. A reviewer opened your website, looked for five or six specific things, did not find them, and closed the tab.

We have taken this call from clients enough times to know what the mail means before we open the site. In almost every case the fix is a day of work, not a new business. The expensive part is not the fix, it is the delay. A shop doing a modest two lakh a month online loses roughly ₹6,500 of revenue for every day it cannot take money, and the ad budget you already committed keeps spending whether checkout works or not. Two weeks of back and forth with a review team is a lakh of damage done by a missing page.

So here is the whole thing in one place: why gateways look at your website, the five pages they want to see, copyable starter text for each one, the smaller checks that fail quietly, and what to do in the hour after a rejection.

Why a payment gateway reviews your website at all

A payment aggregator in India is regulated. When Razorpay, PayU, Cashfree, Instamojo or anyone else onboards you, they take on the risk that your customers will dispute the charges, and they are answerable for who they let onto the network. Their underwriting team has two questions: is this a real business selling what it says it sells, and will a customer who is unhappy be able to find out what their rights are without calling the bank.

Your website is the only evidence they have for either question. They are not grading your design. They are looking for the things a customer would need if something went wrong: who you are, where you are, what you are selling, what it costs, when it arrives, and how to get a refund. Read the rejection that way and it stops feeling personal.

“The review is not about your brand. It is about whether an unhappy customer could help themselves using only your website.”

That also explains the one thing founders find most annoying. A gateway will happily approve a plain, ugly site with all the information in place, and reject a beautiful one that hides everything behind a contact form.

The five pages, and what each one has to say

Every Indian gateway asks for the same set, with small differences in naming. Build these five, link them in the footer of every page, and you clear most of the review on your own.

1. Terms and Conditions

This is the agreement between your business and the person buying. It needs your legal entity name, what you sell, pricing and taxes, how an order is accepted, what the customer may and may not do, and which courts apply if there is a dispute. Reviewers check that the entity name here matches the name on your KYC and your bank account. A site that trades as one brand while the papers say another needs one line explaining the relationship, otherwise it reads as a mismatch and gets flagged.

2. Privacy Policy

What personal data you collect, why, who you share it with, how long you keep it, and how someone can ask you to delete it. Since the DPDP Act this is not only a gateway requirement, it is the law for anyone collecting customer data in India, and it needs a named person to contact. Two lines about cookies and analytics belong here too.

3. Refund and Cancellation Policy

The page reviewers read most carefully, because it is the page that decides how many chargebacks land on the gateway. State the window in days, what condition goods have to be in, who pays return shipping, how long the money takes to come back, and how a customer starts the process. If you genuinely do not give refunds, say that plainly with the reason. A clear no-refund policy is approvable. A missing policy is not.

4. Shipping and Delivery Policy

For physical goods: where you ship, the dispatch time, the delivery window by region, the courier partners, what shipping costs, and how tracking reaches the customer. For anything digital or service based this page still has to exist, and is often called Delivery Policy or Service Delivery. Say how soon after payment access is granted or the work begins. Software and consulting businesses skip this page more than any other, and it is the most common reason a services website gets held up.

5. Contact Us

A real page, not a form in a modal. It needs the full postal address with a pin code, a phone number that is answered, and an email address on your own domain. A Gmail address on a business taking card payments is a flag by itself. Business hours help. A map embed is a nice touch and not required.

Two notes that save a round trip. Every one of these pages has to be reachable without logging in, and the links have to work from the footer on mobile. We have seen a rejection where all five pages existed and the footer was hidden on small screens by an old CSS rule, which is what the reviewer was looking at.

Starter text you can paste today

This is a starting point written to get a real business through review, not legal advice, and a lawyer should look at it before it carries real weight. Replace everything in angle brackets. Keep the headings, because reviewers skim for them.

textREFUND AND CANCELLATION POLICY

Last updated: <date>

<Legal entity name> ("we", "us") wants you to be satisfied with your
purchase. This policy explains when you can cancel an order, when you can
return an item, and how a refund is processed.

Cancellation
You may cancel an order free of charge any time before it is dispatched.
Write to <support@yourdomain.com> with your order number. Once an order has
been handed to the courier it cannot be cancelled, and the return process
below applies instead.

Returns
You may request a return within <7> days of delivery if the item is unused,
in its original packaging, with all tags and accessories. <Perishable goods,
innerwear and customised items> cannot be returned. For a damaged or wrong
item, send photographs within <48> hours of delivery and we arrange a free
pickup or a replacement.

Return shipping
For a damaged, defective or incorrect item we pay the return shipping. For a
change of mind, return shipping of <Rs _____> is deducted from the refund.

Refunds
Once the returned item reaches us and passes inspection we approve the refund
within <3> working days. The amount goes back to the original payment method
and your bank usually credits it in <5 to 7> working days. We will tell you
by email when the refund has been issued.

How to reach us
<Legal entity name>, <full address with pin code>
Email <support@yourdomain.com>, phone <+91 _____>
<Monday to Saturday, 10:00 to 18:00 IST>

The services version of the delivery page is shorter, and this wording has cleared review for software and consulting clients of ours more than once.

textSERVICE DELIVERY POLICY

We sell <services / digital access>, so nothing is shipped physically.

After your payment is confirmed:
- Subscription and digital access is activated within <15 minutes> and the
  login details are emailed to the address used at checkout.
- Project work begins on the date agreed in writing in the proposal, and the
  schedule of milestones in that proposal governs the delivery dates.
- If access has not reached you within <24 hours>, write to
  <support@yourdomain.com> and we will resolve it or refund in full.

All prices on this website are in Indian Rupees and include <GST at 18%>
unless the page says otherwise.

For the Privacy Policy the structure that passes is boring and complete: what we collect, why we collect it, who we share it with (name the payment gateway, the courier and the analytics provider), how long we keep it, your rights, and a named contact with an email address. Write it in your own words rather than pasting a generator's output with another company's name still in it, which reviewers do notice.

The quiet failures that have nothing to do with policies

When all five pages are in place and the application still stalls, it is usually one of these. Go down the list before you write to support.

• Prices not visible. If a visitor has to enquire to learn the cost, a reviewer cannot verify what the gateway would be charging for. Put real figures, or at least a real starting figure, on the page.
• Name mismatch. The business name on the website, the GST certificate, the bank account and the gateway application all have to line up. A trading name is fine as long as one line somewhere says who owns it.
• No tax statement. If you charge GST, say so next to the price. Our note on GST on website development covers how to present it without scaring buyers off.
• A checkout that never reaches a payment step. Reviewers try to buy something. A cart that errors, a form that demands an account first, or every product out of stock reads as a site that is not ready.
• Not on HTTPS, or a mixed-content warning. A browser warning on a checkout page ends the review. If yours shows one, start with our fix for a site marked not secure in Chrome.
• Restricted goods presented casually. Supplements, anything medical, crypto, lending, betting, tobacco, weapons and multi-level schemes have their own rules and some are refused outright. If you are near one of those lines, describe what you sell precisely instead of vaguely.
• Claims you cannot support. Assured returns, guaranteed cash back, doctor approved and government authorised all attract scrutiny. Drop them or evidence them.
• A website that is still half a template. Lorem ipsum in the footer, stock pictures of other people's offices and a blog with one placeholder post all tell a reviewer the same thing.

One more, which surprises people: an under-construction banner or a password-protected staging site. The reviewer sees exactly what the public sees. If the real site is behind a login, nothing else on your application matters.

What to do in the first hour after a rejection

Rejections are reversible, and gateways resubmit faster than people expect. The order matters, because each step rules out the next one.

1. Read the mail for a reason code or a category name. The Indian gateways all use short standard phrases, and the phrase tells you whether this is a website problem or a KYC and documents problem. Those go to different teams, and mixing them up costs days.
2. Open your own site on a phone, logged out, on mobile data. Find every policy page from the footer. If you cannot do it in twenty seconds, neither could the reviewer.
3. Fix the pages and the footer links first. They account for most rejections and take the least time.
4. Then work down the quiet-failures list above and clear each item.
5. Place a real test order yourself, all the way to the payment step, and screenshot it.
6. Reply on the same ticket instead of starting a new application. Name each change and give the direct URL. A reply that reads "refund policy added at /refund-policy, delivery policy at /shipping-policy, GST note added at checkout, test order screenshot attached" is typically approved in one to three working days.
7. If the second reply still fails, ask the agent to tell you the specific clause you are failing. They can see it, and they will usually give it to you if you ask for the clause rather than argue the decision.

Keep a copy of the approved policy text somewhere outside the website. When you add a second gateway later, or a marketplace asks for the same documents, the work is already done.

Build it so this never comes up again

On the sites we build, the five pages ship on day one, before anyone has asked for them. They are proper routes with real content, linked from a footer that survives every breakpoint, carrying a last-updated date, and the policy text lives in the database rather than pasted into a template, so a client can change the refund window without waiting for a developer. On our stack that is a Next.js page reading from a NestJS and Postgres backend, which sounds like overkill for a refund policy until the day you have to change it across eleven pages at once.

It is a small amount of work that removes a whole category of launch-week emergency. If you are planning a store and comparing gateways at the same time, our longer piece on accepting payments online in India has the real per-transaction costs of UPI, cards and autopay, and the Razorpay webhooks guide covers the part after approval, where orders go missing if reconciliation is sloppy.

And if your site is already live and you are not sure which of the five pages you have, send us the link. We will tell you what a reviewer would find, no charge and nothing attached to it.