Withdrawal Button from 19 June 2026: What Online Shops Need to Do Now

The withdrawal button will become mandatory for many online shops and digital B2C offers in Germany from 19 June 2026. This is not an additional marketing feature, but a legally required electronic withdrawal function: consumers should be able to withdraw from an online contract on the website or in the app in a similarly low-friction way as they concluded it.

For shop operators, the topic is therefore more than a footer link. It touches design, checkout logic, customer accounts, guest orders, email confirmations, legal texts, support processes and technical documentation. This guide provides a practical overview. It is not legal advice, but it helps technical and operational teams prepare the implementation.

Legal Basis and Timeline

The European basis is Directive (EU) 2023/2673. It amends the Consumer Rights Directive 2011/83/EU and introduces, among other things, a new Article 11a on exercising the right of withdrawal through an online interface. Germany implemented the requirement through changes to consumer contract law; the official German publication can be found in the Federal Law Gazette 2026 I No. 28.

For practical implementation, the new Section 356a of the German Civil Code (BGB) is central. It deals with the electronic withdrawal function for distance contracts and applies from 19 June 2026. An English legal overview by SZA Schilling, Zutt & Anschütz summarises the core idea: traders who enable consumers to conclude distance contracts through an online interface must provide a withdrawal function.

For project planning, four points matter:

Point	Meaning for businesses
EU basis	Directive (EU) 2023/2673 amends the Consumer Rights Directive.
German implementation	The new Section 356a BGB governs the electronic withdrawal function.
Deadline	The function must be available from 19 June 2026.
Earlier rollout	Earlier activation is possible, but the full process should already match the legal logic.

Anyone who launches the function before the deadline should not simply add a visible link. Once a digital withdrawal path is offered, labelling, form design, confirmation, data minimisation and email handling need to fit together. A half-finished entry point can create more questions than it solves.

Who Is Affected by the Withdrawal Button

The obligation affects traders who conclude distance contracts with consumers through an online user interface and where a statutory right of withdrawal exists. In practice, this covers more than classic product shops.

Relevant cases can include:

• WooCommerce, Shopify and other B2C online shops
• booking platforms for services, courses, appointments or digital offers
• subscription and membership platforms where a right of withdrawal applies
• providers of digital content or digital services
• insurance, financial services and contract portals with online conclusion
• marketplace sellers if they sell to consumers via platforms such as Amazon or eBay

The obligation does not depend on company size. Small retailers, sole traders and niche providers should also check whether their contracts are concluded through a website, app or platform and whether a right of withdrawal exists.

Pure B2B offers are not affected if contracts are concluded exclusively between businesses. Contracts without a statutory right of withdrawal are also outside the actual withdrawal use case. Typical exceptions are listed in Section 312g BGB, for example certain custom-made goods, perishable goods, unsealed hygiene products, unsealed software and some leisure services with a fixed date. The official German wording is available in Section 312g BGB. Legal classification should be checked carefully, especially for mixed assortments or services with several components.

Withdrawal Button and Termination Button Are Not the Same

Germany already has a termination button under Section 312k BGB. It concerns continuing obligations that can be concluded online, for example certain subscriptions or ongoing memberships. The withdrawal button under Section 356a BGB has a different purpose: it makes it easier to exercise an existing right of withdrawal within the withdrawal period.

The distinction matters for design and user guidance:

Function	Applies to	Typical effect
Withdrawal button	Contracts with a right of withdrawal, usually shortly after conclusion or delivery	The contract is reversed; services and payments may need to be returned.
Termination button	Ongoing contractual relationships	The contract ends for the future according to the relevant termination rules.
Returns form	Operational process for sending goods back	Can be related to withdrawal, but does not automatically replace it.
Contact form	General service request	Not sufficient as an unambiguous electronic withdrawal function.

A shop should therefore not merge everything into “cancellation”, “return” or “service”. Users need to understand whether they are withdrawing from a contract, terminating an ongoing service, returning goods or contacting support.

Requirements for the Withdrawal Function

The term withdrawal button is useful, but technically a little narrow. The law requires an electronic withdrawal function. This can be implemented as a graphical button, a clearly highlighted link or a comparable interface element. What matters is not the rectangular shape, but visibility, accessibility and unambiguous wording.

Permanently Available and Easy to Find

The function must be available during the entire withdrawal period, placed prominently and easily accessible to consumers. For shop operators, this means that a hidden feature deep inside a customer account will often not be enough. Guest orders in particular must be withdrawable without forcing the customer into a later login.

Typical useful placements are:

• footer link on every page
• additional link in the customer account or order overview
• reference in the order confirmation
• link in the withdrawal instructions
• app menu or service area if the contract can also be concluded through an app

A footer link is rarely the most convincing entry point, but it helps ensure permanent availability. Shops with customer accounts, booking flows or apps should also provide the entry point exactly where users expect their order or contract, not only after three clicks in a support menu.

Clear Wording Instead of Service Language

The label should be easy to read and use “Withdraw from contract” or an equally clear alternative. For the second step, “Confirm withdrawal” is the intended logic, again in similarly clear language.

Good examples are:

• “Withdraw from contract”
• “Submit withdrawal”
• “Confirm withdrawal” for the final confirmation function

Problematic terms are those with several meanings:

• “Cancel”
• “Start return”
• “Contact us”
• “Service request”
• “Return”

“Start return” may feel similar to many customers, but legally it does not necessarily describe a withdrawal. The two processes may be technically connected. The important point is that the withdrawal declaration remains clearly recognisable as such.

Design Without Obstacles

The withdrawal function must not disappear into the design. Colour, contrast, spacing and link text need to make it findable and understandable. At the same time, the button should not be misleadingly prominent where no right of withdrawal exists. A clear context-sensitive user flow is usually better.

Design patterns that discourage withdrawal are risky:

Do	Don’t
Clear “Withdraw from contract” link in the footer and order view	Hide the link only inside the customer account although guest orders are possible
Two-step process with clear confirmation	Immediate withdrawal after an accidental click
Optional feedback field, clearly marked as voluntary	Make the withdrawal reason mandatory
Email confirmation with content, date and time	Phrase the email as if the withdrawal had already been legally checked
Test mobile and keyboard use	Use pop-ups, overlays or confusing detours

For more background on such patterns, see the article on manipulative web design. For the withdrawal function, a simple rule applies: the way back should not feel harder than the way into the contract.

Process: How Digital Withdrawal Should Work Technically

The new function is designed as a multi-step process. The first click does not directly trigger the withdrawal. It opens a form or comparable input page. Only a second confirmation function submits the withdrawal declaration.

A reasonable flow looks like this:

1. The user clicks “Withdraw from contract”.
2. The system opens a withdrawal form.
3. The form requests only the required data.
4. The user checks the information.
5. The user clicks “Confirm withdrawal”.
6. The system records receipt with date and time.
7. The user receives a confirmation of receipt on a durable medium without undue delay, usually by email.
8. The shop passes the case to support, ERP, accounting or the returns process.

Which Data May Be Requested

Section 356a BGB names three data areas that the consumer must be able to provide or confirm:

• name of the consumer
• information to identify the contract or the relevant part of the contract, for example order number or contract number
• information on the electronic means of communication for the confirmation of receipt, usually an email address

A withdrawal reason must not be required as a mandatory field. An optional feedback field can be useful from a service perspective, but it must be clearly marked as optional. Additional fields such as phone number, customer number, IBAN or return reason should be checked critically. Data minimisation pays off twice here: it supports data protection and keeps the form lean.

Confirmation of Receipt by Email

After the click on “Confirm withdrawal”, the trader must send a confirmation of receipt on a durable medium without undue delay. In practice, email is the most obvious route. It should contain at least:

• content of the withdrawal declaration
• date and time of receipt
• information on the affected contract or contract part
• sender or company
• note that this is a confirmation of receipt

The email should not give the impression that every follow-up question has already been assessed. For some products, the shop still needs to clarify whether an exclusion applies, whether goods must be returned, whether a partial withdrawal is possible or which refund is due. The confirmation first documents receipt of the declaration.

Technical Implementation in WooCommerce, Shopify and Custom Systems

There is no single correct technical implementation. The right solution depends on how the contract is concluded in the specific system and which data is available.

In WooCommerce, an implementation may consist of several building blocks:

• permanently visible link or button in the theme
• form page for guest and customer orders
• validation of order number and email address
• selection of individual items for partial withdrawal where useful
• automated email to the consumer
• notification to shop owner or support
• separate status, note or withdrawal record
• handover to returns, refund or accounting workflow

For existing shops, a technical inventory is worth doing before implementation: Which plugins affect checkout, emails, customer account or order status? Which data is stored for guest orders? Which processes already run through ERP, inventory management or support tools? These answers determine whether an existing WooCommerce setup is enough for the withdrawal function or whether custom extensions through WordPress development make more sense.

Shopify, Shopware, Magento and other systems require different integration routes. For SaaS platforms, the question is which functions the provider supplies and where apps, theme adjustments or external forms are necessary. In custom portals, the withdrawal process should be planned as its own business process, not as a generic contact form.

Technical minimum requirements from a website perspective:

1. The function is reachable on desktop, tablet and smartphone.
2. It is keyboard-accessible.
3. Form labels, error messages and focus states are understandable.
4. Guest orders work without a customer account.
5. Email confirmation and system log contain date and time.
6. The process is protected against spam and abuse without blocking legitimate withdrawals.
7. Staging and live systems behave the same way.
8. The case can be found by support and accounting.

Accessibility should not be left as an afterthought. A legally required process that users can barely operate with a keyboard, screen reader or small display is operationally weak and conflicts with the requirements for accessible websites. If buttons, forms and error messages are being touched for the withdrawal function anyway, both topics should be handled in one workstream. For larger changes, a dedicated accessibility audit is the more honest starting point.

Update Legal Texts, Data Protection and Operational Processes

The withdrawal button is visible, but it is not the only area of work. When the digital withdrawal path is introduced, several other points need to be reviewed:

• withdrawal instructions
• terms and conditions
• privacy policy
• order confirmations
• returns and refund process
• support macros and email templates
• documentation for team, tax advisor or inventory management
• logging of receipt

The withdrawal form processes personal data. That brings the project directly into data protection: the privacy policy must reflect the actual data flow, retention periods need to be clarified and the process should fit the existing consent logic in the shop. In WordPress and WooCommerce shops, these topics are particularly closely connected because withdrawal form, order process and tracking often share the same data path.

A considered project flow therefore consists of more than development. It connects legal text updates, technical implementation, test cases, team briefing and documentation into one process. Otherwise, exactly the gaps that later appear in audits or support work remain open.

Exceptions, Edge Cases and Common Questions

Does the Obligation Also Apply on Marketplaces?

Yes, traders should check the topic even if sales run through marketplaces. In practice, technical implementation depends heavily on what the marketplace provides. Traders should still clarify whether the platform function is sufficient and how withdrawals arrive in their own process.

What About Mixed Assortments?

Many shops sell withdrawable and non-withdrawable products side by side. An example would be an assortment of standard goods, custom-made products and sealed items. If only part of the assortment can be withdrawn, it is often sensible to provide the withdrawal function and distinguish in the process which items can actually be withdrawn. The specific legal assessment should be checked.

Does the Withdrawal Button Have to Be in the Customer Account?

It may additionally be placed there, but it should not only be hidden there if contracts can also be concluded without login. For guest orders, withdrawal must remain practically possible. A public entry point using order number and email address is often more useful than a pure customer-account solution.

Is a General Contact Form Enough?

Usually no. A general form with a subject dropdown is not clear enough if users cannot recognise that they are withdrawing from the contract through it. A dedicated entry point with clear wording, defined fields and a separate confirmation is better.

What About Apps?

If the contract can be concluded through an app, the withdrawal function should also be reachable in that environment. Website and app must not drift apart. Mobile testing is therefore mandatory, especially for native apps, embedded webviews or progressive web apps.

Which Exceptions Exist?

The known list of exceptions to the right of withdrawal remains relevant. It includes, among other things, custom-made goods, perishable goods, unsealed hygiene products, sealed software after unsealing and certain leisure services with a fixed date. The details are in Section 312g BGB. For shop operators, the practical point is this: exceptions should not only exist in legal texts, but also be technically reflected in the process.

Practical Plan for Implementation Before 19 June 2026

Businesses should not wait until shortly before the deadline. Established shops in particular need time because withdrawals are connected to emails, payment methods, order statuses, inventory management and support.

A realistic plan:

1. Review contracts and products: Which offers are B2C, which include a right of withdrawal, which exceptions exist?
2. Map user paths: website, shop, app, customer account, guest order, marketplace, booking flow.
3. Obtain legal assessment: withdrawal instructions, terms and exceptions.
4. Create a technical concept: entry point, form, required fields, confirmation, email, logging.
5. Check design and accessibility: visibility, contrast, focus, mobile use, understandable errors.
6. Integrate the shop system: WooCommerce plugin, custom code, SaaS function or own interface.
7. Define email and support process: confirm receipt, assign case, handle refund and return.
8. Run test cases: guest order, customer account, partial withdrawal, exception product, mobile use, app, incorrect order number.
9. Maintain documentation: responsibilities, test log, technical changes and legal text versions.

The SEO aspect is secondary, but not irrelevant. Many users will search for terms such as withdrawal button, withdrawal function, Section 356a BGB, online shop, distance contracts or consumer law. Shops do not need to turn this into long SEO pages. A clear withdrawal page can still build trust, reduce support requests and guide searchers directly to the right function.

Conclusion: The Withdrawal Button Is a Process, Not a Single Link

The new withdrawal button strengthens consumer rights and forces online providers to map withdrawal more clearly in digital systems. For online shops, this is not just a new button. It is a coherent combination of visible entry point, unambiguous form, confirmation function, email, data minimisation, legal texts and operational handling.

Businesses that start early can reduce warning-letter risks, organise support processes and use the new mandatory element as a trust signal. Done well, the withdrawal function shows: this shop does not make rights harder than the purchase.