Returns and Refunds: Making the Process Painless for Everyone

Reviewed June 2026. Back-office paths and config keys apply to PrestaShop 1.6, 1.7, 8 and 9 (version differences are noted inline). This guide is about running returns operationally, not about what the law requires — withdrawal rights, refund deadlines and who pays return shipping are covered in the linked legal guides, and none of this is legal advice. Enabling the returns module does not by itself make your process compliant; your published policy and local rules do.

Nobody opens a store hoping to process returns. But a return is not a failure — it's a second conversation with a customer who already trusted you once, and the way that conversation goes decides whether they ever come back. The merchant who makes returns quick and predictable keeps the customer; the one who buries the policy and drags the refund out for three weeks loses them and earns a one-star review that warns everyone else. This guide is about the operational side: how to run a return inside PrestaShop so it's painless for the customer to start, fast for you to process, and cheap enough that it doesn't quietly eat your margin.

This is deliberately not a legal explainer. What you're legally obliged to offer — the 14-day withdrawal right, who pays return shipping, refund deadlines — is its own subject, and we cover it properly in Returns Policy: what the law requires and what smart stores offer extra and Distance Selling Regulations: right of withdrawal. If you sell across borders, the rules shift again — see Cross-Border Returns. Here we assume you already know what you must offer and want to know how to deliver it well in PrestaShop.

What PrestaShop gives you out of the box — and where it stops

PrestaShop has a built-in merchandise returns system, and most merchants never turn it on. The switch lives under Customer Service → Merchandise Returns (in PrestaShop 1.7, 8 and 9; on 1.6 it sat under Customers → Merchandise Returns). The single setting that activates the whole thing is "Enable returns", backed by the PS_ORDER_RETURN configuration value, plus a "Time limit of validity" field (PS_ORDER_RETURN_NB_DAYS) that controls how many days after delivery a customer may file a return request.

Once enabled, a logged-in customer sees a "Merchandise Returns" link in their account, and on each delivered order an option to request a return. Under the hood this creates an OrderReturn object handled by the order-return and order-follow front controllers; in the back office every request lands in the AdminReturn controller (the same Merchandise Returns page). You move the request through a set of statuses defined in the OrderReturnState table — by default: Waiting for confirmation, Waiting for package, Package received, Return denied, and Return completed.

So what does the native system actually do, and what does it leave to you? Here's the honest split:

The thing to understand: PrestaShop's credit slip is an accounting document, not a payment action. When you generate a credit slip from the order's Merchandise Returns / Refund section, PrestaShop records that money is owed back and can issue a discount voucher — but it does not push a refund to Stripe, PayPal or your card processor unless that specific payment module supports refund-from-back-office. For most gateways you still log into the gateway (or use its refund button if the module adds one to the order page) to send the real money. Knowing this prevents the classic mistake of "I marked it refunded a week ago, why is the customer emailing me?"

Turning it on the right way

Enabling returns is one toggle; configuring them so they don't generate support tickets takes a few more deliberate steps:

• Set a return window that matches your policy, not the default. PS_ORDER_RETURN_NB_DAYS counts days from delivery. If your published policy says 30 days but the field says 14, customers hit a wall the form won't let them past — and email you instead. Make the number in the back office equal to the number on your policy page.
• Make sure the order actually reaches a returnable state. The native form only offers a return once the order has reached the delivered/returnable state PrestaShop uses, with returns enabled under Customer Service → Merchandise Returns and the time limit set correctly. If your orders never move into the delivered status that qualifies for a return, the option stays hidden — confirm your workflow actually marks orders delivered.
• Localize the return slip. The default PDF return slip is plain. If you sell in several languages, confirm each one renders correctly before a customer prints a slip in broken text.
• Write the statuses you'll actually use. You can add or rename OrderReturnState entries (e.g. a "Label sent" status) so both you and the customer can see exactly where the return stands without an email exchange.

If you want to confirm the two settings are what you think they are — a frequent cause of "the return option isn't showing" tickets — they live as plain rows in ps_configuration:

-- Check whether returns are enabled and the active return window
SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_ORDER_RETURN', 'PS_ORDER_RETURN_NB_DAYS');
-- PS_ORDER_RETURN = 1 means enabled; PS_ORDER_RETURN_NB_DAYS is the day count from delivery

Set them from the back office rather than by hand — the admin page writes the right shop context and clears the relevant cache — but reading the rows is a quick way to see why the customer-facing form is or isn't appearing. If PS_ORDER_RETURN is 1 and customers still don't see the option, the cause is almost always the order not having reached the delivered/returnable state, not the setting.

Making the return easy to start

The single biggest lever on return friction is whether the customer can begin one without talking to you. A return that requires emailing support, waiting for a reply, then waiting for instructions, is the kind that turns into a chargeback the moment the customer loses patience. PrestaShop's self-service flow already solves the hard part — but only if customers can find it.

• Put the policy where it's looked for. Link your returns policy in the footer (a CMS page), on the product page near delivery info, and inside the order-confirmation and shipping emails. A hidden policy generates more tickets than the returns themselves: when customers can't find it, they assume the worst and contact you — or skip straight to a chargeback.
• Tell customers the link exists. Many merchants enable native returns and never mention that the option is sitting in the account area. One line in the shipping email — "Need to return something? Start it from your account, no need to email us" — converts a support ticket into a self-service action.
• Don't force a login wall to read the rules. The request itself needs an account (the OrderReturn is tied to a customer), but the policy that explains the process should be public so a guest weighing the purchase can see how low-risk it is.

The part PrestaShop doesn't handle: return shipping

Return shipping is where most of the cost and most of the friction live, and it's exactly the part native PrestaShop leaves blank. You have three models, and the right one depends on your margin and your category:

Because the native system stops at "request and credit slip," the label generation typically comes from your carrier module or shipping platform, not core PrestaShop. If you run a fulfilment integration, check whether it can issue return labels off the OrderReturn — that's the difference between a one-click approval and a manual portal visit per return.

Processing fast: the workflow that prevents complaints

Customers check their bank accounts. Every day between "I shipped it back" and "the money's here" is a day of low-grade anxiety, and that anxiety is what turns a satisfied returner into a complainer. The fix is a tight, repeatable loop:

• Inspect on arrival, not "when you get to it." A quick visual check — resalable or not — is enough to decide the path.
• Move the status the moment you receive the package (Package received), so the customer's account reflects reality and they stop wondering.
• Issue the credit slip immediately from the order's refund section — and then actually trigger the gateway refund, because (as above) the credit slip alone doesn't move money for most gateways.
• Restock in the same action using the "re-stock products" checkbox if the item is resalable — this keeps your available quantity honest without a separate stock edit. Leave it unticked for damaged returns.

If you process more than a handful of returns a week, the manual click-through gets expensive in time. This is where a dedicated returns/RMA module earns its keep: configurable return reasons, automatic label generation, status emails to the customer at each step, and rules (auto-approve under €X, auto-deny after the window) that stop you re-deciding the same thing daily. Whether that's worth it is a volume question — at five returns a week the native flow is fine; at fifty, the time saved pays for the tool quickly. Browse our PrestaShop modules if your return volume has outgrown clicking through each one by hand.

Refunds: voucher, credit slip, or money back?

PrestaShop gives you two refund instruments and they are not interchangeable in the customer's eyes:

• Credit slip — the accounting record that a refund is due. Generate it from the order; it produces a PDF the customer can see in their account.
• Discount voucher — store credit, optionally generated alongside the credit slip. Cheaper for you (no money leaves) and it keeps the customer in your store, but for a withdrawal under EU law a voucher is not a valid substitute for a cash refund unless the customer agrees to it. Offer it as a sweetener (e.g. "refund to card, or 110% as store credit"), never as the only option.

The mechanics of these documents — and the related invoicing/credit-note rules — overlap with how you customize PrestaShop's PDFs. If you need credit slips and invoices to carry your branding and the legally required fields, that's covered in Invoice Customization in PrestaShop. For the credit-note content itself — proper tax breakdowns, the reference back to the original invoice, accounting-grade formatting on the document PrestaShop produces when you refund — that's the job of Financial Revolution, which works on the credit slips rather than the return workflow.

Returns data is free business intelligence

The native return form lets a customer type why they're returning in a free-text message, and that explanation is the most underused diagnostic in PrestaShop. Core PrestaShop does not ship a configurable list of return reasons — the standard flow captures the customer's own wording, so you read it rather than pick from a menu. If you want structured, pickable reasons (wrong size or fit, not as described, changed my mind, arrived damaged, quality below expectation, arrived too late) for clean reporting, that comes from an RMA/returns module or a customization. Either way, review what customers tell you monthly.

The patterns are actionable and specific. If a third of returns for one product cite "wrong size," the size guide is the problem, not the product. If "not as described" recurs, your photos or copy are overselling. If "arrived damaged" clusters on one SKU, the packaging is failing in transit — and that return costs you twice, refund plus dead inventory. Returns are a symptom; reading the cause is worth far more than processing the return efficiently. Shaving even a couple of points off your return rate flows straight to profit, because every avoided return saves the outbound shipping, the return shipping, the handling time, and often the markdown on a re-opened item.

The cheapest return is the one that never happens

Everything above makes returns less painful once they start. Reducing how many start is the bigger prize, and most of it is upstream of the returns system entirely:

• Make product pages do their job. Dimensions, materials, weight, multiple-angle and in-context photos — anything that closes the gap between what the customer imagined and what arrives. Fashion and footwear especially: a real "how to measure" guide beats a bare chart of numbers.
• Let reviews set expectations. "Runs small" / "true to size" from past buyers prevents the next sizing return better than any policy.
• Confirm the order in detail. An order confirmation that spells out attributes (size, colour, quantity) lets a customer catch their own mistake before it ships — a corrected order is far cheaper than a return.
• Invest in packaging. Transit damage is the most wasteful return category; proper protection is cheaper than the double loss.

The retention truth most merchants miss

Here's the counter-intuitive part: a customer who has a good return experience is often more likely to buy again than one who never returned anything. A smooth return proves the store is low-risk, and that proof removes the biggest psychological barrier to the next purchase — and to bigger baskets, because the buyer knows a wrong choice is recoverable.

Frequently asked questions

Why can't my customer see the return option on their order?

Three things have to be true at once: returns are enabled (PS_ORDER_RETURN = 1 under Customer Service → Merchandise Returns), the order has reached the delivered/returnable state PrestaShop requires, and you're still inside the Time limit of validity window counted from delivery. If the setting is on but the option is hidden, the order almost certainly hasn't been marked delivered — confirm your status workflow actually moves orders into that state.

Does generating a credit slip refund the customer's card?

No — and this is the most common misunderstanding. A credit slip is an accounting record that money is owed back; it does not push a refund to Stripe, PayPal or your card processor unless that specific payment module adds a refund-from-back-office action. For most gateways you still trigger the actual money-back in the gateway itself. Mark the credit slip and send the real refund, or the customer keeps waiting.

Can I add structured return reasons (wrong size, damaged, changed mind)?

Not in core. PrestaShop's native form captures the customer's own free-text explanation rather than a fixed list, so you read what they wrote rather than pick from a menu. A pickable, reportable reason list comes from an RMA/returns module or a customization. Even with the free-text version, review what customers tell you monthly — clustered reasons point straight at a product page or packaging problem.

Should I tick "re-stock products" when issuing the credit slip?

Only if the returned item is resalable. The checkbox raises your available quantity in the same action that issues the credit slip, which keeps stock honest without a separate edit. Leave it unticked for damaged or opened goods you can't sell again, or you'll oversell phantom inventory.

Where does PrestaShop store a return, and what statuses does it use?

Each request is an OrderReturn object, listed in the back office under the AdminReturn controller (the Merchandise Returns page). It moves through statuses held in the OrderReturnState table — by default Waiting for confirmation, Waiting for package, Package received, Return denied and Return completed. You can rename or add states (e.g. "Label sent") so the customer's account always reflects where the return really stands.

That's the frame to hold. The native PrestaShop returns system gets you a self-service request and the accounting documents; your job is to wire up the missing pieces — return shipping, fast gateway refunds, clear statuses, and a findable policy — so the whole loop feels effortless. Do that and the cost of a return becomes an investment in a customer who buys more confidently next time. While you're tightening this up, it's worth a look at the surrounding compliance: the terms and conditions your store must include and the broader EU e-commerce rules set the boundaries your return process has to live inside.