Compliance module · six platforms
EU consumer law gives buyers a right to withdraw from a distance contract, and the direction of travel is towards a clear digital withdrawal function on the website itself.
A permanently visible button, an online declaration, a confirmation step, and an automatic acknowledgement on a durable medium. This page explains what that function has to do, and what it takes to build one correctly.
The classic pattern was a withdrawal form as a downloadable document. The consumer found it, printed it or filled it in, emailed it, and waited. Every step of that flow puts friction in front of a right the law grants unconditionally.
A digital withdrawal function removes the friction and, just as importantly, produces evidence. The shop knows exactly what was requested, for which order, at what time. So does the consumer. Neither party is arguing about whether an email arrived.
Five things, and each of them is harder than it looks.
A button that exists only inside a signed-in account area is not available to a guest buyer. It belongs where a consumer would look: the footer, the account area, the order list, the order detail, the contact page and the returns policy.
The consumer has to be able to say which order they are withdrawing from. That means matching an order number against the email used to place it — for buyers with an account and for guests alike.
Which products, which quantities, contact details, refund details, return method. And it has to subtract quantities already covered by an earlier request, or a consumer can withdraw from the same item twice.
A distinct confirmation step, with the legal text visible, and a button whose wording leaves no doubt about what pressing it does.
Immediately, automatically, containing the content of the request, the date and the time. Durable means the consumer keeps it — not a confirmation screen that disappears on refresh.
In the shop
The button sits in the order the buyer already has open. Behind it: the order number and the email address used at checkout. Nothing to download, nothing to print, nothing to sign and scan.
Identification (order number plus the email used on the order — signed-in customers starting from their own order skip this step), product and quantity selection with already-requested quantities deducted, a review step with the legal text in view, and confirmation.
The consumer receives an email acknowledgement; the shop administrator receives a notification. That pairing is the evidence.
Vanilla JavaScript with fetch, no jQuery or Bootstrap dependency, and its own injected styles — so it does not fight your theme. It adds no URL to your structure and does not interfere with an existing SEO setup, including packages that own URL routing.
On OpenCart it uses events rather than editing theme templates, so a Journal or custom theme keeps its own footer intact. It uninstalls cleanly, and records with legal value are retained by default rather than deleted with the module.
A filterable list, a detail view with history, status changes with optional notification, export, and an audit log.
CSRF tokens, server-side validation of order and email, request rate limiting, hashed tokens for guest orders, IP masking, and GDPR retention, anonymisation and attachment deletion periods.
If you run several shops on different platforms, or you are an agency maintaining shops for clients, you get one behaviour to learn and one answer to give.
3.0.3.8, with 2.3.x and 4.x adaptations. Delivered as an OCMOD module.
Version 5 and above. Delivered as a WordPress plugin, HPOS-compatible.
1.7 and 8. Delivered as a native module.
2.3 and above. Delivered as an app/code module.
An App Proxy backend plus a Liquid snippet.
A standalone backend, a REST API and an embedded widget.
In the shop admin
Every declaration with its own code, the order it belongs to, its state and the language it was filed in. That is what you need the day somebody disputes whether the withdrawal was ever sent.
It implements the technical function. Full compliance also requires the button to be placed visibly where consumers will find it, and your pre-contractual information and returns policy to state that the function exists and where it is. Both are part of the implementation we deliver, but they are decisions you sign off — not something a module can do on its own.
We do not claim the module removes your exposure. We claim it builds the function correctly, with evidence attached to every request.
The specific national rules and dates differ by Member State, and this page deliberately does not guess at yours. Tell us the markets you sell into and we will confirm what applies before anything gets implemented.
One contract can mean ten shops. If you maintain ecommerce sites for clients, the module plus implementation is a service you can resell.
The right of withdrawal in EU consumer law protects consumers. Business-to-business distance selling is governed differently. If you sell to both, the function needs to apply to the consumer side — which is a configuration question, not a separate build.
Yes. Identification works from the order number and the email used to place the order, so a buyer who checked out as a guest can withdraw without creating an account.
No. The flow runs in a modal opened from a button, so it does not add indexable URLs or change your site structure. On OpenCart it works with or without SEO URLs, and it does not overwrite rules owned by an SEO package. Where a landing page is used, the default recommendation is noindex, follow.
They are retained by default. Records with legal value should not disappear because a module was removed; deletion is a deliberate action with a legal basis behind it, not a side effect.
OpenCart, WordPress with WooCommerce, PrestaShop, Magento, Shopify, and Gomag or custom shops through a REST API and embedded widget. Tell us what you run and we will confirm the delivery format.
Yes — product and quantity selection is part of the flow, and quantities already covered by an earlier request are deducted automatically so the same item cannot be withdrawn twice.
