DRMasterChief

ok, so you are fine. It´s not my idea. The regulation says in point 37 regarding implementation: ....For example, the consumer should not have to undertake procedures to find or access the function.... So again my question: is a login an additional "procedure" to access this function? Please answer this question for yourself. In my opinion, it's at least one more step than simply clicking the first button or link, so it is. But perhaps we simply have to wait until June to see how this plays out. In Germany, we have the specific problem that lawyers can send out cease-and-desist letters, which are very expensive. This isn't the case in all countries, so perhaps that's why you're not so sensitive about it. Yes, unfortunately, this makes us very "anxious" in Germany, and online shop owners are often treated like serfs.

I understand if you want to support the module for your own reasons... but that's no reason to be so pushy. As already mentioned, requiring a login could be seen as a hurdle > it's not entirely clear yet; time will tell. However, I don't want to be a guinea pig and have to pay for it. 🙂 The explanations in point 37 of the regulation provide further clarity regarding implementation: ....For example, the consumer should not have to undertake procedures to find or access the function.... Is a login a "procedure" to access this function? Please answer this question for yourself. I just find it problematic to offer a module that might not take this into account and tells the customer it's 101% compatible with the regulation, because I don't think it is or it is not clear yet. But it's everyone's own decision. We'll probably find different solutions, and that's why we're here, not to quarrel.

@Yabber no absolutely not - and even if that were the case, it is exactly what is sufficient. 🤒 Do you have read any of the papers? And what about the opinions and recommendations of chambers of commerce, lawyers, etc.? I almost don't think so... You also haven't read my ideas on this, and yes, of course, it can be implemented in different ways, but I still want to keep it at the most minimal level. This needs to be implemented, and that's enough work and expense for most retailers. I won't be adding any extraordinary service levels. Please explain how you see this and how you will implement it. Then carefully check off the checklist to determine if and how the EU requirements are met.

I won't be performing any customer validation beforehand, as the policy doesn't require it. To prevent spam, I'm integrating Cloudflare Turnstile. If any "fake" customers misuse the form, it's just one more email we have to delete. But emails with the subject "cancellation" have to be processed or at least briefly reviewed anyway. A more automated solution isn't an option for us, as we only accept orders in the shop, and all further handling, delivery, invoicing, etc., is done in an ERP system. The form includes: Name, email, order number, and an optional text field for customer notes (e.g., to cancel only some items). That's sufficient for processing. We'll see whether we need to add another interface to the ERP system later (the number of returns is simply too low to justify the cost, thankfully). I'll place the link to the form in the "My Account" section, highlighted in color, so it's accessible from every page. There's plenty of space there, and it looks good and is easy to find. The emails to the customer are equally simple; they contain exactly the information they entered in the form. I'll also include the date and time (because that's required by the regulations), as the email header apparently won't suffice. There's still time before the deadline. I've already started working on it and can finish it within a few hours.

Hi, it is clearly stated: The withdrawal function shall be continuously available throughout the withdrawal period. Even if the button is displayed after the withdrawal period has expired, this is not a legal problem. There is no reliable technical way to calculate the withdrawal period in the shop. It depends on many factors, such as partial deliveries or whatever period the retailer voluntarily grants. The details of a partial cancellation of a larger order are not addressed in the EU directive. Thank you for that 😞 If a reliable way can be found to link the withdrawal period to the withdrawal period, that's fine. Please do so. However, if there is only one instance of an incorrect withdrawal period, it is not good for the retailer. The permanently displayed button naturally carries the risk that it will be used even after the withdrawal period has expired. However, this is not a problem; the withdrawal is then invalid. The retailer will have to check this in any case and inform the customer, etc. Then he has to inform the customer that the cancellation was received after the deadline, but this is no different from before, or if a customer still cancels by email. Just expose your guest tracking controller with a link in the footer for all guests, and that should suffice. >> Yes, that's true, but guests and logged-in customers can use it, except that the login process is (possibly) displayed afterward. This could be seen as an additional hurdle by logged-in customers > not good. I'm not sure if it's clear what I mean by that point? With all this in mind, I have to say that we actually don't have any cancellations/returns. Maybe I'm oversimplifying things? We simply have to implement it; only one customer will use it per year. But please let us discuss here further!

Thank you very much for the additional information. However, there seem to be differing opinions or different laws depending on the EU country. It appears that the EU regulation is then transposed into national law in each country. In Germany, the situation is such that the button must be clearly visible at all times, from anywhere (possibly highlighted in color). A login could present an additional obstacle and is therefore not permitted. A login is only allowed if ordering can only be done with a login. This likely doesn't apply to most shops, as almost all of them allow guest checkout. See my link, which is in English and explains all the guidelines for implementation in Germany. The same applies to several other EU countries, so Germany isn't alone in this. This concerns the amendment to EU Directive 2023/2673 on the introduction of the right of withdrawal (for goods deliveries). I absolutely cannot see in this that the shop operator has to provide a solution in which the customer can identify the contract (i.e., select their order in a login process). It is perfectly fine if the customer simply enters the order number in the withdrawal form. That's why I initially wanted to know how to implement such a button and now we can clearly see that most of the solutions will bringt this into the footer. I wish your module were suitable for me, but after all this and a checklist, unfortunately, it isn't. This is the official document and you can choose every EU language: https://eur-lex.europa.eu/eli/dir/2023/2673/oj (main thing is Article 11 a) and it explains in detail what is necessary (and what is not necessary, or what we as retailers do not need to represent).

Hello, thank you for the information. Please provide us with some more details. The product images are unfortunately difficult to see. How are guest orders handled? According to regulations, a login should not be required. The button must always be easily accessible and available. You mention refunds several times. Is this process implemented, or are you only referring to the cancellation request? An automatic refund would be problematic for the retailer and is not required. Additionally i found an actual paper with a lot of pratical help and hints, which explains a lot of questions which was earlier in this post here (e.g. place it in the footer...), please find it: https://www.noerr.com/en/insights/implementing-legislation-for-the-withdrawal-button-published

Yes, something like that was my intention. Maybe the thirtybees Team is looking for making some $ and sell this as a paid premium module.

...useful to find malicious files on the server if they are placed, let's say in img where they are extremely hard to find manually... This is a very nice idea and a real business case 🙂 Maybe we can see more about this in future. And regarding growing up, I'd like to say: my bank knows if there are too many zeros and it doesn't fit on the bank statement; they'll let me know 🤪🤑

All the free AI offerings have a daily usage limit (or they even fake model versions.). Nothing is truly free if you're looking at cutting-edge models. However, http://poe.com/ offers some pretty good models for free.

Some kind of OT, but which pricing model do you use @vincentdenkspel? I have a look for some php work on https://openlaboratory.ai/models/CodeLlama-70B but the Claude Sonnet with Coding looks also interesting. Maybe we should split this here for future AI things?

We shouldn't mix things up too much here. And I do think that one more problem can create one more problem than the other. 🙂 The right to be forgotten, data deletion, etc., must be guaranteed, but this can also happen through a standard request and doesn't have to be an automated process (perhaps it's different in other countries). Most retailers will probably use an ERP system or CRM in addition to their online shop system, so a process within the online shop itself isn't very helpful, because the data also needs to be deleted from other systems. I would find it a shame if the discussion and search for a solution ended here. That's usually how it feels in forums when someone brings up a different idea. Let's work on solutions for the cancellation button, and if necessary, everyone can review the minimum legal requirements again.

I actually came across a case where something very similar was being complained about. It's not about a cancellation for goods, but rather the long-standing law regarding cancellations for subscriptions or financial services, etc. It concerns an offer from HP: (please use the translation for you language) https://www.bundesjustizamt.de/DE/Themen/Verbraucherrechte/VerbandsklageregisterMusterfeststellungsklagenregister/Verbandsklagenregister/Unterlassungsklagen/Klagen/2025/282/UKlag_282_2025_node.html

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.

I don't understand why everyone in the PrestaShop forum seems to think this is so terrible.... bla bla. I would take massive legal action against the provider, meaning multiple official reports to the data protection authorities in every country where a forum member resides. That's the intended course of action, that's all there is to it. It should be noted that payment data is also affected. There's no room for "oh, what a shame, blah blah," but rather, hard facts must follow.

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)?

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.

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

@30knees danke für dein "like", kannst du daran mitarbeiten oder etwas beitragen? Wir sollten hier in der Community eine einfache Lösung erarbeiten, das wäre doch toll. (not sure if you will read this in English 🙂 )

Okay, we're getting quite off-topic here. But that's okay, right? 🙂 I wrote a long time ago that charging a low monthly fee can be a good approach. It absolutely mustn't scare off potential customers. It's (nowadays) very important to reach small retailers/shops that don't have a large budget. This is exactly where Thirtybees would be a great solution, and $4-5 per month for the shop as pure software would be fantastic. Payable every six months in advance. If that's too complicated to implement, offer a free 30-day trial or something similar. Then the license would need to be activated. It's important that no money-grubbing third-party provider does this (no Envato, please). And of course, it has to work flawlessly. I'd be happy to receive a license via email and have me insert it into a config file and upload it—no problem. I'm fine with that. In addition, there could be paid premium modules for ThirtyBees (as has already begun). That's fair, because nowadays it's also important to only pay for what you need. One more important point: Some information about ThirtyBees is extremely outdated. The demo, changelog, version roadmap, etc. It's also not entirely clear how and for what purpose paid support is provided; this urgently needs to be revised.

Good for customers? Time will tell. In any case, a lot would have to change. The current model is no longer suitable for e-commerce today (from the retailers' perspective).

@netamismb you can find a lot of ideas for an update here in this section: Updating thirty bees - thirty bees forum

Hi, many thirty-bees/PrestaShop themes provide the variable `$cart` in the shopping cart template. Then, in the template, you can simply add: smarty {* show Cart ID *} div class="cart-id"> Cart ID: {$cart->id} </div> If it's not already available, you'll need to pass the Cart ID to Smarty via a controller. The correct controller for the shopping cart is `CartController` (controllers/front/CartController.php) (or for one-page checkout: `OrderController`, I think, you'll need to check that). If you have to retrieve it via a controller, I would create an override for it so that it persists after an update.

thank you, appreciate this! (i will save this time 🤙)

Great! and can i implement this (manually) also in 1.6 ? (i get this error with php8.1 and want to fix it for my update in live-shop)