E-commerce · Strategy & fundamentals
Germany's Withdrawal Button Is Mandatory – and Many Stores Don't Have It
Since 19 June 2026, virtually every B2C online store selling into Germany needs a digital withdrawal function (§ 356a BGB). What the button must do, where implementations fail and how it looks in Shopify and Shopware. As of August 2026. Not legal advice.
By Boaz Lichtenstein Prefer us on Google

Since 19 June 2026, virtually every online store selling to consumers in Germany needs a digital withdrawal function. The rule sits in the new § 356a BGB and follows a simple idea: if a contract can be concluded in two clicks, it should be possible to withdraw from it in two clicks – exactly as the cancellation button for ongoing contracts established before it. The deadline passed without the attention the order button and the cancellation button received. Accordingly, plenty of stores do not meet the requirement today – and are exposed as a result. This piece sorts out what the button has to do and where implementations get stuck. As of August 2026. (Not legal advice – a binding assessment of your specific case needs a lawyer.)
Key takeaways
- Mandatory since 19 June 2026 for consumer contracts concluded via an online user interface that carry a right of withdrawal (§ 356a BGB).
- Two steps are required: a button “Vertrag widerrufen”, then a short form, closed with “Widerruf bestätigen”.
- The form asks only what is needed: name, details identifying the contract, and the channel for the acknowledgement.
- No forced login, unless concluding the contract itself required an account – guest buyers must be able to use the function.
- Prominent and permanently reachable, not hidden in a list of footer links.
- Acknowledgement on a durable medium, in practice an email with the date of receipt.
- Double risk: a regulatory offence with a range up to €50,000 (up to four percent of annual turnover for larger companies) and cease-and-desist exposure as an unfair practice.
What the button has to do
The requirement is not a design detail but a flow with an evidentiary function. It has three parts.
First, the entry point. A button labelled “Vertrag widerrufen” or equally unmistakable wording. Creative labels are not design freedom here, they are a risk: the point of the rule is that consumers find the function without searching and without interpretation. It also has to stay reachable throughout the withdrawal period – not only in the order confirmation nobody can find three weeks later.
Second, the form. It deliberately asks for little: the name, details identifying the contract – usually the order or contract number – and the contact channel for the acknowledgement. Adding mandatory fields you would otherwise like to have (reason for return, phone number, bank details) builds a hurdle where the rule explicitly wants none. It closes with a second button, labelled “Widerruf bestätigen”.
Third, the acknowledgement. The consumer gets receipt documented on a durable medium, in practice an email with a date. That email is a confirmation of receipt, not a validity check – it says “arrived”, not “accepted”. Phrasing that distinction cleanly is the text block most implementations have to revisit.
The three traps
The login. A withdrawal inside the customer account is convenient to build and worthless for guest buyers. If you allow guest checkout – which almost every store does – the function has to work without an account. That is the actual engineering: an order must be identifiable from an order number plus a second detail, without turning into an interface that discloses other people’s orders.
The placement. “Prominent and easily accessible” is not a footer requirement. A link between the legal notice and the terms does not satisfy it on the prevailing reading. Several routes at once make sense: a dedicated page, linked from the order confirmation, from the customer account and from the help section.
Confusing it with the withdrawal instructions. The instructions inform, the button acts. Both remain necessary, and keeping them apart helps in substance too: the button must not be buried in instructional text, or it stops being what it is meant to be – the shortest route.
Implementation in Shopify and Shopware
Neither Shopify nor Shopware ships the function natively; both ecosystems have filled the gap with apps and plugins since the spring. For the selection, the same three questions apply as with any other app – usefulness, load time, native alternative – as covered in the best Shopify apps.
A custom build is feasible and in one respect even attractive: the flow is small and the data already sits in the store. But it has to deliver two things, or it creates a new problem. It needs identification without a disclosure leak – an order number alone is not enough, or anyone guessing numbers could trigger other people’s withdrawals. And it needs spam protection, because a public form without a login attracts exactly that; a cookieless captcha service is the privacy-friendly option here.
One side effect that often gets overlooked: a clean digital withdrawal makes returns measurable, because every case arrives structured instead of as a free-text email. Deriving rates per product range from that surfaces the items that bring revenue and cost margin – the logic is laid out in returns management.
Bottom line
The withdrawal button is not a project to prioritise – it is an obligation whose deadline has already passed. The effort is half a day, the risk is a cease-and-desist letter plus a fine range. Checking today means checking three things: is the function reachable for guests, is it findable in two clicks, and does the acknowledgement email arrive. Everything else is polish. And because law is never legal advice on this site: the wording for button, form and acknowledgement email belongs on the desk of somebody who carries liability for it.