EU withdrawal button requirement

Marc Meese how this should really work? Just reading this, I think you can just create a form with any Form Plugin (Fluent Forms) and give a super simple fields_ like, name, email, order id etc and process the refund manually to make your store compliant?

Our team is exploring a feature for adding refund request and show as group but in that case, the user must need to be logged in; otherwise that will be as the same as a request a refund form.

.

Do you mean the German implementation of the EU Directive? The title of "Withdrawal Button" or "Button Requirement" is misleading. That is just common wording, the law requires a withdrawal function which can be a form, or it can even be a function within the user account to withdraw only a subset of contracts. However, I would always go with the form. Withdrawal is not the same as cancel. Adding that to FluentCart can become very tricky. Using a simple Fluent Form with the consumer’s name,
details identifying the contract the consumer wishes to cancel,
and details of the electronic means of communication should do everything you need.

For those questions I prefer talking to a lawyer rather than a privacy council. See this for a pretty detailed description (German only): https://www.it-recht-kanzlei.de/widerrufsbutton-faq-leitfaden-online-handel.html

EDIT: Found this article including examples just after posting the comment: https://datenschutz-generator.de/widerrufsbutton/

And what about B2B payments with PEPPOL, already implemented in several countries. I'm afraid Fluentcart unfortunately won't be usable in Europe for a long time. Our legislations are crazy.

Shahjahan Jewel A simple form like you suggested for guest sales is sufficient, so the feature being requested is redundant. However, an official returns function in the admin and possibly for logged-in customers would indeed be fantastic. Shopify has this too, and it works great (screenshot 1: return & 3: refund). As you can see, there is an option to upload return labels and track the shipment yourself. There is also a function to deduct costs, such as the cost of the return label or processing fees. By the way, a built-in function in FluentCart for tracking orders for users who do not use a shipping platform (screenshot 2). And the ability for 3rd party services to hook into this via API would also be fantastic.

*I used AI to convert the Dutch text in the screenshots to English.

Shahjahan Jewel according to the directive as far as I understand it, people need to be able to basically do ctrl+z on purchases and other as quickly as possible. Making someone wait for an admin to take care of this actually causes issues with compliance. So it would be useful and necessary to make a withdrawal button available on the FluentCart shop page as well as the 'thank you for your order' page.

Shahjahan Jewel , I agree with Jorge de los Reyes .

In the long term, it will be necessary for the return functionality to be implemented natively in FluentCart and a "workaround" solution via FluentForms will not be sufficient, because this type of functionality may tend to develop and this will be one of the decisive signals whether an EU seller chooses FluentCart as a solution.

We have this solution deployed on one of our Woo e-shops https://wordpress.org/plugins/eu-withdrawal-button-for-woocommerce/ and it currently provides the minimum that is needed. This means the ability to enter mandatory order and customer data via a publicly available form, where even an unregistered consumer will be answered by the system whether they are still within the 14-day period and can submit a return request, or if they have already exceeded it.

However, if he logs in, it is of course easier, because either the data can be pre-filled for him, or he should see a button in the order list for that order, where it still falls within the defined withdrawal time. If it is exceeded, he no longer has that option.

About 2 weeks ago I also filed a ticket with support, but what is described in this thread is even more valuable.

If a merchant/seller has hundreds or thousands of products, it is essential to have this functionality available, because otherwise it can be madness if even 100 customers return the ordered goods at different times.

Sander W., Shahjahan Jewel there's so much conflicting information so I thought I'd do a deep dive. The German government didn't make it easy, though!

Here's what I was able to understand after my research:

1. The customer should not have to take additional steps for withdrawing compared to originally making the order. So, sites with guest purchases enabled must provide a way for guests to withdraw without logging in.
2. For cancellations, you need to provide a reason and the seller can take a reasonable amount of time to respond for you. For withdrawals, they need to be able to do it immediately and with no reason. The only thing you can ask them to provide is security information to ensure someone isn't maliciously withdrawing their purchase.
3. You can still provide a withdrawal button on their account page if they are automatically logged in upon purchase, since they wouldn't need to take any additional steps or provide any additional information to get there. This is one step to being compliant.
4. It is ok to offer an optional login form that customers can choose to log in with if they want to, but it musn't be mandatory to log in for the purpose of a withdrawal.
5. The withdrawal button needs to cancel the transaction and make it as if it didn't happen at all. That's different from a cancellation.
6. If a client forgot their username and password and accidentally gets logged out, they should still be able to withdraw without having to go through any other steps. That means it's not compliant for you to force them to reset their password in order to access the withdrawal.
7. The withdrawal needs to give them confirmation immediately.
8. If you make them wait for approval, the system is not compliant. We cannot have it so that the consumer waits for us to manually approve the withdrawal, but we also can't make it so that people have the power and ability to maliciously withdraw someone else's orders.
9. You can ask customers for identifiers like their name, order number and password in order to ensure security. However, it comes with a few caveats:
   1. If the customer is already logged in, you can't ask for those things again.
   2. It cannot send or redirect the customer to a login page. Those identifiers need to be part of the form they fill out for withdrawal.
10. The process for withdrawing can't be longer, be more involved, require more infromation or require more steps than the process of signing up did in the first place.

However, this does introduce a security issue that I think is important for us to talk about: if people are able to withdraw without friction or login, then hypothetically they could maliciously withdraw someone else from a purchase with no way to stop that. This would also be a legal nightmare, not only because of the GDPR issues of trying to figure out if the person who withdrew was correct.

So I thought a good solution was double opt-in of some sort, although doesn't that introduce an extra step, which goes against the compliance? It turns out that it would probably not be compliant because it requires extra steps. They ask you to provide email confirmation of the withdrawal, but not email verification that you want to withdraw. It needs to happen after the withdrawal has already taken place.

This put me in a stressful situation, because I know there are many people online who would be able to find a way to exploit this: either maliciously withdrawing other people's orders or withdrawing their own when it's not appropriate to do so.

My next consideration was this: if you cannot require extra steps for them to withdraw, would it be ok to put a magic withdrawal link into all confirmation emails and invoices that bypasses the need to log in? But the problem with this is that it could still be considered to be an extra step that they're engaging with.

I did find this though:

On the confirmation page, a business required its customers to provide their password as an identifier for the termination (i.e. this was no login request, but a password request). The court found this additional information request on the cancellation confirmation page to be acceptable since it solely served for the clear identification of the consumer and did not redirect them to a login or customer account area. This practice does not constitute an inadmissible hurdle under §312k BGB. 

From the page I found it on (if it's got good legal information), it seems to me that the problem that many companies were running into is that you cannot require login or redirect a customer to a login page that is not related to the form.

However, you can require identification during the form process for security purposes, as long as the place where you're requiring this information is in the actual withdrawal or cancellation form. Of course, these are talking about legal battles for cancellation rather than withdrawal (which aren't the same thing), but given the relative lack of information about the withdrawal button, I am forced to treat the two as if they have the same requirements.

But since the withdrawal needs to be immediate, there still needs to be automation and integration with FluentCart. There also needs to be an automated way for us to check user authenticity without requiring them to log in, either through providing a password or some other identification that's more than just the order number and email.

There would then need to be an automated, immediate process to check the details that the customer provided and cancel if the details match a real purchase that is within the mandatory withdrawal period. Then, the contract needs to be automatically cancelled, and an email confirmation needs to be sent immediately.

But it also needs to account for the fact that once the customer has accessed the product they terminate their right to the withdrawal period immediately. So if they open a course that they paid for on FluentCommunity and go to a lesson, for example, then they no longer get right to withdraw.

With that in mind, a simple form is not enough.

But please do let me know if you're an actual German speaker, any of you! I'm just piecing things together with some help from friends, a dictionary and Google Translate.

Sources in another comment.

What to do?

It seems to me that the best way for FluentCart, FluentForms and FluentCommunity etc to be compliant is going to take a lot of thought. The things we would need to be undeniably following the law are:

• Turn off guest checkout if you don't want people to have to provide no identifying information. I think guest checkouts that don't mandate account creation during the process are a bad idea, anyway.

• Provide a withdrawal button in the confirmation screen/page that customers see after an order is placed.

• A section of the shop account that allows people to cancel and withdraw that's clearly visible from their account page.

• Shortcodes for us to be able to visibly place the withdrawal/cancellation form button in footers/headers/sidebars.

• A way for the FluentForm to check pre-existing information for customers that will confirm if their password is correct without them having to be forced into a login page. It should natively be part of the withdrawal form.

• A way for the identification sections to be already filled in if the person is logged in.

• A section in order confirmation emails that redirects them to the withdrawal page, with possible magic links to reduce friction (for a time, anyway. I understand the security risks of having a magic link that's accessible for 14 days).

• FluentCart, FluentCommunity, FluentSMTP, FluentBooking and FluentForms will need to talk to one another more clearly:

  • Immediately check credentials and grant the withdrawal if they match and the customer is still within their withdrawal period.
  • Immediately send a confirmation email if the withdrawal is successful.
  • If the details do not match, immediately send an email notification to inform the consumer, perhaps alongside automatically a FluentSupport ticket to query if the customer was the person asking for the withdrawal.
  • Set custom withdrawal periods in line with EU law that also let us account for things like services that are already complete (for example, completing a booking on FluentBooking should automatically cancel the withdrawal period).
  • Check if the user has downloaded any digital material on FluentCart or if they have accessed a lesson or downloaded a resource in the Community, or if they accessed the space that they paid for. This should then automatically cancel their withdrawal.
  • We might also need to be able to set product-based withdrawals for FluentCart and meeting date-based withdrawals for Bookings.

This would need to be comprehensive and include all the things I listed.

The reason I'm adding all these complex things isn't because I think it's easy to do. It's because if we need to automatically give them their withdrawal, then we need to still have a way to protect ourselves.

Otherwise, we might run into situations where someone is outside of their withdrawal period, or they have already used the product/service and then get an automatic withdrawal or refund immediately. That could be very dangerous for us sellers in the long run as it's an easy system to exploit.

On the other hand, if we try to do it that we respond to forms, we will not be compliant. It's supposed to be like a Ctrl+Z like I said earlier, so you cannot require them to wait until business hours or anything like that. It has to be immediate.

Any news about the integration?
According to the regulations, this would be required by June 26 at the latest.

Ideally, once logged in, users should be able to directly access orders placed within the last 14 days and cancel them. If not logged in, there should simply be a form field for the email address, first and last name, and order number.

This is how Germanized handles it for WooCommerce,