cancellation button (withdrawal button)

[DRMasterChief]

Hello, ...the cancellation button will become mandatory from June 19, 2026 in EU countries.

So, this means, an electronic button is needed that allows consumers to cancel contracts online – simply, directly, and without detours. The goal: Cancellation should be as easy as signing the contract – with just one click.

How do we implement this in ThirtyBees? Has anyone already considered this, or is someone working on a solution?

It would be sufficient to use a copy the existing contact form and make it available for this purpose. This would also allow for the automatic sending of the email confirmation.

This means, we have to copy the Controller and the .tpl  from contact form to a new form?  What else is to be done?

Once again, the entire EU is affected, although the implementation in some countries seems to be less stringent.

More informations here:

The "cancellation button" (or withdrawal button) becomes a mandatory, simple, one-click feature for all EU online retailers for distance contracts starting June 19, 2026, due to EU Directive 2023/2673,

requiring an easily accessible, prominent, and clearly labeled button on websites/apps to make canceling online purchases as easy as making them, preventing complex email/form processes. 

Key Details of the 2026 Cancellation Button:
Mandatory Date: June 19, 2026.
Applies To: Online retailers (websites & apps) in the EU for distance contracts (e.g., online shopping).
Purpose: To allow consumers to withdraw from a contract with a single click, just as easily as they agreed to it.
Functionality: It must be a digital function that's simple, clearly recognizable, and available throughout the 14-day withdrawal period.
Requirements:
Easy Access: Prominently placed, not hidden behind multiple clicks or logins.
Clear Labeling: Clearly labeled (e.g., "Cancel Contract").
Confirmation: Clicking it leads to a confirmation page where the user submits the cancellation.
Legal Basis: EU Directive 2023/2673, amending the Consumer Rights Directive. 
Why it's Happening:
The EU aims to strengthen consumer rights and confidence in e-commerce by removing friction and complexity from the cancellation process, making it as easy as ordering. Non-compliance could lead to extended withdrawal periods (12 months + 14 days) or penalties. 

and also here are some informations: https://retjet.com/en/mandatory-return-button-in-online-stores-directive-2023-2673 

 

Maybe we can arrange an good solution (without an module) in team work here? 

[DRMasterChief]

Hi everyone,

Has no one really looked into this yet? It's coming into effect across the EU in June.

I can't believe no one has started working on a solution yet.

I think a paid module for this is overkill, especially since you can easily put together your own solution.

Or perhaps offering a small paid module / code solution would be a good option for ThirtyBees, considering future financing, etc.  @Acer

Here's my post in the German forum, where I'm already working on a solution:

Widerrufsbutton - Deutsches Forum - Generelle Fragen - thirty bees forum

 

[the.rampage.rado]

Hi @DRMasterChief,

Can you describe what you want to achieve?

I reviewed few online articles and the information I get is:

• we need to have a withdrawal button next to each order for the specified withdrawal period (by law or if extended by our policies)
• we should lead the customer to another page where they can confirm the request of withdrawal
• we should send them email with the details of the withdrawal request

I think the best implementation would be in BO:

• In Preferences->Orders - a value in days to specify the withdrawal period and a switch to display or hide the withdrawal button in FO-> order history

In FO:

• In My Account-> Order history right after the current buttons we place new column with the withdrawal button, after that we take the customer to a confirmation page and after confirmation we send out a withdrawal confirmation email.
  

 

After the request is recieved it gets little bit messy. Probably we will have to track those requests in separate BO controller and process them there. Or we simply receive a message with the order ID and we apply appropriate actions depending on it's current status (we contact the customer to return the products, cancel the order if not shipped, refund money, etc.). But then what happens with their personal data? Should we also obfuscate it as part of the process?

 

Sources:

• https://www.heuking.de/en/news-events/newsletter-articles/detail/new-cancellation-button-what-companies-must-implement-by-june-19-2026.html
• https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202302673

[DRMasterChief]

Hello, thank you for your input.  I have read several papers from lawyers and from the Chamber of Commerce.  My concrete ideas are:

 

• we need to have a withdrawal button next to each order for the specified withdrawal period (by law or if extended by our policies)

>> No, I don't want to make it that complicated, and there's no legal obligation to link it to the cancellation period.

It's mandatory that the customer must be able to easily access the cancellation button anytime, anywhere (just like the legal notice).

And it's important that they don't have to be logged in! It must be accessible to the customer even without logging in  (e.g. for guest customers and if you have forgotten your password, it must be hold super simple for the customers).

Of course, a customer could then press the button even after the cancellation period has expired, but the right of cancellation is quite clear about that, and once the time has passed, the cancellation is no longer effective (or, as a retailer, you can handle it however you like).

However, I definitely want to avoid a very complicated implementation in the back office and don't want to automate any checks using back office data. The cancellation button must always be visible on the front end anyway.

 

• we should lead the customer to another page where they can confirm the request of withdrawal

>> Yes, but easily accessible. I would therefore like to simply place the cancellation button in the footer, where information about shipping costs, legal notice, etc., is also found.

The refund process does not need to be initiated simultaneously, nor does it need to be started digitally.  This is generally covered by the right of withdrawal or the retailer's terms and conditions.

 

• we should send them email with the details of the withdrawal request

>> Yes, a very simple confirmation that the cancellation has been received is sufficient.

 

I believe that the retailer will then check it manually anyway. If you are a large retailer who has to process many returns a day, you will have a different, expensive solution programmed including payment management etc.

We should have this solution simple and easy for smaller retailers.

My specific idea is therefore to clone the contact form including the controller (with a new name). It already includes everything necessary:

The subject selection function (customer service, etc.) should even be deleted. The heading should be renamed "Cancellation." The submit button must also be renamed, and a new email template should be created, which will then be automatically sent (by the cloned Controller) to the customer and the retailer.

 

It is of course necessary to have a field for the customer's name and email address, as well as the order number if applicable. You might also want to include a field for the postal code to ensure consistency with the customer data and prevent misuse (however, this presents a legal hurdle).

On this cancellation form, we can include a fixed text so that the customer automatically declares their cancellation. It may be helpful to add a free text field so that the customer can indicate if they are only cancelling part of the purchase.

 

Just like with the contact form, you should probably include Turnstile (or another Captcha) to prevent the form from being misused by bots.

Edited 23 hours ago by DRMasterChief

[Yabber]

@DRMasterChief 

It won't be a "Cancel order" button, but a confusing contact form where the customer has to fill in dozens of pieces of information.
This was certainly not the intention of the creators of this law.

The customer clicks on the "Guest Tracking" link and sees a single "Cancel order" button, which changes the status of the order in the store to "Order canceled". And that's it.

[DRMasterChief]

There are certainly various possibilities, but the law provides clear rules.  Of course, this also applies to guest orders.

How do we handle it if not all items are returned?

Is this sufficient in this form, or does it comply with the law? The button must also be accessible to customers who no longer have a confirmation email, who can't log in, etc.   Thus, they also can't access the guest tracking information.

And I don't think a cloned contact form requires too much information. As already mentioned, name and order number are actually sufficient.

@Yabber What solution do you actually use (shown in the picture)?

Edited 19 hours ago by DRMasterChief

[Yabber]

12 hours ago, DRMasterChief said:

How do we handle it if not all items are returned?

Canceling an order is not the same as returning an order - they are two completely different processes.

12 hours ago, DRMasterChief said:

The button must also be accessible to customers who no longer have a confirmation email, who can't log in, etc.

A customer who has no information about their order is not a customer.
Can you log into your bank account without any login information?
You can't make this feature so that hackers from all over the world can cancel all orders in our store.

12 hours ago, DRMasterChief said:

What solution do you actually use (shown in the picture)?

This is my own module running on the displayOrderDetail hook - it is visible in standard customer and guest orders. The screenshot shows a simple configuration of the module.
Of course, for orders that have the status “Order shipped” or “Delivered,” there can be no question of canceling the order. For such orders, the customer should make a standard return after receiving the shipment.

[the.rampage.rado]

6 hours ago, Yabber said:

Canceling an order is not the same as returning an order - they are two completely different processes.

A customer who has no information about their order is not a customer.
Can you log into your bank account without any login information?
You can't make this feature so that hackers from all over the world can cancel all orders in our store.

This is my own module running on the displayOrderDetail hook - it is visible in standard customer and guest orders. The screenshot shows a simple configuration of the module.
Of course, for orders that have the status “Order shipped” or “Delivered,” there can be no question of canceling the order. For such orders, the customer should make a standard return after receiving the shipment.

I like your approach for the guest customers. But here is what I think this law makes the waters very murky - I don't think it specifies certan cases of which statuses should be excluded from this option. I think it applies to all orders (probably even non considering download/digital products) - i believe it just upgrades the standard RMA and has to stay on top of it.

So if you're using RMA, this button simply triggers the proces so you don't force your customers to manuall fill forms, send emails, etc.

The moment where the customer would like to return (cancel/withdrawal) only part of the order is easily achievable by a table with all order products on the confirmation page and preselected checkboxes next to them. If they want to cancel the whole order, they simply have to click confirm. If they want only part of it - make the appropriate selection. But of course, this after that has to be wired to the current RMA process. How hard would it be - I don't know because I currently don't use it.

IMHO the button should not be in the footer - it has to be in the profile of registered customers or as Yabber said in their guest tracking so there is at least some level of authentication. If the customer made a registration it is just as simple to cancel their order in their profile and this is the purpose of the law - 'order with one button' and 'cancel with one button'. Same with guest customers.

[DRMasterChief]

6 hours ago, Yabber said:

Canceling an order is not the same as returning an order - they are two completely different processes.

A customer who has no information about their order is not a customer.
Can you log into your bank account without any login information?
You can't make this feature so that hackers from all over the world can cancel all orders in our store.

This is my own module running on the displayOrderDetail hook - it is visible in standard customer and guest orders. The screenshot shows a simple configuration of the module.
Of course, for orders that have the status “Order shipped” or “Delivered,” there can be no question of canceling the order. For such orders, the customer should make a standard return after receiving the shipment.

Canceling an order is not the same as returning an order—they are two completely different processes.

>> I understand the regulation to mean that cancellation must be possible via a button, regardless of whether the order is partially or completely canceled. As already mentioned, the return process (if goods actually need to be returned) is then handled separately and manually or through some other automated method. This doesn't affect the required cancellation button; that's a separate issue.

As you wrote, in such cases, the customer has to follow the standard return process, but that's precisely what they initiate with the cancellation button (but only the first step).

Whether the retailer then (automatically) sends a return label, etc., is independent of this and must be considered separately (or it's a much larger, more complex solution with associated costs, as I've already mentioned).

 

A customer who has no information about their order is not a customer.

>> I understand that, but that's not the point the regulation stipulates.

 

Thank you so much for your contributions. Let's continue to think about this and find solutions.

 

I'd like to add something regarding guest tracking, specifically the issue of the unsubscribe button not being easily and clearly visible to everyone:

I think this alone will cause problems or legal warnings. We would then have to explain to "the world out there" that the button exists, but is only accessible with some difficulty. That's precisely what the law doesn't want...    How exactly this should be resolved isn't entirely clear at the moment.

That's precisely why I had the idea to make the button clearly visible and always accessible at the beginning of the regulation. If, after some time, there are court rulings and experience with them, it can potentially be adjusted so that it can be moved to the customer menu.

 

Edited 8 minutes ago by DRMasterChief