Order button under § 312j BGB: keep checking the label

What § 312j BGB requires of the final button

The provision sets out several duties, all of which surface in checkout. Subsection 3, sentence 1 requires the ordering situation to be designed so that the consumer expressly confirms, with the order, that they are committing to a payment (§ 312j(3) BGB). Sentence 2 turns this into a concrete requirement for the button, and that sentence is the yardstick for everything checked in this post (unofficial translation):

If the order is placed via a button, the trader’s duty under sentence 1 is only fulfilled if this button is labeled in an easily legible manner with nothing other than the words “zahlungspflichtig bestellen” or with a corresponding unambiguous wording.

— § 312j(3), sentence 2 BGB

The legal consequence follows one subsection later and is unusually clear: a contract is only formed if the trader fulfills the duty under subsection 3 (§ 312j(4) BGB). The provision implements Article 8(2) of the EU Consumer Rights Directive, which states that the consumer is not bound by the contract or order if the trader does not comply with the labeling duty (Directive 2011/83/EU). For operations, this means that a wrongly labeled button affects the formation of every order placed through it; the consequences in an individual case are for legal counsel to assess.

Two further subsections concern the same checkout. Immediately before the consumer places the order, certain mandatory information must be provided clearly, comprehensibly and in a prominent manner (§ 312j(2) BGB). This includes the main characteristics of the goods, the total price including all taxes and charges, any freight, delivery or shipping costs, for subscriptions the total price per billing period, and the term and minimum duration of the commitment (Art. 246a § 1 EGBGB). At the latest when the ordering process begins, the shop must also state clearly whether delivery restrictions apply and which means of payment are accepted (§ 312j(1) BGB).

The labeling duty itself is not new. The so-called button rule took effect on August 1, 2012 (vzbv), back then under a different section number. The sentence on the button already appeared in its current wording in the federal government’s draft bill (Bundestag printed paper 17/7745). Precisely because the rule is so old, it easily looks done. It is only done for the state that was live when someone last checked.

Which labels work and which do not

The statute names only one example; the explanatory memorandum to the 2011 draft bill says more. According to it, unclear labels such as “Anmeldung” (sign-up) or “weiter” (continue) do not meet the requirements (Bundestag printed paper 17/7745). Wordings such as “bestellen” (order) or “Bestellung abgeben” (submit order) are regularly not suitable either, because free services such as a newsletter or a product sample can also be “ordered” online (Bundestag printed paper 17/7745). As unmistakable, it names labels such as “kostenpflichtig bestellen” (order subject to charge), “zahlungspflichtigen Vertrag schließen” (conclude a contract with obligation to pay) or “kaufen” (buy) (Bundestag printed paper 17/7745).

Besides the wording, the button must not carry any additions, so that the consumer is not distracted from the decisive information (Bundestag printed paper 17/7745). Moreover, any graphical control that triggers the order counts as a button, explicitly including a link or a checkbox (Bundestag printed paper 17/7745).

In 2022 the Court of Justice of the European Union answered a reference from Germany about a hotel booking made with a button labeled “Buchung abschließen” (complete booking). To decide whether a wording corresponds to “zahlungspflichtig bestellen”, only the words on the button count, not the circumstances of the ordering process (CJEU, C-249/21). Whether “Buchung abschließen” was sufficient was for the referring court to examine: if “Buchung” is not necessarily associated with an obligation to pay in everyday language, the wording is ambiguous (CJEU, C-249/21). Under this interpretation, a notice above the button, a price summary next to it or the terms and conditions cannot make up for an unclear label.

The table is not an invitation to invent variants: the target text for the check is the label your shop uses after legal review, usually the wording of the statute. If you are reviewing your website for typical grounds for cease-and-desist letters anyway, the checklist against cease-and-desist risk lists further candidates.

Why the label flips after an update

In the standard Shopware 6 storefront, the label is not hard-coded in the template but comes from the text snippet checkout.confirmSubmit, whose default value in the German base set is “Zahlungspflichtig bestellen”. Shopware uses text snippets to translate and customize texts, which can be edited in the administration under Settings, Shop, Snippets (Shopware documentation). Other shop systems use language files in the same way. That leaves several places where the text can change without anyone deliberately touching checkout:

• Theme updates: A theme can override the block containing the order button, page_checkout_confirm_form_submit in the Shopware storefront. If a new theme version ships its own texts or text keys, its default ends up on the button.
• Extensions: Payment and checkout plugins add their own buttons to checkout or replace the standard one. If such a button triggers the order, the same requirement applies to it.
• Language packs: An update to the language files delivers new default texts; a label customized directly in a file rather than in the administration may be gone afterwards.
• Additional sales channels and languages: A second channel, for Austria for example, or a second language uses its own snippet sets. What is correct in the main shop is not automatically correct there.
• Campaigns and tests: A variant reading “Jetzt sichern” (grab it now) or an addition such as “and save” quickly collides with the rule that the button must carry no further additions.
• Styling: A new stylesheet shrinks the font, lowers the contrast or truncates the text with an ellipsis on narrow screens.

The weeks before Black Friday are especially sensitive. Themes, extensions and campaign pages are updated right before the rush, and that is exactly when demand arrives: roughly one in two, 52 percent of internet users aged 16 and over, planned to use the reduced prices of Black Friday and Cyber Week in fall 2025 (Bitkom). Of these shoppers, 69 percent planned to look for deals exclusively online (Bitkom). Every order placed through a wrongly labeled button during those days carries the same problem.

Why uptime checks and release tests do not cover this

An uptime check does not see the order review page at all. Uptime checks the HTTP response of the homepage, while browser monitoring clicks through a complete flow like a user (XICTRAQ® documentation). The order review page only exists with customer data and a filled cart; a plain request to its address typically ends up in the cart or on the login page. The difference is covered in Browser monitoring: when uptime is green but checkout is broken.

A clean test before the release is not enough either: it checks the approved state, not the one that is live weeks later after a plugin update or a change to a text snippet. How deploy errors surface in general and how to roll them back is described in Deploy errors as a cause of outages.

The label as a browser check

In XICTRAQ® browser monitoring, multi-step flows such as login, checkout or forms run in a real Chromium browser (XICTRAQ® documentation). A scenario can have up to 40 steps, and the interval ranges from 5 minutes to 24 hours (XICTRAQ® documentation). The label needs only a fraction of that: log in, put a test product in the cart, open the order review page and compare the button text.

The decisive step is assert_text. It requires the text of a selector to contain a substring or to be exactly equal (XICTRAQ® documentation). For the order button, the exact comparison with equals is the right fit: a contains on “bestellen” would also accept “Jetzt bestellen” (order now), a label the explanatory memorandum regards as regularly unsuitable. An equals on “Zahlungspflichtig bestellen”, by contrast, fails on any deviation. The runner only strips whitespace at the beginning and end of the text it finds and compares the rest character by character, including upper and lower case.

{
  "name": "Order button § 312j, stop before the click",
  "viewport": { "width": 1280, "height": 800 },
  "timeout_ms": 20000,
  "step_retry": 1,
  "steps": [
    { "type": "goto", "url": "https://shop.example.invalid/account/login" },
    { "type": "fill", "selector": "#login-email", "value": "monitoring@shop.example.invalid" },
    { "type": "fill", "selector": "#login-password", "value": "***" },
    { "type": "click", "selector": "form.login-form button[type=submit]" },
    { "type": "wait_for", "selector": ".account-welcome" },
    { "type": "goto", "url": "https://shop.example.invalid/testartikel-monitoring" },
    { "type": "click", "selector": ".buy-widget button[type=submit]" },
    { "type": "goto", "url": "https://shop.example.invalid/checkout/confirm" },
    { "type": "assert_visible", "selector": "#confirmFormSubmit" },
    { "type": "assert_text", "selector": "#confirmFormSubmit", "equals": "Zahlungspflichtig bestellen" },
    { "type": "screenshot" }
  ]
}

Addresses, login selectors and the test product are placeholders. The selector #confirmFormSubmit is the ID of the order button in the standard Shopware 6 storefront; if a theme changes it, use the theme’s selector instead. The assert_visible step before it makes sure the button is visible. The last step takes a screenshot that is shown in the run detail (XICTRAQ® documentation), so each run usually produces a dated image of the order review page. All step types are listed in the browser monitoring documentation.

The run stops before the click

The check reads the label; it does not use the button. A click on “Zahlungspflichtig bestellen” in the live shop would create a real order on every run, with order confirmation, stock booking and invoice. The Shopware monitoring page therefore recommends letting browser checks end on the order review page and logging in with a dedicated test customer (XICTRAQ®). For the test setup:

• A dedicated test customer instead of a real customer account. XICTRAQ® stores the field values of fill and type steps, such as passwords, encrypted and does not show them again in the editor (XICTRAQ® documentation).
• A test product that stays in stock permanently and appears in no promotion.
• A simple payment method such as prepayment as the test customer’s default, so that no payment interface interferes with the path to the order review page.
• No click on the order button in the scenario. A full order test with payment belongs in a test environment, not in the live shop.

The login step is covered in Monitor the login flow. Your own statistics stay clean too: the runner blocks the XICTRAQ® tracker so that synthetic runs do not create test page views (XICTRAQ® documentation). The same setup for promo codes is shown in Test discount code redemption with a browser check.

Check subsections 1 and 2 in the same run

On the order review page, more than the label can be checked. Subsection 2 requires the mandatory information immediately before the order. An additional assert_text on the order total line, with contains on the text your shop uses there, for example “inkl. MwSt.” (incl. VAT), shows whether the total price including taxes is still in place. For subscriptions, add a step for the term and cancellation notice, because the mandatory information also covers the term and minimum duration (Art. 246a § 1 EGBGB).

Subsection 1 concerns the start of the ordering process: delivery restrictions and accepted means of payment must be stated clearly at the latest by then (§ 312j(1) BGB). For 54 percent of online shoppers, payment options are very important when choosing a shop, and for 53 percent, shipping and delivery are (Bitkom). An assert_visible step on the payment method block in the cart or an assert_text on the note about delivery countries covers this. Where buyers drop off at the payment method is shown in Analyzing payment methods.

The shop must also provide technical means that allow customers to identify and correct input errors before placing the order (§ 312i BGB). An assert_visible on the link for changing the address or payment method checks that this path still exists after an update. For all extra steps, a single step may take at most 60 seconds, and the whole run is aborted after 90 seconds (XICTRAQ® documentation).

Easily legible: what the text comparison does not see

assert_text compares the text in the document, not how it is displayed. If a stylesheet truncates the label on a smartphone to “Zahlungspflichtig be…”, shrinks the font or drains the button’s contrast, the text in the source remains the same and the check stays green. Yet that is exactly what the “easily legible” requirement is meant to prevent: the explanatory memorandum explicitly mentions a particularly small font and a low-contrast design such as dark red text on a red background (Bundestag printed paper 17/7745).

1. An image at the end of every run: The screenshot step records what the button actually looked like, with a date. If the run stops earlier, the failure screenshot automatically captures the moment of the failure.
2. A second monitor at smartphone width: The viewport can be set per scenario; the default is 1280 × 800 pixels (XICTRAQ® documentation). For many customers the mobile view is the real one: 73 percent of online shoppers use a smartphone for shopping (Bitkom).
3. Contrast with a number: WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text (W3C). That is not an interpretation of § 312j, but a verifiable yardstick for legibility.

How regressions in contrast and legibility surface after a deploy is described in Accessibility monitoring: WCAG regressions after deploys. For public pages such as product pages with payment and shipping notes, the screenshot changelog complements the browser check: it compares captures pixel by pixel and shows changes in a chronological overview with a before/after view (XICTRAQ®).

When the check fires

If the label differs, the run stops at that step: XICTRAQ® automatically takes a screenshot at the moment of the failure (XICTRAQ® documentation) and records the index of the failed step and an error message (XICTRAQ® documentation). For the text comparison, the message names the text found and the expected text, for example “Weiter” instead of “Zahlungspflichtig bestellen”. The failure creates an alert with severity critical (XICTRAQ® documentation), delivered through the configured notification channels. Whether it reaches the right person at night can be rehearsed in advance, as shown in Testing the alerting chain.

1. Look at the screenshot: Is there a different text on the button, or is the button missing because the page is no longer the order review page?
2. Compare recent changes: Theme, plugin and language pack updates from the last few days and changes to text snippets. In the German Shopware administration, the filter “Nur angepasste Textbausteine anzeigen” (show only customized snippets) lists the snippets that were edited there (Shopware documentation).
3. Restore the label: Correct the snippet or roll back the update, clear the cache and trigger the monitor with “Run now”. The next cron tick, every minute, then runs it without waiting for the interval (XICTRAQ® documentation).
4. Record the time window: The overview shows the last 50 runs per monitor (XICTRAQ® documentation); together with the time of the alert, this shows since when the wrong text was live at the latest. Whether orders from that window need special handling is for legal counsel to assess.

Once the run is green again, XICTRAQ® closes the alert automatically (XICTRAQ® documentation). The screenshot from the first green run after the fix is at the same time the record of when the label was correct again.

Interval, timing and multiple channels

The dashboard offers intervals of 5, 15, 30, 60, 180 and 720 minutes (XICTRAQ®). In the weeks before and during Black Week and Cyber Week a short interval makes sense, because updates and campaigns follow each other closely; outside that period an hourly run is usually enough. More important than the interval is a “Run now” directly after every change.

If you run several sales channels or languages, create one monitor per channel with the target text valid there. Browser monitoring is included from the Business plan (XICTRAQ® documentation); scope and terms are on the pricing page.

Checklist before Black Week

• Define the target label and agree it with legal counsel, usually “Zahlungspflichtig bestellen”.
• With a test customer, a test product and a simple payment method, build the browser check up to the order review page: assert_visible and assert_text with equals on the order button, screenshot at the end, no click on the button.
• Add extra steps for the total price, shipping costs, payment methods and the link for changing entries.
• Create a second monitor at smartphone width and a separate one for each additional channel or language.
• List express buttons and order paths of payment extensions and, where they trigger the order, check them too.
• Clarify the alerting path: who receives the alert, and who is allowed to change text snippets or the theme?

The label belongs in day-to-day operations

The risk does not lie in the rule itself but in the updates that follow. A browser check that compares the label exactly, stops before the click, alerts on any deviation and records the state in a screenshot turns an assumption into a measurement. It does not replace a legal review, but it shows whether the reviewed wording is still on the button after the next update.

The same logic now applies in the opposite direction: the withdrawal function must be labeled in an easily legible way with “Vertrag widerrufen” (withdraw from contract) or an equivalent unambiguous wording (§ 356a BGB). How this function can be checked continuously with the same tool is described in Withdrawal button in the holiday season. You set up the order button check itself in browser monitoring.