Withdrawal button in peak season: keep checking that it works

What Section 356a BGB actually requires

The obligation goes back to Directive (EU) 2023/2673, which requires a withdrawal function for web shops through a new Article 11a (WKO). Germany implemented it with the act amending consumer contract and insurance contract law; the act was published in the Federal Law Gazette on 5 February 2026, BGBl. 2026 I Nr. 28 (Noerr). The new Section 356a BGB has applied since 19 June 2026 (Noerr). It sits in the subtitle on the right of withdrawal in consumer contracts, right next to the rules on the withdrawal period and on information, and it addresses the interface, not the small print.

The statutory text is short, but every one of its requirements can be observed on the interface. That makes it unusually well suited to technical monitoring, because what a customer sees in the browser, an automated browser sees as well:

1. The function itself - for distance contracts concluded via an online interface, the consumer must be able to submit a withdrawal declaration there by using a withdrawal function (Section 356a(1) BGB).
2. The label - clearly legible with “Vertrag widerrufen” (withdraw from contract) or another equivalent unambiguous wording (Section 356a(1) BGB).
3. Availability - permanently available during the withdrawal period, prominently placed and easily accessible for the consumer (Section 356a(1) BGB).
4. The details - the consumer’s name, details identifying the contract and the electronic means of communication for the confirmation of receipt must be easy to provide or confirm (Section 356a(2) BGB).
5. The confirmation - a confirmation function, clearly labelled “Widerruf bestätigen” (confirm withdrawal) or with an equivalent unambiguous wording (Section 356a(3) BGB).
6. The receipt - a confirmation of receipt on a durable medium without undue delay, containing the content of the declaration and the date and time of its receipt (Section 356a(4) BGB).

Subsection 5 governs the deadline: the declaration counts as received in time if the consumer sent it via the withdrawal function before the period expired (Section 356a(5) BGB). The German consumer advice centre Verbraucherzentrale describes the procedure as a two-stage process: after clicking, a page opens on which the contract is identified, for example by order number or email address. The consumer then confirms via a further button such as “Widerruf bestätigen”, and the business sends an electronic confirmation of receipt with date and time, for example by email (Verbraucherzentrale). For monitoring, this two-stage design is the decisive point: between the first click and the binding declaration there is a state in which everything can be checked without anything being triggered.

Why peak season raises the stakes

The withdrawal period is 14 days (Section 355(2) BGB) and, for purchases of goods, usually starts when the goods are received (Verbraucherzentrale). This pushes the window in which the withdrawal function must be available beyond the purchase date: goods that arrive shortly before Christmas can still be withdrawn from well into January. For a shop that sells continuously, “permanently available during the withdrawal period” means in practice: on virtually every day, because on virtually every day some withdrawal period is running.

There is a second deadline track. The withdrawal period does not begin before the business has properly informed the consumer about the right of withdrawal (Section 356(3) BGB), and without that information the right of withdrawal expires twelve months and 14 days after the regular start of the period at the latest (Section 356(4) BGB). Both rules concern the information, not the withdrawal function itself. They do show, however, how long a right of withdrawal can remain open in case of doubt, and therefore how long the function may still be needed for older orders.

Peak season sharpens this from two directions. First, the weeks before often bring a particularly large number of interface changes: promotional banners, countdown bars, new home page modules, a theme update that is supposed to go live before the cut-off date. Second, where order volume rises, so does the number of customers who actually use the function. How much volume picks up during the season is usually shown more precisely by your own year-over-year comparison than by an industry figure; how to read it correctly despite sale days that move around the calendar is covered in the article on year-over-year reports in the fourth quarter, and the technical preparation for high load in the article on Q4 traffic peaks.

The typical failure points are unspectacular. None of them triggers a server error, and that is why none of them is noticed by a plain uptime monitor that only checks whether the home page answers with status 200:

The consequences of a gap fall into two parts. For the customer, withdrawal remains possible, because it is made by declaration to the business, and sending the withdrawal in time is sufficient to meet the deadline (Section 355(1) BGB). They simply write an email or call, and customer service has more work. For the merchant, the breach remains. The law firm Noerr expects an increase in cease-and-desist letters after the rules take effect, similar to the cancellation button under Section 312k BGB, especially as a missing implementation will be relatively easy to detect; in addition, substantial fines may be imposed in some circumstances (Noerr). For the cancellation button, which Germany introduced as early as July 2022, there is already case law (WKO). What a competitor can detect with a browser in a few clicks can just as well be detected automatically and earlier. How to reduce the risk of cease-and-desist letters more generally is summarised in the article on cease-and-desist risk for websites.

The procedure as a checkable click path

For monitoring purposes, it helps to read the statutory procedure not as a legal question but as a sequence of observable states. Each state has a feature a browser can detect and a typical failure that breaks it. The following table maps the four states to the checks and the common failure points:

The first three rows take place entirely in the browser. The fourth does not: the confirmation of receipt is an email or another message on a durable medium, and whether it arrives is decided in the mailbox, not on the page. A browser flow can secure the path up to the confirmation button; it does not check the inbox. That requires a separate check, more on this below.

Every run without a real withdrawal

This results in two variants that complement each other and together cover the whole procedure:

1. Variant A: live shop, stop before the confirmation. The flow opens the home page, checks the visibility and label of the button, clicks it, fills in the form with neutral test values and verifies that the “Widerruf bestätigen” button appears. Then it ends. If the shop validates the order number against the order management system in the first step, the flow needs a permanent order marked as a test whose number it can enter. Interval: hourly or shorter.
2. Variant B: test order or test environment, complete run. The flow additionally clicks “Widerruf bestätigen”, either against a staging environment with an identical theme or against a marked test order known to the team. The confirmation of receipt goes to a test mailbox. Interval: daily and after every deploy.

Variant A covers the availability that matters under Section 356a(1) BGB, and it runs often enough to find a gap within hours rather than weeks in most cases. Variant B covers what happens after the click: whether the confirmation is accepted, whether the shop throws an error and whether the receipt email is generated. Because deploys are a typical cause of broken click paths, variant B belongs directly after every release; how this interacts with a rollback is described in the article on deploys as an outage cause. With “Run now”, a monitor can be marked as due; the next cron tick, which runs every minute, then executes it without waiting for the next interval (XICTRAQ documentation).

Neutral test values have a welcome side effect: if a record with the name “Prüflauf Monitoring” ever does show up in the list of withdrawals, it is immediately clear where it came from. The test address should point to a domain that belongs to nobody, so that no confirmation of receipt ends up in someone else’s mailbox if the flow does go too far.

The flow in browser monitoring

In XICTRAQ browser monitoring, multi-step flows run in a real Chromium browser; if a step fails, you get an alert and a failure screenshot with the exact step number and error message (XICTRAQ documentation). A scenario comprises up to 40 steps, the interval is between 5 minutes and 24 hours, a single step may take at most 60 seconds, and the entire run is hard-stopped after 90 seconds (XICTRAQ documentation). The withdrawal path needs only a fraction of that. The step types and the scenario format are described in the browser monitoring documentation; as a scenario, variant A looks roughly like this:

{
  "name": "Withdrawal function live (stop before confirmation)",
  "viewport": { "width": 1280, "height": 800 },
  "timeout_ms": 20000,
  "step_retry": 1,
  "steps": [
    { "type": "goto", "url": "https://shop.example.invalid/" },
    { "type": "assert_visible", "selector": "footer a[href$='/vertrag-widerrufen']" },
    { "type": "assert_text", "selector": "footer a[href$='/vertrag-widerrufen']", "contains": "Vertrag widerrufen" },
    { "type": "click", "selector": "footer a[href$='/vertrag-widerrufen']" },
    { "type": "wait_for", "selector": "form#widerruf" },
    { "type": "fill", "selector": "#widerruf-name", "value": "Prüflauf Monitoring" },
    { "type": "fill", "selector": "#widerruf-bestellnummer", "value": "TEST-0000" },
    { "type": "fill", "selector": "#widerruf-email", "value": "pruefung@example.invalid" },
    { "type": "click", "selector": "form#widerruf button.weiter" },
    { "type": "wait_for", "selector": "button#widerruf-bestaetigen" },
    { "type": "assert_text", "selector": "button#widerruf-bestaetigen", "contains": "Widerruf bestätigen" },
    { "type": "screenshot", "full_page": true }
  ]
}

Three details make the difference. The assert_text step on the label reports a silent renaming that a pure click test would miss. The assert_visible step fails if the link has been hidden or removed; if a promotional element sits on top of it, the subsequent click usually fails, and the failure screenshot shows what was in the way. And the flow ends with the screenshot, not with a click on “Widerruf bestätigen”. If the details and the confirmation are on the same page, the click on “Weiter” (continue) is omitted.

Beyond the basic scenario, the following points belong in the setup:

• Home page and at least one category or product page as entry points, because promotional elements often appear only there
• A second monitor with a narrow mobile viewport, because footer and menu are structured differently there
• Checking the label with assert_text rather than only the existence of the link
• In variant B: the form can be submitted without giving a reason
• No login between the button and the form
• A screenshot at the end of every run as a dated record

The consent layer deserves a closer look. A browser flow without a stored consent sees the same consent prompt as a new visitor. If it covers the footer, the flow has to dismiss it just like a customer, and if that no longer works after a configuration change, that is a real finding. How to monitor changes to the consent layer and the loaded tags is shown in the article on consent and tag drift.

Dated captures as evidence of permanent availability

“Permanently available” is a statement about a period of time, and a period can only be documented with data points. Browser monitoring stores every run with its total duration, result and per-step results; the overview shows the last 50 runs per monitor (XICTRAQ documentation). At an hourly interval, that is roughly two days of history at a glance. On every failed step, a screenshot is also taken automatically at the moment of failure and stored in the run history (XICTRAQ documentation). This documents the moment of the break, not just the fact that something broke.

For longer periods, visual diff with screenshot changelog complements the flow. It takes captures of the page at regular intervals, in desktop, tablet and mobile view, automatically dismisses or hides cookie and consent banners and captures the entire page including the footer and lazy-loaded elements (XICTRAQ). Retention depends on the plan and ranges from 7 to 180 days (XICTRAQ documentation). For the withdrawal function this means: depending on the interval, the footer with the “Vertrag widerrufen” link is available as a dated capture in three device sizes. Hiding the banners is intended for documenting the placement; whether a layer covers the link for real visitors is checked by the browser flow.

For large deviations above 20 %, visual diff notifies you immediately; in addition, it extracts the text content and shows changes as a text diff (XICTRAQ). A renamed label is a tiny change for a pixel comparison, but a clear line in the text diff: “Vertrag widerrufen” is missing, “Service” is new. It is precisely this combination that catches the quiet cases in which the page looks almost the same.

Such captures do not replace a legal assessment. But they answer the question that is asked first in a cease-and-desist letter or a dispute with a customer: was the button there on that day, and what did it look like? Anyone who wants to use monitoring as evidence should treat the captures like a test report for the burden of proof: with fixed intervals, stored unchanged and clearly attributable to the monitor. The same logic applies to evidence for insurers, as the article on website evidence for cyber insurance shows.

Alerting: who responds when the path breaks

A failure in browser monitoring creates an alert of type browser_monitor_failed with severity critical (XICTRAQ documentation). Ten-minute deduplication, ACK link, escalation via the default policy and postmortem export work the same way as for a normal uptime alert, and when the flow turns green again, XICTRAQ closes the alert automatically (XICTRAQ documentation). Via alerting with escalation, the notification goes by email, chat or webhook to the people who can actually fix the footer.

More important than the channel is responsibility. A broken withdrawal function is, as a rule, not a server problem but a change to the template, consent layer or form. A short chain helps:

1. The alert goes to the person responsible for the shop interface and theme, not to the hosting on-call service.
2. They open the failure screenshot and read the step number: step 2 or 4 means the link is missing or covered, step 5 means the form does not load, step 11 means the label of the confirmation has changed.
3. If the cause lies in a change made in the last few hours, that change is reverted before a lengthy search for the cause begins.
4. With “Run now”, the flow is repeated at the next cron tick without waiting for the interval; if the alert closes, the path is clear again.
5. The legal department or the advising law firm learns of every gap that lasted longer than one working day, with the period and screenshots.

Planned work on the shop where the path will predictably break belongs in a maintenance window so that the alert does not become routine. How to set such windows without swallowing real outages is described in the article on maintenance windows and false alerts. One caveat applies: the obligation under Section 356a BGB does not pause during maintenance. A window suppresses the alert, not the requirement, and the work should be kept correspondingly short.

Austria: Section 13a FAGG since 1 October 2026

Anyone who also sells to Austria has recently had a second, largely identical obligation. The Austrian implementation was published in the Federal Law Gazette on 28 July 2026, takes effect on 1 October 2026 and applies to contracts concluded after 30 September 2026 (WKO). Under Section 13a(2) FAGG, the withdrawal function must be clearly labelled “Vertrag widerrufen” or with a corresponding unambiguous wording, be continuously available during the entire withdrawal period and be placed prominently and easily accessible (WKO). The withdrawal period of 14 days under Section 11 FAGG remains unchanged (WKO).

One question is expressly open there: whether the button only has to be available during the individual withdrawal period of each consumer or may be available permanently is, according to the WKO, not settled (WKO). For monitoring, this hardly matters. A permanently visible button is in practice the simpler implementation, and a flow that checks it only needs a second entry URL for the Austrian shop. Several monitors per website are intended, typically one for login, one for checkout and one for the contact form, all configurable independently (XICTRAQ documentation).

Checklist before peak season

The following points can be worked through before the promotional weeks start. They do not replace a legal review of the implementation, but they help ensure that a reviewed implementation is still the same in December:

• Label “Vertrag widerrufen” or equivalent, clearly legible, on all page types in the footer or header
• No promotional element, pop-up or consent layer that permanently covers the link on mobile or desktop
• Form reachable without login, without a mandatory field for a reason
• “Widerruf bestätigen” button present after the details and clearly legible
• Variant A as a browser flow in the live shop, hourly, stop before the confirmation
• Variant B against a test environment or test order, daily and after every deploy
• Separate mailbox script with heartbeat for the confirmation of receipt including date and time
• Visual diff on the home page and the withdrawal page, alert path with named responsibility

If you set up the flow not only for the withdrawal function but also for checkout, sign-in and the contact form, you will find the basics in the article on synthetic checks for critical flows. And because load also rises during peak season: a flow that suddenly becomes much slower can be an early sign of an exhausted worker pool, long before error pages appear. More on this in the article on worker pool exhaustion.