Building a Returns Page and Return-Request Flow for Your Online Store

Building a Returns Page and Return-Request Flow for Your Online Store

A returns policy that lives only as a paragraph in the footer is a promise your website cannot keep. The version that works is a returns page that states the rules in plain language, a return-request form that collects exactly what your team needs, status updates that tell the customer what is happening, and records that your accountant, your warehouse and your payment gateway can all reconcile. This guide explains how to build that on a Shopify, WooCommerce or custom store: what to put on the page, what the form must capture, how statuses should work, how refunds should connect to payments, and what to test before launch.

It replaces an earlier version of this article that mixed the policy with tax and reverse-logistics operations. Those are real subjects, but they belong to your accountant and your logistics partner. What a website developer controls, and what this article covers, is the customer-facing page, the request flow and the data behind it. For the legal and tax side, take advice from your chartered accountant; our separate guide on what an ecommerce returns policy in India should include covers the policy wording.

Why the website side of returns deserves its own build

Returns touch more systems than almost any other process in a store: the order record, the payment, the courier, the warehouse, the invoice and the customer's inbox. When these are connected by hand, with emails, spreadsheets and calls, the same mistakes recur: a refund issued twice, a return approved after the window closed, a parcel received but not recorded, a customer asking for the third time where their money is.

A flow built into the website does not remove returns, but it makes each one a record with a status instead of a conversation to reconstruct. It also protects you: a clear request with a reason, photos where needed and a timestamp is far easier to assess than a chain of messages.

Start with the rules, written for customers

Your returns page is read by two kinds of people: shoppers deciding whether to buy, and customers who already have a problem. Both need the answer quickly.

What the page should state

• The return window, and exactly when it starts: from dispatch, from delivery or from the first delivery attempt. Pick one and say it.
• What can be returned, replaced, exchanged or refunded, and the difference between these.
• What cannot be returned, listed specifically: perishable items, personalised products, items with broken seals for hygiene reasons, and any others that apply to your range.
• Condition requirements: unused, with tags, in original packaging, with accessories.
• How to start a return: a visible button leading to the request form, not an instruction to email someone.
• What happens next: how the return is collected or sent, how it is checked, and when and how the refund is issued.
• Who pays for return shipping, in each case: a wrong or damaged item, change of mind, a size exchange.
• Contact details for problems, including your grievance contact where the rules require one. Our article on the 2026 consumer protection rules for ecommerce explains what the website must display; check the current text with your adviser.

Avoid vague clauses such as "returns accepted at our discretion". If discretion applies, describe the situations. Vague terms cost more in disputes than a generous clear policy ever costs in returns.

Where to place it

Link the returns page from the footer, from every product page near the price or delivery information, from the cart and checkout, from the order confirmation email and from the order-tracking page. A customer who cannot find the policy before buying will find it after, usually in a bad mood.

On product pages, a short summary ("7-day returns on unused items") with a link to the full page works better than a full policy repeated on every page. Our checklist for product pages on Indian online stores shows where this belongs.

Designing the return-request form

The form is where policy becomes data. Every field should serve a purpose.

Identify the order without friction

Let the customer find their order in the way that is easiest for them:

• Logged-in customers see their recent orders and choose one.
• Guest customers enter the order number and the phone number or email used at checkout, and receive a one-time code if you want to confirm identity. Do not force account creation to start a return.

Check the order against the return window automatically and say clearly if it is outside it, with a way to ask for an exception.

Select items and quantities

An order with several items needs line-level returns. The form should list each item with a quantity selector, so that a customer returning one of three items does not have to return all three.

Capture the reason

Offer a short list of reasons, mapped to how you will handle them:

• Wrong item received
• Item damaged or defective
• Size or fit
• Not as described
• Changed my mind
• Delivered late
• Other (with a text box)

The reason drives who pays for shipping, whether photos are needed and whether the product goes back to stock. It is also valuable data. Patterns by product or by courier tell you what to fix in your listings and your packaging.

Photos and evidence, where justified

For damaged, defective or wrong items, asking for photos is reasonable. Make it easy: accept uploads from a phone camera, compress large images automatically, and explain what you need to see. If you require an unboxing video for certain categories, say so on the product page before purchase, not only in the return form. Do not demand evidence for every reason: asking for photos of an item the customer simply does not want adds friction without benefit.

What the customer wants

Ask whether they want a refund, a replacement or an exchange, and for an exchange, which variant. Show only the options that apply to the reason and the product. For exchanges, check stock before promising anything.

Refund destination

For prepaid orders, the refund normally goes back to the original payment method, and the form can say so. For cash-on-delivery orders there is no payment to reverse, so you need somewhere to send the refund. Collect bank details or UPI information only at the point they are needed, over a secure connection, and tell the customer how the information is stored and used. Do not store more than you need. Our article on how personal data should be handled on a website explains the obligations to check.

Pickup address and contact

Prefill the delivery address from the order and let the customer confirm or change it, using the same pin code validation as your checkout. Confirm the mobile number, since the courier will call it.

A confirmation the customer can keep

On submission, show a confirmation page and send the same details by email and, if you use it with proper consent, by WhatsApp or SMS: a return reference number, the items, the status and what happens next. Make the reference easy to quote. Our article on WhatsApp order updates covers sending these messages.

Return statuses: the backbone of the flow

A return is a journey with stages. Define them once, use them everywhere, and show the customer where they are.

A workable set of statuses

1. Requested. The customer has submitted the form.
2. Approved, or Rejected with a reason. Approval can be automatic for clear cases, such as an order within the window and a reason that needs no evidence, or manual for the rest.
3. Pickup scheduled or Awaiting shipment from customer.
4. In transit to warehouse.
5. Received. The parcel has arrived and been logged.
6. Inspected. The item has been checked against the reason, with a result recorded: accepted, partially accepted, rejected.
7. Refund initiated or Replacement dispatched.
8. Refund completed, or Closed.

Rules for moving between statuses

Write down who or what can move a return from one status to the next, and what must be recorded each time: a timestamp, a user, a note. The easy mistake is allowing any status to be set at any time, which leads to refunds being initiated before the item has been received, or returns being closed with no outcome. Where possible, let the system enforce the order.

Show the status to the customer

A tracking page, linked from the confirmation message, saves a large share of support calls. Each status should have a plain-language description and an honest expected timeframe. Do not state a refund timing you cannot meet. If banks and gateways take several working days to credit a refund, say that, and say the timeline starts when the refund is initiated.

Connecting returns to refunds and payments

Refunds are where the website, the gateway and the accounts meet. Get this wrong and the books never match.

Use the gateway's refund function, from your system

For prepaid orders, issue the refund through your payment gateway's API or dashboard against the original payment, so the gateway and your records agree on what was refunded. Record the refund reference returned by the gateway against the return.

Partial and multiple refunds

A customer returning one item of an order, or receiving a partial refund after inspection, needs a partial refund. The system should track the refunded amount against the order, prevent refunding more than was paid and handle shipping charges and discounts consistently. Define how an order-level discount is split across items when only some are returned. Your accountant should confirm the treatment, and the system should apply it the same way each time.

Prevent duplicate refunds

Use an idempotency key, or an equivalent check, so that a retry after a timeout cannot refund the same return twice. Refund buttons that can be pressed twice cause real losses. Our article on Razorpay and Cashfree from the website side explains the server-side patterns that apply.

Cash-on-delivery returns

Because no payment exists to reverse, COD refunds are manual transfers or store credit. Record the method and reference, verify the account details before sending money and consider a rule on who is eligible. For the larger question of COD orders that never get accepted at all, see our guide on COD and RTO at checkout.

Store credit

Store credit and exchange vouchers can reduce refunds but need careful handling: clear terms, an expiry that complies with your terms and the law, and a balance the customer can see. Check what applies with your adviser before offering it.

Reconciliation data

Your finance team will need to match refunds in the store with refunds in the gateway and in the books. Export each return with its reference, order number, amount, method, date and gateway reference. Our article on payment settlement and reconciliation explains what finance needs from the data.

Warehouse and courier connections

You do not need to build a warehouse system to benefit from returns data, but the flow should make life easier for whoever receives parcels.

• Return labels or pickup requests generated through your courier integration where available, with the return reference printed on the parcel.
• A receiving screen where staff scan or search the reference and record what arrived. Even a simple internal page is better than a message thread.
• An inspection form with a few outcomes (restock, discard, return to supplier, refurbish) that updates inventory.
• Inventory rules. Restock only after inspection, and only to the right variant and location.

If you use a third-party fulfilment partner, the integration should carry return statuses back to your store. Our article on what to check when choosing a 3PL for your store covers how orders, stock and returns should flow, and our guide to connecting shipping to your ecommerce website covers the courier side.

Fraud and abuse controls, without punishing honest customers

Most returns are honest. A small share may not be: wrong item returned, used goods, repeated claims. Controls should target the pattern, not treat everyone as a suspect.

• Flag, do not auto-reject. Repeated returns from the same customer, address or phone number can prompt a manual review instead of automatic refusal.
• Match what comes back to what was sent. Serial numbers, batch codes or tamper seals help where products allow it.
• Keep evidence from the original packing and from the return inspection when the value justifies it.
• Be consistent. Apply rules uniformly so a decision can be explained.
• Respect privacy. Collect only the evidence you need and keep it only as long as you need it.

Email, WhatsApp and support touchpoints

Each status change is a chance to inform the customer before they have to ask. At minimum, send messages when a request is received, approved or rejected, when pickup is scheduled, when the parcel is received, and when the refund is initiated and completed. Keep the wording short, consistent and free of jargon, and include the return reference and a link to the status page. For WhatsApp messages, follow template and consent rules; see our guide to WhatsApp utility and marketing templates.

Make sure support staff can see the same return record the customer sees, with its full history, so that a call does not begin with "can you tell me your order number again?".

Measuring returns usefully

Once returns are records, you can learn from them. Review, with your own data:

• Return rate by product, variant and category, to spot sizing, quality or description problems.
• Reasons by product and by courier, to see damage patterns.
• Time in each status, to find where returns stall.
• Refund time from request to completion, to see what customers actually experience.
• Support contacts about returns, to see whether the status page is working.

Do not benchmark yourself against general "average return rate" figures from the internet. They vary enormously by category and are rarely sourced well. Compare against your own past months.

A test plan before launch

Run these on a staging store or with the gateway's test mode.

1. Submit a return as a logged-in customer and as a guest, on a phone and on a desktop.
2. Try an order outside the window, and one with items that are non-returnable.
3. Return one item from a multi-item order, and then the remainder.
4. Test each reason, including the ones that require photos, with a large image from a phone.
5. Walk a return through every status, and confirm each triggers the right message.
6. Issue a full and a partial refund, confirm the gateway reference is stored and try to refund twice.
7. Test a COD return, with and without bank details.
8. Check that exports reconcile with the gateway report for the test period.
9. Test with a slow connection and with the form abandoned halfway.
10. Read every message and screen aloud, as a customer would.

Common mistakes

• A policy with no route to act on it. The page explains returns and then says "email us".
• Asking for too much. Long forms and mandatory evidence for every return.
• No line-level selection, forcing whole-order returns.
• Free-text statuses, so nobody can report on them.
• Refunds issued outside the system, leaving records that do not match.
• Duplicate refunds from retry buttons.
• Promising refund timings the bank and gateway cannot meet.
• Hiding the policy until after purchase.
• No feedback loop, so return reasons are collected and never read.

Working with Govindani Infotech

Govindani Infotech Pvt. Ltd. is a website design and development company in Pune. Our ecommerce development service includes building custom return flows on Shopify, WooCommerce and bespoke stores, and our payment gateway integration service covers refund handling against the gateway. For stores that need orders, returns and couriers connected, our logistics integration service is the place to start.

If you would like us to review your current returns page and process, you can message us on WhatsApp or use the contact page. We will confirm scope and pricing against your requirements.

Frequently Asked Questions

What should an ecommerce returns page include?

The return window and when it starts, what can and cannot be returned, condition requirements, how to start a return, what happens after, who pays for return shipping in each case, how refunds are issued and how to reach you. It should link to a return-request form so that customers can act on it directly.

Do I need a return-request form, or is email enough?

Email works at very low volume, but a form gives you structured data: the order, items, reason, evidence, preferred outcome and pickup details. That makes decisions faster, reduces back-and-forth and gives you a record. Most growing stores move to a form, with statuses the customer can follow.

How should refunds be handled for prepaid and cash-on-delivery orders?

Prepaid refunds should normally go back to the original payment method through your payment gateway, with the gateway's reference recorded. Cash-on-delivery orders have no payment to reverse, so the refund is a separate transfer or store credit, for which you need to collect details securely. Ask your accountant how to record each.

How long should a refund take?

It depends on your own process and on the bank or payment method. State when the refund will be initiated and note that credit to the customer's account can take additional working days. Do not promise a total timeframe you cannot control, and confirm what your gateway tells you.

Can a returns flow be added to an existing Shopify or WooCommerce store?

Usually, through an app or plugin, a custom extension or an integration with your order system, depending on the platform and the complexity you need. Check how the option you choose stores return data, connects to refunds and exports for reconciliation before you commit.