Germany’s withdrawal button became mandatory for every B2C online shop on June 19, 2026. The deadline has passed. The question isn’t whether you need to act anymore, it’s whether your Shopware store already has it set up correctly.
I looked at the native solution Shopware shipped in version 6.7.9.0, and checked what shops without that version need to do instead. This post covers both paths: the native toggle for standard storefronts, and the manual build for custom or headless setups, plus the form and confirmation copy you can use directly.
What Section 356a BGB actually requires since June 19, 2026
The requirement traces back to an EU directive and is codified in Germany as Section 356a of the Civil Code (BGB). The core rule: if your shop closes contracts through an online interface where a right of withdrawal exists, you need a withdrawal function that stays permanently available, prominently placed, and easily accessible for the entire withdrawal period. It has to be labeled “Cancel contract” (Vertrag widerrufen in German) or an equally unambiguous phrase.
This covers every B2C contract closed through an online interface with an existing right of withdrawal, regardless of whether the shop primarily serves B2B customers. The moment a consumer contract with a withdrawal right can be formed anywhere in the shop, the requirement applies.
If the button is missing or poorly integrated, hidden, hard to find, or only visible on certain subpages, it counts as a competition law violation. The consequences are costly cease-and-desist letters and injunctions, not just a fine from a regulator.
Are you already too late?
The deadline is two weeks behind us. That makes the situation more urgent, not less: competitor associations and rivals typically start actively checking for compliance only after a legal deadline has passed, because before that, some benefit of the doubt is assumed. That benefit of the doubt is gone after June 19.
Three questions for a two-minute check:
- Does your storefront footer show a button labeled “Cancel contract”?
- Does that button lead to a form the customer can submit electronically, without writing their own email?
- Does the customer automatically receive a confirmation that their withdrawal was received?
A “no” to any of these means the shop isn’t compliant right now.
The native solution: activating the withdrawal button from Shopware 6.7.9.0
Requirements
The native solution ships from Shopware 6.7.9.0, released in April 2026, with a backport to version 6.6. If your shop runs an older 6.x version or is still on Shopware 5, this option doesn’t exist. The section further down on outdated versions covers what to do in that case.
Step by step
Activation happens in the admin, not in a page builder or a custom plugin:
- Log into the Shopware 6 administration.
- Navigate to Settings → Basic Information.
- Scroll to the Legal and Privacy section.
- Enable the option to display the “Cancel contract” button in the footer.
For shops on the standard storefront, that’s the entire technical lift. No custom code, no plugin, no manually building a form.
What happens after activation
Once enabled, the button appears in the storefront footer. Clicking it opens a form page where customers submit their withdrawal electronically. Shopware generates a shop page layout for this automatically, already linked. After submission, the customer automatically receives a confirmation that it was received, as the law requires.
For a title and confirmation text you can use directly, see the templates further down.
No standard storefront? Custom templates and headless setups
With custom templates or headless architectures, the admin toggle doesn’t reach your frontend. The native solution is tied to the standard storefront. If your frontend runs independently, say as a React or Vue app against the Shopware API, you need to build three things yourself:
- A button or link labeled “Cancel contract,” permanently visible somewhere reachable from every page, typically the footer.
- A form endpoint that accepts the withdrawal declaration and processes it electronically, without requiring the customer to write their own email.
- Automatic confirmation logic that fires immediately after submission.
This isn’t a weekend project, but it’s not a storefront rebuild either. If you’re already maintaining custom plugins, the cleanest path is building this as a standalone service that hooks into the checkout and account areas through Shopware’s extension points, rather than wiring it directly into the template. I wrote about how I build Shopware 6 plugins that survive updates, and the same principle applies here: a decorator that encapsulates the form logic doesn’t break on the next Shopware update.
Customizing the form and confirmation email without breaking layout or language versions
The form page Shopware generates on activation can be placed and customized through Shopping Experiences. Important distinction: Shopping Experiences only handles the page design, not the activation itself. The function itself comes from the Basic Information settings; you design the surrounding layout in the usual place.
Title for the form page:
Cancel contractThat’s the phrasing the law itself gives as the compliant example. There’s no reason to swap in something more creative and take on risk the statute already rules out.
Confirmation text for the on-screen message after submission (a form element setting, plain string with no placeholder logic):
Thank you for your withdrawal request.
We received your withdrawal declaration electronically. This confirmation
serves as proof of receipt of your withdrawal.
We'll follow up with the next steps (return, refund) in a separate message.
If you have questions, reach us at [email protected] or +49 xxx xxxxxxx.This field is what shows on the page right after submission, not the email. Shopware takes the content as a literal string, there’s no placeholder resolution. Order number, date, and time can’t go in here, only fixed text like your contact details.
The actual confirmation email is a separate template under Settings > Shop > Email Templates (“Withdrawal request customer”). That one runs on Twig and has real variables from the form:
Thank you for your withdrawal request.
We received your withdrawal declaration for {{ revocationRequestFormData.contractNumber }}
on {{ revocationRequestFormData.submitTime|format_datetime('medium', 'short', locale='en-US') }}
electronically. This confirmation serves as proof of receipt of your
withdrawal.
We'll follow up with the next steps (return, refund) in a separate message.
If you have questions, reach us at [email protected] or +49 xxx xxxxxxx.Only contractNumber, firstName, lastName, email, comment, and submitTime are available. There’s no phone number field in the form data, so your contact details go in as fixed text here too.
Three things merchants commonly get wrong when setting this up:
First, the on-screen text and the email template are two separate places with different capabilities. Write [Order Number] in the on-screen field and that’s exactly what shows on the page, not the real order number.
Second, this text confirms receipt only, not processing. Don’t promise a refund timeline or pickup date here. That belongs in a separate message once the withdrawal has actually been reviewed.
Third: if your shop is multilingual, the confirmation email needs to go out in the language the customer shopped in, not default to German or English. You control that through snippet management per storefront language. Testing every active language before going live is mandatory, not optional.
Pre-launch test checklist:
- Complete a test order with a test account.
- Trigger a withdrawal through the footer button.
- Check the confirmation in the inbox, including sender address and subject line.
- Check the form’s mobile rendering, since most withdrawals get submitted from a phone.
- For multilingual shops: repeat the same test in every active language.
Still running an old version?
If you’re still on Shopware 5 or a 6.x version below 6.6 with the backport, you have neither the native solution nor a stable base to reliably build your own plugin against. Shopware 5 has been end-of-life since July 2024, and I covered why every additional month on that version raises the risk, not just on this one issue, in a separate post on the Shopware 5 migration.
A plugin for the withdrawal button on an outdated version is a short-term workaround, not a fix. It solves the compliance question for the moment while the actual problem, an unsupported platform in production, keeps running underneath it. The right order is update first, withdrawal button second through the native solution, not the other way around.
Act now: a three-step compliance check
Check your Shopware version. From 6.7.9.0 or with the 6.6 backport, activate the native solution through Basic Information in a few minutes. With custom templates or headless setups, build the button, form endpoint, and confirmation logic yourself. On older versions, the platform migration comes before the withdrawal button.
Then test the full flow yourself once, including the confirmation email in every language your shop serves.
Frequently asked questions
Since when is the withdrawal button mandatory in Germany? Since June 19, 2026. The requirement is codified in Section 356a BGB and mandates an electronic withdrawal form that stays visible and easily accessible throughout the withdrawal period.
Which Shopware version ships the native withdrawal button? Shopware 6.7.9.0, released in April 2026, with a backport to 6.6. Older versions have no native solution and need a manual implementation.
Where do I activate the withdrawal button in Shopware 6? Under Settings, Basic Information, in the Legal and Privacy section. Enable the option to display the “Cancel contract” button in the footer.
Does the native solution work with custom templates or headless storefronts? Not automatically. With custom templates or headless architectures, the button has to be actively built into that frontend and tested, because the native storefront integration doesn’t apply there.
What happens if the withdrawal button is missing or broken? It counts as a competition law violation and can trigger costly cease-and-desist letters and injunctions. Since the deadline has already passed, competitor associations are actively checking for it.
Need help implementing it?
On a standard storefront, this is a ten-minute job. On custom templates, headless setups, or shops running outdated Shopware versions, it’s a real technical project where mistakes translate directly into legal exposure. If you’re not sure which case applies to you, or want help with the implementation, get in touch. More on what actually matters when choosing the right help, in this post.
