Widerrufsbutton Shopware Juni 2026: Technische Umsetzung

Der Widerrufsbutton ist seit dem 19. Juni 2026 verbindliche Pflicht für jeden B2C-Online-Shop in Deutschland. Die Richtlinie (EU) 2023/2673 und ihre deutsche Umsetzung in § 356a BGB schreiben eine zweistufige digitale Widerrufsmöglichkeit vor, deren technische Umsetzung weit mehr verlangt als nur einen Button im Footer. Wer die Funktion nicht oder fehlerhaft bereitstellt, riskiert eine Abmahnung durch Mitbewerber und Verbraucherschutzverbände; bei weitverbreiteten Verstößen sieht Art. 246e EGBGB zudem einen Bußgeldrahmen bis 4 Prozent des Jahresumsatzes vor. Dieser Leitfaden zeigt die konkrete technische Implementierung in Shopware 6, die zulässigen Label-Formulierungen, die erlaubten Datenabfragen sowie die Anforderungen an die Eingangsbestätigung.

Was ab 19. Juni 2026 gilt

Die Richtlinie (EU) 2023/2673 ist in Deutschland durch § 356a BGB umgesetzt – „Elektronische Widerrufsfunktion bei Fernabsatzverträgen“. Die Umsetzungsfrist für die Mitgliedstaaten endete am 19. Dezember 2025, angewendet werden die Vorschriften ab dem 19. Juni 2026. Ab diesem Stichtag muss jeder B2C-Shop einen funktionsfähigen Widerrufsbutton bereitstellen, der den Widerruf deutlich einfacher macht als das Ausfüllen eines Formulars oder das Schreiben einer E-Mail. Weitere rechtliche Grundlagen sind in unserem Artikel zur Widerrufsbutton-Pflicht 2026 ausführlich aufbereitet.

Der Anwendungsbereich ist weit gefasst: § 356a BGB gilt für Fernabsatzverträge, die über eine Online-Benutzeroberfläche geschlossen werden. Die zugrundeliegende Richtlinie stellt ausdrücklich klar, dass die Pflicht nicht nur für Fernabsatzverträge über Finanzdienstleistungen gilt, sondern für sämtliche Fernabsatzverträge, für die ein Widerrufsrecht vorgesehen ist. Wer einen B2C-Shop betreibt, kann sich also nicht darauf berufen, die Regelung ziele allein auf Finanzprodukte – sie trifft den Warenhandel genauso.

Die Widerrufsfrist von 14 Tagen bleibt unverändert (§ 355 Absatz 2 BGB). Fehlt die ordnungsgemäße Belehrung, erlischt das Widerrufsrecht erst zwölf Monate und 14 Tage nach dem regulären Fristbeginn (§ 356 Absatz 4 BGB). Wichtig: Der Button ersetzt nicht die Pflicht zur Widerrufsbelehrung, sondern stellt lediglich eine zusätzliche, barrierearme Ausübungsmöglichkeit dar. Händler müssen beide Wege parallel anbieten – klassischer Widerruf per Text und digitaler Widerruf per Button.

Button-Anatomie: Zweistufiger Ablauf

Der Gesetzgeber schreibt einen zweistufigen Prozess vor: Stufe 1 ist der eigentliche Button mit dem Klick, Stufe 2 ist ein Bestätigungsformular mit Eingabe der Identifikationsdaten und Absenden des Widerrufs. Nur so lässt sich sicherstellen, dass der Kunde den Widerruf bewusst auslöst und gleichzeitig der Händler die Bestellung eindeutig zuordnen kann. Eine einstufige Umsetzung – also ein Button, der den Widerruf direkt ohne Datenerhebung auslöst – ist unzulässig, weil keine Zuordnung möglich wäre.

Die beiden Stufen sind klar voneinander abzugrenzen: Stufe 1 ist eine reine Intention-Geste des Kunden. Nach dem Klick auf „Vertrag widerrufen“ öffnet sich entweder eine dedizierte Seite oder ein modales Dialogfenster mit dem Formular. Erst mit dem finalen Klick auf „Widerruf bestätigen“ wird der Widerruf rechtlich wirksam erklärt und gilt als beim Händler eingegangen. Dieser Moment ist rechtlich entscheidend, weil ab diesem Zeitpunkt die Frist zur Rückgewähr der empfangenen Leistungen läuft – spätestens nach 14 Tagen (§ 357 Absatz 1 BGB).

Technisch realisieren lässt sich der Ablauf über eine dedizierte Route (z. B. /widerruf) mit einem Twig-Template, das im ersten Schritt den Button zeigt und nach dem Klick per POST-Request zum Formular-Step weiterleitet. Alternativ kann ein modales Dialogfenster über JavaScript geöffnet werden, solange der Dialog auch bei deaktiviertem JS als Fallback via normaler Seite funktioniert – Barrierefreiheit ist durch das BFSG ohnehin Pflicht. Eine saubere BFSG-Audit-Routine prüft automatisiert, ob Kontraste, Tastaturnavigation und Screenreader-Labels am Widerrufsformular den WCAG-2.1-AA-Standard erfüllen. Ein Modal ohne Fokus-Trap oder ohne Escape-Taste scheitert regelmäßig an diesen Kriterien.

Beschriftung nach § 356a BGB

Das Gesetz nennt für beide Schaltflächen eine Beschriftung und lässt daneben eine andere gleichbedeutende eindeutige Formulierung zu (§ 356a Abs. 1 und 3 BGB). Spielraum für Varianten besteht also nur, solange die Absicht des Widerrufs unmissverständlich bleibt – neutrale Formulierungen wie „Kontakt“ oder „Nachricht senden“ erfüllen das nicht, weil sie den Zweck verschleiern.

Die Formulierung „Vertrag widerrufen“ ist der Wortlaut, den § 356a Abs. 1 BGB für den primären Button nennt; für den Bestätigungs-Button nennt Abs. 3 „Widerruf bestätigen“. Wer diese Wörter übernimmt, erspart sich die Prüfung, ob eine eigene Formulierung gleichbedeutend ist. Wer bereits eine Shopware-Agentur mit der Umsetzung beauftragt hat, sollte diese Labels in den Snippets hinterlegen und sprachabhängig übersetzen – für englischsprachige Shops etwa als „Withdraw contract“ und „Confirm withdrawal“.

Platzierung im Shop

Der Button muss dauerhaft, gut sichtbar und kontrastreich platziert werden. Eine Unterbringung ausschließlich in einer verschachtelten Hilfe-Sektion reicht nicht. Sinnvoll sind zwei Platzierungen: prominent im Footer auf allen Seiten sowie im Kundenkonto unter „Meine Bestellungen“. Besonders wichtig: Der Button muss auch für nicht eingeloggte Besucher (Gäste-Bestellungen) erreichbar sein – eine Platzierung ausschließlich hinter dem Kundenkonto-Login ist unzulässig.

• Position im Footer jeder Seite, oberhalb oder neben Impressum/AGB
• Zusätzlich im Header als Link oder in der Meta-Navigation
• Im Kundenkonto direkt bei jeder widerrufbaren Bestellung verlinkt
• Auch für Gast-Bestellungen per separater Seite ohne Login erreichbar
• Kontrastreich gestaltet nach WCAG 2.1 AA (min. 4,5:1 bei Fließtext)
• Mobil voll bedienbar, Tap-Target mindestens 44 × 44 px
• Nicht hinter mehreren Klicks oder Akkordeons versteckt
• Auch bei deaktiviertem JavaScript funktionsfähig

Daten, die Sie abfragen dürfen

Das Gesetz beschränkt die Datenerhebung im Widerrufsformular strikt auf das Minimum, das für eine eindeutige Zuordnung nötig ist. Eine Abfrage von Widerrufsgründen, Zufriedenheits-Skalen oder Rückgabe-Alternativen ist während des Widerrufsprozesses unzulässig und wäre abmahngefährdet.

Diese drei Felder reichen aus. Optional dürfen Sie die Auswahl des konkret zu widerrufenden Artikels anbieten, wenn Teilwiderruf möglich sein soll – etwa bei mehreren Positionen innerhalb einer Bestellung. Unter keinen Umständen abfragen dürfen Sie hingegen: Gründe für den Widerruf, Bitte um Stellungnahme vor dem Widerruf, Rückfragen zur Zahlungsmethode oder alternative Angebote wie Gutscheine. Eine Retourengrund-Abfrage darf nach dem abgeschlossenen Widerruf freiwillig angeboten werden – unser Ratgeber zum Retourenmanagement zeigt, wie Sie diese Daten ohne rechtliches Risiko sammeln.

Die strikte Datenminimierung ergibt sich unmittelbar aus dem Gesetz: § 356a Absatz 2 BGB zählt abschließend auf, welche Informationen die Widerrufsfunktion abfragen darf – den Namen des Verbrauchers, Angaben zur Identifizierung des Vertrags oder des widerrufenen Teils und Angaben zum elektronischen Kommunikationsmittel, mit dem die Eingangsbestätigung übermittelt wird. Retourengründe sind betriebswirtschaftlich interessant, und genau diese Relevanz verleitet dazu, das Widerrufsformular als Feedback-Kanal zu missbrauchen – die Aufzählung im Gesetz lässt dafür aber keinen Raum.

Retourengründe gehören deshalb in einen getrennten Prozess: eine separate Mail mit optionaler Umfrage zwei bis drei Tage nach Eingang der Retoure, erkennbar freiwillig und ohne Einfluss auf die Abwicklung des Widerrufs. So bleiben Widerrufsprozess und Retourenanalyse rechtlich sauber getrennt, und die Auswertung stützt sich auf Antworten, die der Kunde bewusst gegeben hat.

Technische Integration in Shopware 6

Seit Version 6.7.9.0 vom April 2026 bringt Shopware ein Widerrufsformular im Kernsystem mit; die Funktion wurde auf Shopware 6.6 zurückgeführt und steht auch in der Community Edition zur Verfügung. Ob die eingesetzte Fassung die Kernfunktion bereits enthält, zeigen ihre Release Notes. Wer nicht aktualisieren kann oder einen abweichenden Ablauf braucht, setzt die Funktion als eigenes Plugin um. Die folgende Minimal-Implementierung zeigt den Controller für die zweite Stufe (Formularabsendung):

<?php declare(strict_types=1);

namespace Xictron\Withdrawal\Storefront\Controller;

use Shopware\Core\Framework\Context;
use Shopware\Core\Framework\DataAbstractionLayer\EntityRepository;
use Shopware\Core\Framework\Routing\Annotation\RouteScope;
use Shopware\Core\Framework\Uuid\Uuid;
use Shopware\Storefront\Controller\StorefrontController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

/**
 * @RouteScope(scopes={"storefront"})
 */
class WithdrawalController extends StorefrontController
{
    public function __construct(
        private readonly EntityRepository $withdrawalRepository,
        private readonly WithdrawalMailService $mailService
    ) {}

    /**
     * @Route("/widerruf", name="frontend.withdrawal.form", methods={"GET"})
     */
    public function form(Request $request): Response
    {
        return $this->renderStorefront('@XictronWithdrawal/storefront/page/withdrawal/index.html.twig');
    }

    /**
     * @Route("/widerruf/submit", name="frontend.withdrawal.submit", methods={"POST"})
     */
    public function submit(Request $request, Context $context): Response
    {
        $name = trim((string) $request->request->get('name'));
        $orderNumber = trim((string) $request->request->get('orderNumber'));
        $email = filter_var($request->request->get('email'), FILTER_VALIDATE_EMAIL);

        if (!$name || !$orderNumber || !$email) {
            $this->addFlash('danger', 'Bitte füllen Sie alle Pflichtfelder aus.');
            return $this->redirectToRoute('frontend.withdrawal.form');
        }

        $reference = 'WDR-' . date('Y') . '-' . strtoupper(substr(Uuid::randomHex(), 0, 5));

        $this->withdrawalRepository->create([[
            'id' => Uuid::randomHex(),
            'reference' => $reference,
            'customerName' => $name,
            'orderNumber' => $orderNumber,
            'email' => $email,
            'receivedAt' => new \DateTimeImmutable(),
        ]], $context);

        $this->mailService->sendConfirmation($email, $name, $orderNumber, $reference);
        $this->mailService->notifyMerchant($name, $orderNumber, $reference);

        return $this->redirectToRoute('frontend.withdrawal.success', ['ref' => $reference]);
    }
}

Die Datenbank-Entität withdrawal speichert die Eingangsdaten mit Zeitstempel als Nachweis. Zusätzlich muss im Shopware Flow Builder ein Trigger eingerichtet werden, der beim Eintreffen eines neuen Widerrufs die internen Prozesse anstößt – etwa das Erstellen einer Retoure in der Warenwirtschaft, das Pausieren ausstehender Versand-Aufträge und die Information des Customer-Service-Teams. Für die Formular-Ansicht selbst reicht ein schlankes Twig-Template mit drei Input-Feldern. Wer individuelle Frontends mit Vue oder Nuxt betreibt, implementiert den Flow als separate SPA-Route mit REST-Endpunkt.

Eingangsbestätigung automatisieren

Der Händler ist verpflichtet, den Eingang des Widerrufs unverzüglich auf einem dauerhaften Datenträger zu bestätigen. In der Praxis bedeutet das: Innerhalb weniger Minuten nach Absenden des Formulars muss eine E-Mail an den Kunden gehen, die den Eingang dokumentiert. Die Bestätigung muss mindestens enthalten: Name des Kunden, Bestellnummer, Zeitpunkt des Eingangs (Datum und Uhrzeit), eine eindeutige Referenz-ID sowie eine kurze Information über die nächsten Schritte.

Technisch empfiehlt sich ein Mail-Template im Shopware-Mail-System mit den Platzhaltern {{ customerName }}, {{ orderNumber }}, {{ receivedAt|format_datetime }} und {{ reference }}. Um Verzögerungen zu vermeiden, sollte der Versand nicht synchron im Request-Handler erfolgen, sondern über die Shopware-Message-Queue asynchron im Worker-Prozess. So bleibt die Response-Zeit für den Kunden unter 500 ms, selbst wenn der SMTP-Server gerade ausgelastet ist.

Parallel zum Kunden-Mail sollte ein internes Benachrichtigungs-System eingerichtet werden: eine Benachrichtigung an das Customer-Service-Team, optional ein Eintrag im Ticket-System oder eine Push-Benachrichtigung an die Logistik. Die Nachweis-Pflicht für den Händler bezieht sich auf die Empfangsbestätigung – prüfbar nachvollzogen werden muss, wann und wie der Widerruf entgegengenommen wurde. Ein detaillierter Log-Eintrag mit IP-Adresse und User-Agent (ohne personenbezogene Verarbeitung jenseits der Bestellzuordnung) schützt im Streitfall.

Die Referenz-ID sollte folgenden Anforderungen genügen: eindeutig über alle Widerrufe hinweg, nicht erratbar (um Enumeration-Angriffe zu verhindern), menschenlesbar für Support-Anfragen und kurz genug, um in Betreffzeilen zu passen. Ein bewährtes Schema ist WDR-JAHR-ABCDE mit 5 zufälligen alphanumerischen Zeichen (ca. 60 Millionen Kombinationen pro Jahr). Dieser Ref-Code sollte in allen Folge-Mails (Eingangsbestätigung, Rückversand-Information, Erstattungsbestätigung) konsistent verwendet werden, damit Kunde und Support jederzeit den Vorgang nachvollziehen können.

Ausnahmen: Wann der Button nicht nötig ist

Nicht jeder Shop braucht einen Widerrufsbutton. Die Pflicht gilt ausschließlich für Verträge, für die das gesetzliche Widerrufsrecht überhaupt besteht. In folgenden Konstellationen entfällt die Button-Pflicht vollständig oder teilweise:

• Reine B2B-Shops ohne Endkundenverkauf – kein Widerrufsrecht, kein Button nötig
• Verkauf personalisierter Waren (z. B. Gravur, individuelle Konfiguration)
• Leicht verderbliche Lebensmittel mit begrenzter Haltbarkeit
• Versiegelte Medien (CDs, DVDs, Software) nach Entfernen des Siegels
• Digitale Inhalte auf nicht-physischem Träger, sobald mit Ausführung begonnen wurde
• Finanzdienstleistungen mit eigenen Widerrufsregeln (erweiterte Fristen)
• Waren, die untrennbar mit anderen Sachen verbunden wurden
• Verträge, die auf öffentlichen Versteigerungen geschlossen wurden

Abmahnrisiko und typische Fehler

Abmahnwellen starten erfahrungsgemäß innerhalb weniger Tage nach einem Stichtag, weil der Verstoß von außen sichtbar ist: Ob ein Shop eine Widerrufsfunktion bereitstellt, lässt sich ohne Testbestellung und ohne Kundenkonto prüfen. Genau das macht den Widerrufsbutton zu einem bequemen Abmahngrund – anders als etwa eine fehlerhafte Datenverarbeitung im Hintergrund, die erst auffällt, wenn jemand sie meldet.

Für kleine Händler wiegt das schwerer als für große: Eine Abmahnung bindet Zeit und Geld, die im laufenden Betrieb fehlen, und die Nachbesserung unter Fristdruck ist aufwendiger als eine saubere Erstimplementierung. Eine frühzeitige Beratung ist daher in aller Regel die günstigere Variante als eine spätere Nachbesserung nach erfolgter Abmahnung.

Prüfliste für Umsetzung und Nachprüfung

1. Ist-Aufnahme: welche Bestell-Typen gibt es, welche Kundengruppen, welche Ausnahmen greifen; eingesetzte Shopware-Version prüfen und ob sie die Kernfunktion bereits enthält
2. Technischer Entwurf: prüfen, ob das Kernformular aus 6.7.9.0 (Backport 6.6) den Bedarf deckt; sonst Route, Template, Controller, Datenmodell, Mail-Templates und Flow-Builder-Integration festlegen
3. Entwicklung und Code-Review: Shopware-Update einspielen oder Plugin entwickeln, Storefront-Template anpassen
4. End-to-End-Test in Staging: Formular-Flow, Bestätigungs-Mail, interne Notification, Flow-Trigger, Mobile, Barrierefreiheit
5. Rechts-Review: Prüfung durch Fachanwalt, Label-Prüfung, Datenschutz-Check, Anpassung der Datenschutzerklärung
6. Deployment: Auslieferung in Produktion, Cache-Warmup, Monitoring der Error-Logs
7. Betrieb: in den ersten 48 Stunden nach dem Livegang Logs und Mail-Queue engmaschig beobachten, Support-Team auf Rückfragen vorbereiten; nach jedem Shopware-Update den Ablauf erneut testen

Wer die Funktion noch nicht oder nur teilweise bereitstellt, sollte die Lücke zügig schließen, denn die Pflicht gilt bereits. Wo das Kernformular nicht passt, ist die eigene Umsetzung je nach Shop-Komplexität in der Regel eine Sache von Tagen reiner Entwicklungsarbeit – zuzüglich Test und Rechts-Review. Wer auf individuelle Programmierung setzt oder ein Headless-Frontend betreibt, sollte deutlich mehr Zeit einplanen, weil die API-Schnittstellen mit entworfen werden müssen.