Returns and RMA in PrestaShop: what's built in and what gets built

Case studies · 8 min read

Returns and RMA in PrestaShop: what's built in and what gets built

“I'd like to return the boots, they're too small.” Someone on your team opens the order, replies by hand, notes the case in a spreadsheet and waits for a parcel. When it turns up, they have to remember whose it was and what was promised. Multiply that by twenty a month.

Three different things arriving in the same email

The customer always writes the same message, but behind it sit three processes the law treats separately, with deadlines and costs that have nothing in common:

  • Withdrawal or cancellation. Fourteen calendar days to change their mind without giving any reason. It isn't a favour you're doing: it's a right, and the product can be in perfect condition.
  • Commercial returns. The thirty or sixty days you offer on top of the law. This one is yours: you set the window, who pays the postage, and whether it's money back or store credit.
  • Legal guarantee. The product arrived faulty or broke too soon. It isn't simply returned: repair or replacement comes first, and only then does money enter the conversation.

How long that guarantee runs depends on where your customer is, and the differences are bigger than most shops assume. Two years is the EU floor, not the ceiling: Spain raised it to three years for anything bought since 2022, France presumes a fault was there from the start for a full twenty-four months and adds six months to the guarantee after every repair, and Germany puts the burden of proof on the seller for the first twelve months. If you ship across the EU, the safe answer is the most generous one for that customer's country, not the one written on your English returns page.

Selling into the UK adds a second layer that has nothing to do with the EU rules: fourteen days to cancel under the Consumer Contracts Regulations 2013, and separately a thirty-day short-term right to reject faulty goods for a full refund under the Consumer Rights Act 2015. Two different rights, two different clocks.

Mixing them up is expensive in both directions. Treating a cancellation as a commercial return —“the window was thirty days and it's closed”— puts you outside the law. Treating a guarantee claim as a cancellation means giving back money you never had to.

The customer always writes the same email. Behind it are three different processes, and only one of the three is yours to decide.

And the fourth case: the one who doesn't want to return anything

This one isn't in any manual and it's the one that turns up most: the customer forgot to enter their discount code. They don't want to return the goods — they haven't even got them yet — they want the whole order cancelled so they can place it again properly.

And they're entitled to, because the right to withdraw doesn't make anyone wait for the parcel: it can be exercised from the moment the contract is concluded. The fourteen days are the end of the window, not the start of it.

Operationally this is nothing like a return. If the order hasn't left the warehouse there's nothing to collect: it has to be stopped, cancelled and refunded. If it has already gone, you have a parcel in transit that will come back on its own. PrestaShop offers no route for the customer to do this themselves — it ends up as an email, or a phone call — and it's exactly what the electronic withdrawal function solves, mandatory since June 2026 and what we build with Right of Withdrawal.

What's left —the everyday return, with the goods already at the customer's house— is what the rest of this article is about.

PrestaShop already ships returns, switched off

This surprises a lot of people: you don't need to buy anything to get started. PrestaShop has included a merchandise returns system for years, but it arrives disabled, which is why hardly anyone knows it's there.

You turn it on under Customer Service → Merchandise Returns. There are two settings and that's it: enable it, and say how many days you accept — fourteen out of the box.

From then on the customer opens the order from their account, ticks which products they're returning and how many, writes why, and submits the request. It shows up in a list in your back office, with five states you move it through: waiting for confirmation, waiting for the parcel, parcel received, denied and completed. Every state change emails the customer, and you can print a PDF return slip for them to drop in the box.

For a shop with three or four returns a month, this is enough. Genuinely. Switch it on before you consider anything else.

How far the built-in system goes

The first surprise is when the button shows up. PrestaShop only offers to return an order that is paid and shipped, and it counts the days from the shipping date recorded on the order: the one filled in when you change the status, not when the customer opens the box. If your warehouse takes two days to mark orders as sent, the customer starts two days down without anyone telling them.

The second is that digital orders are left out entirely. If what you sell is downloaded, PrestaShop never shows the return option — which makes sense for a file, but leaves nothing for shops that mix physical and downloadable products in the same order.

The third is the reason. The customer types it into a free-text box, and that's where it ends: there's no list of reasons, so at the end of the quarter you can't answer the one question that matters —why am I getting these back?—. With fixed reasons you find out that 40 % of the returns on one reference are about sizing, and that the product needs a better size guide, not a different supplier.

The fourth is that a return doesn't move any money. Approving one generates no refund: that's another screen, on the order, that somebody has to remember to fill in. There's no collection either, no carrier label, no notice to the warehouse.

Put shortly: PrestaShop records the request. Everything that happens afterwards still lives in your inbox.

What people actually end up asking for

Once a shop goes past twenty or thirty returns a month, the same requests always appear, and they're almost never “I want an RMA module”:

  1. An RMA number the customer can write on the box and the warehouse recognises on arrival, without opening the order to work out what it is.
  2. Fixed reasons and a photo. The photo settles half the arguments before they start.
  3. The case not staying inside the shop. Nobody wants to log into PrestaShop to handle returns: they want the request where the team already works.
  4. A refund that doesn't get forgotten, because a forgotten refund is two angry emails and a complaint.

The third point takes the most forms, and they're worth telling apart, because they aren't the same piece:

  • A board like Monday for day-to-day tracking: each request lands as a card, with an owner and a date, and the support team works there instead of in the back office.
  • A form like Typeform as the way in for anyone who can't go through their account: guest checkouts, orders taken over the phone, purchases made in the physical shop. The website isn't your only sales channel, so it can't be your only returns channel either.
  • The ERP, when it already does RMA. Plenty of them do, and it goes unused. In Dynamics 365 Business Central —the old Navision— a return is a sales return order that produces its own number and its own credit note, and the usual practice is to number that series RMA-00001, precisely because customers understand “RMA” and don't understand “sales return order”. If your ERP already knows how to do this, the shop doesn't need to learn it: it needs to tell it.

That last idea is the one that saves us the most work. We already apply it in the Go!Manage integration: the ERP runs the business, the shop is the window. Returns are no different — whoever decides to issue a credit note is whoever keeps the books, not the catalogue.

What does repeat in every case is the starting point: the native system switched on, so the request is recorded against the order instead of in an email, and whatever needs connecting goes on from there.

Where to start this week

Turn on native returns and set the window to what you actually accept. Write the three routes out separately on your returns page, with their deadlines and with the country differences that apply to you, and stop arguing them case by case. Then spend a month noting the reason for every return by hand: at thirty lines you'll know whether you need to connect something or whether this is plenty.

If those thirty lines tell you it has to move somewhere else, tell us how you work and with which tools —the board, the ERP, the warehouse— and we'll tell you what's worth connecting and what isn't worth touching.

Tell us how you handle returns

How we can help

See all services →

Keep reading

Need a hand with your project? Let us talk

Turn your ecommerce into your best salesperson

Ready to boost your PrestaShop store? Let's discuss your project and create something amazing together.

Contact us now