PrestaShop Returns and Right of Withdrawal: Why Native Management Is No Longer Compliant with EU Directive 2023/2673

From June 19, 2026, the way an online store must manage the consumer's right of withdrawal changes. Directive (EU) 2023/2673, transposed in Italy with Legislative Decree 209/2025, introduces into the Consumer Code the new article 54-bis and the obligation of a digital withdrawal function, the so-called "withdrawal button". For those managing an e-commerce with PrestaShop, a concrete and urgent question arises: is the platform's native returns management sufficient to comply with the new rules? The answer, in most cases, is no.

In this article, we explain, practically and straightforwardly, why PrestaShop's native "Returns" tool was designed for a different purpose than that required by the new legislation, what the five points are where it is not aligned with art. 54-bis, and what is really needed to bring a store into compliance. The goal is not to scare you but to help you understand where to look before the deadline.

What Directive EU 2023/2673 and art. 54-bis provide

Directive (EU) 2023/2673 of November 22, 2023, was formally created regarding distance contracts for financial services. It amends Directive 2011/83/EU on consumer rights and repeals the previous Directive 2002/65/EC. So far, it might seem like an issue concerning only banks, insurance companies, and financial institutions.

The delicate point is how the Italian legislator transposed it. Legislative Decree no. 209 of December 31, 2025, published in the Official Gazette on January 8, 2026, inserted a new article 54-bis into the Consumer Code, titled "Exercise of the right of withdrawal from distance contracts concluded through an online interface." The wording of the provision does not only refer to financial services: it more generally refers to contracts concluded through an online interface. For this reason, many commentators emphasize that, in fact, the reform's impact extends broadly to e-commerce.

The most visible novelty is precisely the digital withdrawal function, nicknamed the "withdrawal button" or, in English, withdrawal button. The declared objective is to make canceling an online purchase as simple as subscribing to it, countering manipulative practices (the so-called dark patterns) that often make withdrawal difficult, hidden, or discouraging.

Concretely, the new withdrawal function must meet some precise requirements:

• Visibility and accessibility: it must be easily identifiable and available throughout the period in which withdrawal can be exercised.
• Direct online exercise: the consumer must be able to withdraw without downloading PDF forms, sending certified emails (PEC), or searching for email addresses.
• Confirmation step: after the request, the system must ask for explicit confirmation.
• Receipt on durable medium: the professional must promptly send a receipt of the withdrawal, with date and time.
• No dark patterns: the process must not be artificially complicated.

All these elements apply to contracts concluded from June 19, 2026, onwards. It is a date worth marking because it does not concern contracts already concluded before, but from that day on it becomes the new operational standard.

How PrestaShop's native returns management works today

PrestaShop, for several versions, offers a native tool to manage returns: the RMA (Return Merchandise Authorization) system, found in the back office under Customer Service → Merchandise Returns (in some versions "Returns"). It is a solid and tested function, but it is important to understand what it was designed for.

On the administrator side, activation is simple. In the options section, you set:

• Enable returns: activates the function.
• Validity time limit: the number of days after delivery within which the customer can request the return. This is where many set the 14 days of the right of withdrawal.
• Returns prefix: the prefix of the RMA number, for example "RE".

On the customer side, the path to request a return involves several steps:

1. Access their account management.
2. Open the order history.
3. Enter the details of the relevant order.
4. Select the products to return, write a reason, and click "Request a refund".
5. Wait for the request to be accepted by the seller; only then, from the "Product Return" section, the customer can download the RMA slip to ship the return.

It works and is very useful for the logistics part: tracking the return of goods, managing statuses ("awaiting confirmation," "awaiting package," "package received," "return completed"), generating credit notes or vouchers. But this is exactly the point: the native tool is a returns manager, not a withdrawal manager. And the difference, which at first glance seems terminological, is actually legal and substantial.

Why a return is not a withdrawal: the legal difference

Return and withdrawal are often used as synonyms in common language, but they represent two different things. Understanding the distinction is key to understanding why native management is not enough.

The return of goods (native RMA) is an operational and commercial procedure. It is how the seller organizes the physical return of a product. It can be subject to conditions, evaluations, and, indeed, acceptance by the merchant: it is the seller who, upon receiving the request, decides how to handle it.

The right of withdrawal is instead a potestative right of the consumer, provided for by articles 52 and following of the Consumer Code. It is the ability to unilaterally dissolve the contract within 14 days, without providing any reason and without any penalty. Withdrawal is perfected by the consumer's declaration alone: it does not require the seller's approval, does not require justification, and is not negotiable.

The following table summarizes the fundamental differences.

When a store manages the right of withdrawal exclusively through the native "Returns" tool, it is treating a consumer right as if it were a conditional logistical procedure. This is where compliance problems arise.

The five critical points of native management

Analyzing the native flow in light of the requirements of art. 54-bis, five specific criticalities emerge. Let's see them one by one.

1. It requires a reason

In the native flow, the "Return" form presents the customer with a field to enter the explanation for the return, and the button is labeled "Request a refund." Withdrawal, however, by definition does not require any reason: the consumer can change their mind without explaining why. Imposing or suggesting a reason introduces friction that the directive wants to eliminate and that risks discouraging the exercise of the right.

2. It requires the seller's acceptance

This is the most serious problem. In the native flow, the request goes through states like "awaiting confirmation" and "awaiting package," and the RMA documentation is generated only after the seller accepts. But withdrawal is a right perfected by the consumer's declaration, not by the professional's approval. Making withdrawal conditional on merchant acceptance conflicts with the very nature of the right: the consumer does not ask permission to withdraw, they communicate that they have done so.

3. It is buried in too many steps

To request a return, the customer must go through account, order history, order details, product selection, reason, and submission. The directive instead requires a withdrawal function "easily visible," ideally exercisable with a few clicks. A path that is too long and unintuitive risks being configured as a dark pattern, precisely the kind of friction the regulation intends to counter.

4. It depends on delivery

The native "validity time limit" counts days from the delivery date, and the return activates on orders already shipped or delivered. The right of withdrawal, however, exists from the conclusion of the contract: a customer may want to withdraw even before receiving the goods. In the native flow, those who want to withdraw before delivery have no tool to do so. This is a gap that the new withdrawal function must cover.

5. The receipt on durable medium is missing

The PDF generated by the native system is a return slip, i.e., a logistics document for the return. It is not the withdrawal receipt with date and time that the regulation requires to be sent to the consumer without delay, on a durable medium. It is a document designed to accompany the package, not to certify the exercise of a right.

The issue of durable medium and immutable document

Among the five points, the receipt deserves further discussion because it is also the most technical and where the "let's do like PrestaShop with invoices" approach does not hold.

The regulation requires that the consumer receives a withdrawal receipt, with date and time, on a durable medium. And "durable medium" is not a generic expression: it has a precise legal definition in art. 45 of the Consumer Code. It is a means that allows the consumer to store the information addressed to them and that allows its unchanged reproduction over time.

Here emerges the limit of an approach many would take for granted: regenerating the document on the fly from database data, as PrestaShop does with invoices. A page that dynamically reconstructs the receipt from the database is not a durable medium because the data remains under the seller's control and is modifiable: it does not guarantee the unchanged reproduction required by the regulation.

The practical implications are two:

• For the consumer's copy: the receipt must actually be sent in a storable form, typically an email (which is considered a durable medium) with the document attached or in the message body. The sent email meets the requirement; the regenerated page does not.
• For the seller's copy: an immutable snapshot is needed for evidentiary purposes. It is advisable to generate the receipt only once, "freeze" it in a file, and store a cryptographic hash with a timestamp. This way, there is proof of integrity without resorting to the fiscal storage system, which is not required for the withdrawal receipt because it is not a fiscal document.

There is also the issue of storage over time. The directive does not set a specific term for the withdrawal receipt, but the prudent reference is the ordinary contractual prescription of ten years (art. 2946 of the Civil Code), effectively aligned with the retention period already provided for the order invoice. However, attention must be paid to the tension with GDPR: the receipt contains personal data, and the storage limitation principle (art. 5.1.e of the Regulation) requires not to keep them longer than necessary. The correct solution is to define an explicit retention policy, with automatic deletion or anonymization once the term expires.

The risk of dark patterns and store exposure

One of the declared objectives of Directive 2023/2673 is precisely to counter dark patterns, i.e., those interface choices that make exercising a right difficult: long procedures, hidden options, unintuitive paths, unjustified requests for reasons.

The problem, for a store relying only on the native flow, is that some of these characteristics are not the result of a deliberate and incorrect choice but simply the result of using a tool born for another purpose. From the consumer's point of view, and potentially the supervisory authority's, the difference between "intentional" and "unintentional" may count little: what is evaluated is whether exercising withdrawal is truly simple and immediate.

The consequences of non-compliant management are not only formal. They translate into possible disputes, exposure to sanctions, and, no less important, reputational damage: in a competitive market, a cumbersome withdrawal process erodes customer trust and directly affects future purchasing decisions.

What is really needed to be compliant

The good news is that adapting does not mean discarding the native returns management. It means complementing it with a layer dedicated to withdrawal. The two levels must be kept distinct.

On one side, the act of withdrawal: a mechanism perfected unilaterally, without seller approval, without mandatory reason, with an explicit confirmation step and immediate sending of a dated receipt on durable medium. It must be visible, accessible throughout the useful period, and available even before delivery.

On the other side, the logistics of the return: here the native "Returns" function remains perfectly useful. Once withdrawal is perfected, the physical return of the goods, the credit note, or the voucher can be managed from the native screen the merchant already knows. Withdrawal is the act; return is what comes after, on the operational level.

In other words: native management is not the problem, it is just incomplete. It must be integrated with a component that implements withdrawal as a right, leaving the native tool to do what it does well, i.e., handling the movement of goods.

How to adapt a PrestaShop store in practice

Translated into concrete steps, here is how to proceed on a PrestaShop store, whether version 1.7, 8, or 9.

1. Keep native returns active. The Customer Service → Merchandise Returns section continues to serve for return logistics. It should not be deactivated.
2. Add a dedicated withdrawal function. A withdrawal button is needed, clearly visible in the account area and order details, perfected unilaterally, without acceptance and without mandatory reason.
3. Separate the act from logistics. The act of withdrawal must be recorded as its own immutable document, with date and time. The creation of the native return, when the goods are already delivered, can happen downstream and automatically.
4. Manage the receipt on durable medium. Generate the receipt only once, save a snapshot with a cryptographic hash, and send it by email to the consumer.
5. Define a retention policy. Establish how long to keep withdrawal acts (the prudent reference is ten years) and provide for automatic deletion or anonymization to comply with GDPR.
6. Update legal texts. The general terms and conditions of sale and the withdrawal information page must be aligned with the new digital procedure, describing how the customer can exercise withdrawal online.

For those developing or customizing modules, this is exactly the kind of gap a dedicated component can fill: a module that adds the withdrawal button and receipt generation above the existing RMA flow, compatible with different platform versions, reusing the native management as much as possible for the logistics part.

Frequently Asked Questions

Does art. 54-bis also apply to those who sell only physical goods?

The directive originates in the financial services sector, but the Italian transposition inserted a broader wording into the Consumer Code, referring to contracts concluded through an online interface. The subjective scope of application to e-commerce of only goods is therefore interpretatively open, and several commentators believe the impact extends broadly to e-commerce. The prudent approach is to comply, evaluating your specific situation with a legal advisor.

Should I deactivate PrestaShop's native returns management?

No. The "Returns" function remains useful for return logistics, status management, credit notes, and vouchers. It must be complemented, not replaced, by a withdrawal function compliant with art. 54-bis.

From when do the new rules apply?

The new provisions apply to contracts concluded from June 19, 2026, onwards. Contracts concluded before that date are not affected by the new obligation.

Does the RMA slip generated by PrestaShop count as a withdrawal receipt?

No. The return slip is a logistics document that accompanies the package. The withdrawal receipt is a different document: it must show date and time, certify the exercise of the right, and be sent to the consumer on a durable medium.

Can I continue to ask the customer for the reason for the return?

You can offer an optional field for feedback, but you cannot make the reason mandatory to exercise withdrawal. The right