The withdrawal button: build it, test it, log it

The withdrawal button comes from European law. Directive 2023/2673 amended the Consumer Rights Directive and inserted a new Article 11a (Directive 2023/2673) governing the exercise of the right of withdrawal for distance contracts concluded through an online interface. The occasion was the distance marketing of financial services. The new provision was not placed in a special section, though, but in the general part of the Consumer Rights Directive. Member States apply the rules from 19 June 2026 (Directive 2023/2673). In Germany the transposition sits in section 356a BGB, headed Electronic withdrawal function for distance contracts (BGB § 356a). Anyone deriving the scope from the legislative history therefore ends up wrong: the German text contains no restriction to financial services.

The core of the provision sits in paragraph 1. The trader has to make sure the consumer can submit a withdrawal declaration through a withdrawal function on the online interface. The function has to be legibly labelled Vertrag widerrufen (BGB § 356a) or with another equally clear wording of the same meaning. And while the withdrawal period runs it has to be continuously available (BGB § 356a), placed prominently and easy to reach. Those are three requirements with little in common: a label, a placement and an availability across a span of time. The theme handles the first two. The third is a statement about operations – and therefore the actual maintenance task. The article on legal text maintenance does not help here: that one is about text, this one is about an order flow.

The provision describes a flow, not a button. The first stage is the withdrawal function itself. It has to let the consumer transmit a withdrawal declaration and, in doing so, provide or confirm three items (BGB § 356a) without further ado: the name, details identifying the contract or the part of the contract to be withdrawn, and details of the electronic means of communication through which the acknowledgement of receipt is to arrive. The phrase without further ado is the real requirement here. Forcing logged-in customers to copy an order number out of an invoice in PDF format satisfies the wording in form only. Where the details are already known, they belong in the form, pre-filled and confirmable.

The second stage is the confirmation. Once the details are provided or confirmed, the trader has to let the declaration and the details be transmitted through a confirmation function. That function has to be legibly labelled Widerruf bestätigen (BGB § 356a) or with another equally clear wording of the same meaning. Two stages mean two states that can break separately: the first stage can be perfectly reachable while the second fails on an expired form token. That case in particular escapes a superficial glance at the page. The control is visible; whether the dispatch path behind it holds only shows in a full run with a real contract.

What the function does not have to ask for matters as much for the audit as what it does. The statute names three items, and the withdrawal declaration itself does not have to contain a reason (BGB § 355). Building in a mandatory field for the reason makes it harder to exercise a right whose exercise was meant to be made easier. The same goes for a forced login where the contract was concluded as a guest: there the path runs through an access key in the order confirmation, not through an account that was not created. As a rule of thumb for the audit: anything standing between customer and dispatch that does not come from the statute needs a reason – or goes. Our services start exactly at that point.

Alongside the new function, the familiar law on periods is unchanged, and that is precisely what gets lost in the excitement about the button. The withdrawal period is 14 days (BGB § 355). In a consumer sale it does not start at conclusion of the contract but once the consumer or a third party named by them, other than the carrier, has received the goods; with separate deliveries the last item counts, with part shipments the last part, and with regular delivery the first item (BGB § 356). For maintenance that is not a legal nicety but the basis of the audit rhythm: the period determines how long the withdrawal function has to stay reachable for a specific order.

Two further periods belong with it. Without proper instruction the right of withdrawal expires only after twelve months and 14 days (BGB § 356) – a span that can hold three shop updates and two theme changes. And the payments received are to be reimbursed no later than 14 days (BGB § 357), whereby in a consumer sale the trader may refuse reimbursement until the goods are back or their dispatch is evidenced. The model withdrawal form on the website remains permissible alongside (BGB § 356); the new function is added to it rather than replacing it. Anyone maintaining their legal texts therefore keeps both paths in view.

The audit rhythm follows from these periods on its own. A function that still has to hold twelve months after an order does not tolerate an annual visual check. What makes sense is a daily automatic run for reachability and label, a monthly run with real dispatch against a test contract, and an additional run after every update touching theme, customer account or dispatch path. The effort for that stays modest as long as it sits inside an existing maintenance routine – and gets unpleasantly high when it is caught up on only after a warning letter.

The withdrawal function sits at one of the most mobile spots in the shop. It depends on the theme, because the control and its label are rendered there. It depends on the customer account, because the contract reference comes from there. It depends on form processing, because the second stage needs a valid token. And it depends on the dispatch path, because the acknowledgement leaves the shop. An update can loosen any of those connections without producing an error page. Translation gaps are particularly inconspicuous: if the key for the label is missing, the interface shows the technical placeholder in the second language – a control, in other words, that is no longer legibly labelled. How to track down such gaps is covered in the article on translation gaps in the shop.

These patterns have one thing in common: they arise on a change, not in steady operation. That is why the withdrawal flow belongs in the regression test after every update, and why it belongs on the practice environment beforehand. A run on staging costs minutes; the same run on the production system costs a real contract. How to build regression tests after updates is described in the article on update testing. Two additions matter: the test has to check the label word for word and not merely the existence of a control. And it has to actually submit the second stage, because otherwise precisely the part most likely to break stays out of view.

That leaves the evidence. Because receipt counts from timely dispatch onwards, what decides a dispute is what the operator can say about that moment. A lean log makes sense: contract number, moment of dispatch in server time including the time zone, the three transmitted details, the dispatch time of the acknowledgement and its recipient address. Those entries are personal data and therefore need retention limits and access rules of the kind described in the article on GDPR-compliant backup retention. The withdrawal flow likewise belongs in the regular check of operability: a control that cannot be reached with the keyboard is not easy to reach – a point the article on shop accessibility explores further. In day-to-day operation that is handled by Shopware maintenance, together with monitoring of the order flow.