Am 19. Juni 2026 ändert sich für jeden B2C-Online-Shop in der EU eine Kleinigkeit, die schnell groß wird: Die Richtlinie (EU) 2023/2673 verpflichtet alle Händler, eine Ein-Klick-Widerrufs-Funktion bereitzustellen. Kein PDF-Formular in den AGB. Kein „Bitte schicken Sie eine Mail an widerruf@…”. Eine echte Funktion im Shop. In Magento 2 ist diese Funktion nirgends enthalten — weder in Open Source noch in Adobe Commerce. In diesem Artikel zeigen wir, was die Richtlinie konkret verlangt, woran kostenlose Marktplatz-Module rechtlich knapp werden, und wie wir das Problem in einem eigenen Magento-Modul sauber gelöst haben.
Was die Richtlinie konkret vorschreibt
Die EU-Richtlinie 2023/2673 erweitert die Verbraucherrechte-Richtlinie um genau einen Punkt: Wer Waren oder Dienstleistungen an Verbraucher online verkauft, muss ihnen eine „Widerrufsfunktion” an die Hand geben — eine Funktion auf der Shop-Webseite, mit der der Widerruf per Klick erklärt werden kann.
Betroffen ist jeder, der in die EU verkauft. Das gilt unabhängig vom Sitz des Händlers: Ein US-amerikanischer Shop, der Bestellungen aus Wien annimmt, muss die Funktion genauso anbieten wie ein österreichischer Mode-Händler.
Was die Funktion mindestens leisten muss:
- Sie muss vom Verbraucher direkt im Shop ausgelöst werden können
- Sie muss alle Pflichtangaben des Widerrufs abfragen (Bestellung, Erklärung, optional Begründung)
- Der Verbraucher muss sofort eine Empfangsbestätigung auf einem dauerhaften Datenträger bekommen — in der Praxis: per E-Mail
- Die Frist von 14 Tagen ab Erhalt der Ware muss korrekt berechnet werden
Was definitiv nicht mehr reicht: Ein Mustertext im Footer. Ein PDF zum Download. Ein „Widerruf”-Punkt im AGB-Menü. Eine Mail-Adresse zur Kontaktaufnahme. All das ist Information — keine Funktion.
Was Standard-Magento liefert — und was fehlt
Wer jetzt in Magento 2 nach einer Widerruf-Funktion sucht, findet: nichts. Magento Open Source bringt sie nicht mit. Adobe Commerce auch nicht. Das Standard-Bordmittel der meisten Shops für das Thema ist eine CMS-Page mit der Widerrufsbelehrung und einem ausdruckbaren Formular. Das war pre-2023/2673 ausreichend. Ab Juni 2026 ist es das nicht mehr.
Im Magento-Marketplace gibt es einzelne kostenlose Module, die das Thema adressieren — aber meistens nur in der oberflächlichen Variante: ein Formular im Customer-Account, das eine E-Mail an den Shop-Betreiber schickt. Für die Konformität reicht das nicht aus. Drei Dinge fehlen praktisch immer: ein sicherer Gast-Flow, eine belastbare Fristberechnung und ein Statusworkflow im Admin-Bereich.
Wo gratis-Module rechtlich knapp werden
Wir haben uns die gängigste freie Open-Source-Alternative im Magento-Umfeld angeschaut, bevor wir das eigene Modul gebaut haben. Das war lehrreich, vor allem an den Stellen, an denen es um Privacy, Frist und Audit geht.
Privacy-Boundary im Gast-Widerruf
Wenn ein Gast — also jemand ohne Magento-Customer-Account — widerrufen will, muss er sich identifizieren. Manche Module lösen das so: Du gibst Bestellnummer und E-Mail-Adresse ein, und wenn beides passt, schickt der Shop dir die Widerrufs-Bestätigung mit Name und Bestellliste zu. Klingt praktisch.
Das Problem: Die E-Mail-Adresse, die du eingibst, gehört nicht zwingend dem Besteller. Tippfehler, böswillige Anfragen, automatisierte Scraper — am anderen Ende der Mail steht potenziell eine falsche Person und liest die Bestelldetails einer fremden Bestellung. Das ist ein klassischer Datenleak, der eine DSGVO-Meldung an die Datenschutzbehörde nach sich ziehen kann.
Der sauberere Weg: Die erste E-Mail enthält nur einen Token-Link, keine Bestelldaten. Erst wenn der Empfänger den Link klickt — also nachweist, dass er Zugriff auf das Postfach hat — wird die eigentliche Widerrufs-Erklärung verarbeitet. Double-Opt-In wie beim Newsletter, nur ernsthafter.
Brute-Force-Endpoint, der den Shop lahmlegt
Der zweite Punkt, an dem gratis-Module schmerzhaft sind, ist dieselbe Suche aus dem Privacy-Thema — nur aus der Verfügbarkeits-Perspektive. Der Endpoint „Bestellnummer + E-Mail → Order finden” liegt bei den freien Modulen public und ungeschützt im Frontend. Ohne reCAPTCHA, ohne Rate-Limiting, ohne Captcha-Cooldown. Das ist ein Geschenk für jedes Skript-Kiddie: ein paar tausend Requests pro Sekunde gegen den Widerrufs-Endpoint, und der Shop steht — entweder weil PHP-FPM ausgeht, weil MySQL die zugehörige sales_order-Lookup-Query nicht mehr stemmt oder weil eine WAF/CDN-Regel den Bot mit dem regulären Traffic blockiert.
Anders gesagt: Ein bisher harmloser Compliance-Endpoint wird zu einem DDoS-Vektor. Wir schützen den Endpoint im CopeX-Modul mit serverseitig validiertem reCAPTCHA v3 plus Request-Throttling — und gehen davon aus, dass jedes Modul ohne diese Schutzschicht in den ersten Wochen nach dem 19. Juni 2026 sehr viel Aufmerksamkeit bekommen wird.
Frist-Logik mit Versandzeit-Puffer und Grace Period
Die 14-Tage-Frist beginnt mit dem Erhalt der Ware, nicht mit dem Bestelldatum. Magento weiß nicht, wann der Kunde die Ware bekommt — die Versandbestätigung ist das Späteste, was im System landet.
Viele Module rechnen deshalb stur: Versanddatum + 14 Tage = Frist. Das ist zu eng. Wenn das Paket drei Tage zum Kunden braucht (Speditions-Auslieferung, Wochenende, Auslandsversand), verkürzt sich seine Widerrufsfrist effektiv auf 11 Tage. Lehnt der Shop dann am Tag 13 nach Versand einen Widerruf ab, ist das rechtlich angreifbar — der Kunde hat formal noch Frist.
Sauber wird es so:
- Versanddatum (aus dem letzten Shipment der Bestellung)
- plus erwartete Lieferzeit (z.B. 3 Tage, konfigurierbar)
- plus 14 Tage Widerrufsfrist
- plus Grace Period (z.B. weitere 3 Tage) als Puffer für nachgelagerte manuelle Beurteilung
Anträge, die innerhalb der Grace Period eingehen, gehen nicht in „expired”, sondern in den Status Needs Validation — der Operator entscheidet manuell, ob noch fristgerecht oder nicht. Diese Großzügigkeit kostet praktisch nichts und schützt vor rechtlichen Auseinandersetzungen mit Kunden, die unverschuldet knapp dran sind.
Status-Lifecycle und Audit-Trail
„Wir haben Ihren Widerruf erhalten” ist nicht dasselbe wie „Wir akzeptieren Ihren Widerruf”. Das ist eine Unterscheidung, die juristisch wichtig ist und die in Modulen oft fehlt. Im Standard-Fall ist beides eine einzige E-Mail, eine einzige Status-Änderung — und im Streitfall lässt sich nicht mehr nachweisen, wann der Shop die Erklärung eigentlich anerkannt hat.
Sauber ist ein Lifecycle in vier Schritten: Awaiting Confirmation (Gast-Antrag, Token verschickt) → Pending (vom Kunden bestätigt, beim Operator zur Bearbeitung) → Confirmed oder Rejected (operative Entscheidung mit Order-History-Notiz). Bei jeder Statusänderung wird im Magento-Order-Log eine Notiz hinterlegt, damit später nachvollziehbar ist, wer wann was entschieden hat.
Feature-Vergleich
| Anforderung | Gratis-Open-Source-Modul | CopeX-Modul |
|---|---|---|
| Double-Opt-In für Gast-Widerruf | Bestellnummer + E-Mail genügt | Token-E-Mail mit Ablauf |
| reCAPTCHA serverseitig | Fehlt | Ja |
| Angriffspotential auf den Such-Endpoint | Groß (public, ungeschützt — DoS-Vektor) | Gering (reCAPTCHA + Throttling) |
| E-Mail in URL-Parameter | Im Klartext (Privacy-Risiko) | Token-only |
| Versandzeit-Puffer in Fristberechnung | Fehlt | Konfigurierbar |
| Grace Period nach 14-Tage-Frist | Hartes „expired” | Needs Validation für manuellen Review |
| Widerrufsgrund auditfest gespeichert | Fehlt | Code + Label-Snapshot, store-view-übersetzbar |
| Cron-Cleanup abgelaufener Tokens | Fehlt | Daily |
| Hyvä-Kompatibilität | Meist nicht vorhanden | Ja |
| MageSuite-Anleitung | Fehlt | Schritt-für-Schritt-Doku |
| Unit-Tests / E2E | Keine | Mehr als 50 Unit-Tests + E2E-Tests (Playwright gegen Mailcatcher) |
| Support | Keiner | Während der Support-Laufzeit |
Wie wir das in Magento 2 gelöst haben
Unser Order-Withdrawal-Modul deckt beide Wege ab — den Logged-in-Flow für Kunden mit Magento-Account und den Public-Form-Flow für Gäste.
Logged-in: In der Bestellhistorie steht neben jeder fristgerechten Bestellung ein „Widerruf”-Button. Ein Klick öffnet das Formular, optional kann der Kunde einen Grund auswählen (konfigurierbar als Pflicht- oder Optional-Feld) und einen Kommentar hinterlassen. Eingang wird sofort bestätigt — der Kunde ist bereits authentifiziert, der Datenleak-Pfad existiert nicht.
Public Form: Der Kunde gibt Bestellnummer und E-Mail-Adresse ein, der Shop schickt eine Token-E-Mail ohne Bestelldaten. Erst nach Klick auf den Token-Link wird die Erklärung verarbeitet und die Bestätigung mit den eigentlichen Details verschickt. Das Formular ist mit serverseitig validiertem reCAPTCHA v3 geschützt.
Im Admin-Bereich landen alle Anträge unter Sales → Withdrawals — ein eigenes Grid mit Inline-Status-Edit. Anträge ohne automatisch erkannte Bestellung (etwa bei Tippfehlern in der Bestellnummer) bekommen eine Autocomplete-Order-Zuordnung; der Operator wählt die richtige Bestellung manuell.
Konfigurierbar ist praktisch alles, was rechtlich oder operativ variiert:
- Widerrufsfrist (Standard: 14 Tage, je nach Branche anpassbar)
- Erwartete Versandtage (Standard: 3, sollte konservativ gesetzt werden)
- Grace Period (Standard: 3 zusätzliche Tage)
- Token-Ablaufzeit (Standard: 24 Stunden)
- Erlaubte Order-Statuses für Widerruf-Eligibility
- Reason-Liste mit Code + Store-View-Labels
Ein Cron-Job räumt täglich um 02:00 Uhr abgelaufene, unbestätigte Anträge weg — keine Karteileichen in der Datenbank, keine veralteten Tokens.
Was der Operator selbst tun muss
Das Modul ist Infrastruktur. Die rechtliche Pflicht erfüllt es nur, wenn drumherum die übrigen Anforderungen aus 2023/2673 sauber umgesetzt sind. Was du parallel anpacken musst:
- Footer-Link auf die Widerrufs-Funktion, gut sichtbar — nicht versteckt im Sub-Menü
- §5 Widerrufsbelehrung in den AGB muss explizit auf die Online-Funktion verweisen, nicht nur auf das Muster-Formular
- Datenschutzerklärung ergänzen: Datenverarbeitung im Rahmen des Widerrufs (Token, IP-Adresse für reCAPTCHA, Reason-Eingabe)
- Bestellbestätigungs-Mail mit Hinweis auf die Funktion erweitern
- Personal-Schulung: Eingangsbestätigung ist nicht gleich Widerruf-Anerkennung. Operator muss den Unterschied verstehen und im Admin-Grid sauber umsetzen
Praktisch heißt das: Modul-Installation ist ein Halbtag, die rechtlichen Anpassungen drumherum sind ein bis zwei zusätzliche Tage Arbeit — meistens in Abstimmung mit dem Datenschutz-Berater des Shops.
Was du als nächstes tun kannst
Wenn dein Magento-2-Shop ab 19. Juni 2026 in der EU an Verbraucher verkauft, gibt es zwei pragmatische erste Schritte:
- Selbst-Check in 15 Minuten. Prüfe: Steht im Footer ein klickbarer Widerruf-Link? Verweist deine §5-Widerrufsbelehrung in den AGB auf eine Online-Funktion oder nur auf ein PDF? Enthält die Bestellbestätigungs-Mail einen Link zur Widerrufs-Funktion? Drei „Nein” = du brauchst die Funktion bis Mitte Juni.
- Modul-Installation oder Audit. Wir installieren das Order-Withdrawal-Modul bei dir, ziehen die Konfiguration mit dir durch und stimmen die rechtlichen Texte mit deinem Datenschutz-Berater ab. Bei Bedarf machen wir vorab einen kostenlosen Compliance-Audit — Kontakt: office@copex.io oder Termin anfragen.
Verwandte Themen aus unserem Blog: DSGVO-Aufbewahrungsfristen in Magento, EuGH-Urteil zur Cookie-Regelung, Magento-Patches und sichere Updates.




