WooCommerce Entwickler in Frankfurt

Seit dem 14. September 2019 gilt im Online-Handel die starke Kundenauthentifizierung (SCA) der EU-Zahlungsdiensterichtlinie PSD2. Sie entscheidet in Ihrem Shop mit, ob ein Kunde bezahlt oder an der Bank scheitert. Auf dieser Seite beschreibe ich, wie ich WooCommerce-Zahlungen unter SCA baue und teste, für Händler in Frankfurt am Main und Hessen. Ich bin ein einzelner Entwickler, arbeite aus Gdynia, schriftlich und ohne Termine. Layout und Gestaltung Ihres Shops liefern Sie, ich setze sie um.

Foto: Kiefer. from Frankfurt, Germany, CC BY-SA 2.0, Wikimedia Commons.

#Frankfurt und die Zahlungsfrage

Die Europäische Zentralbank sitzt in Frankfurt. Auf ihrer Website führt sie einen eigenen Bereich zu Zahlungsverkehr und Finanzstabilität und verlinkt dort den digitalen Euro. Für einen WooCommerce-Shop hat das heute keine Pflicht zur Folge. Die Pflichten zur Authentifizierung treffen die Zahlungsdienstleister, und Ihr Shop muss sie technisch zulassen. Genau das ist der Teil, den ich baue und teste.

#Was SCA im Checkout bedeutet

Rechtsgrundlage in Deutschland ist § 55 ZAG. Der Zahlungsdienstleister muss danach eine starke Kundenauthentifizierung verlangen, wenn der Zahler einen elektronischen Zahlungsvorgang auslöst. Bei Fernzahlungen, also in Ihrem Shop, muss sie den Vorgang dynamisch mit einem bestimmten Betrag und einem bestimmten Zahlungsempfänger verknüpfen. Die Einzelheiten und Ausnahmen regelt die Delegierte Verordnung (EU) 2018/389.

Nach Artikel 4 dieser Verordnung beruht die Authentifizierung auf mindestens zwei Elementen aus den Kategorien Wissen, Besitz und Inhärenz. Bei einer Kartenzahlung im Shop ist das Verfahren dafür 3-D Secure. Stripe schreibt in seiner SCA-Dokumentation: Kartenzahlungen müssen 3D Secure nutzen, um SCA zu erfüllen, und Banken können Zahlungen ablehnen, die den Vorgaben nicht folgen.

Für Sie als Händler folgt daraus ein wichtiger Punkt in § 675v Absatz 4 BGB. Verlangt der Zahlungsdienstleister des Zahlers keine starke Kundenauthentifizierung, muss der Zahler seinem Zahlungsdienstleister keinen Schaden ersetzen. Nimmt der Zahlungsempfänger oder dessen Zahlungsdienstleister eine starke Kundenauthentifizierung nicht an, muss dieser dem Zahlungsdienstleister des Zahlers den Schaden ersetzen. Ein Shop, der 3-D Secure nicht sauber abbildet, trägt das Risiko also selbst. Den Wortlaut finden Sie in § 675v BGB.

#Die Ausnahmen aus der Verordnung 2018/389

Nicht jede Zahlung braucht eine Authentifizierung. Die Verordnung nennt unter anderem diese Fälle:

Entscheidend ist das Wort “dürfen”. Die Ausnahme wendet der Zahlungsdienstleister an, nicht der Shop. Stripe schreibt dazu, Ausnahmen seien nicht garantiert und die Bank könne trotzdem Authentifizierung verlangen. Ihr Checkout muss deshalb immer in der Lage sein, einen 3-D-Secure-Dialog anzuzeigen, auch wenn die meisten Zahlungen ohne ihn durchlaufen. Bei der Transaktionsrisikoanalyse gelten nach Anhang der Verordnung gestaffelte Referenzwerte für die Betrugsquote, bei Karten 0,01 Prozent für die Schwelle fünfhundert Euro, 0,06 Prozent für zweihundertfünfzig und 0,13 Prozent für hundert Euro. Diese Zahlen erfüllt der Zahlungsdienstleister, nicht Ihr Shop.

#Der Ablauf bei einer Kartenzahlung

Am Beispiel der Payment-Intents-Schnittstelle von Stripe, die viele WooCommerce-Gateways nutzen, sieht der Ablauf von 3D Secure so aus. Der Kunde gibt die Karte ein. Die Bank prüft die Zahlung und kann sie sofort freigeben (frictionless) oder einen zusätzlichen Schritt verlangen (Challenge). Verlangt sie ihn, steht die Zahlung im Status requires_action, und der Shop muss den Dialog anzeigen, als Popup oder per Weiterleitung zur Bank. Schlägt die Authentifizierung fehl, fällt der Status auf requires_payment_method: Der Kunde muss eine andere Zahlungsart wählen oder es erneut versuchen.

Für den Shop heißt das: Die Bestellung darf erst als bezahlt gelten, wenn die Zahlung wirklich abgeschlossen ist. Eine Bestellung, die auf die Authentifizierung wartet, bleibt offen. Bricht der Kunde im Bank-Dialog ab, darf kein Lagerbestand dauerhaft reserviert bleiben, und die Bestellung braucht einen klaren Weg zurück in den Warenkorb. Genau dort entstehen in der Praxis die Beschwerden, dass eine Zahlung “hängt”, und nicht in der Kartenprüfung selbst.

#Gespeicherte Karten und Abos

Bei einem Abo oder einer gespeicherten Karte zahlt der Kunde später ohne Beteiligung im Shop, “off-session” in der Sprache der Anbieter. Stripe beschreibt dafür zwei Schritte: den Kunden einmal on-session authentifizieren und die Karte dann wiederverwenden, mit gesetztem off-session-Flag. Beim Speichern ohne Zahlung dient die Setup-Intents-Schnittstelle. Der Kunde muss dem Händler dabei erlauben, Zahlungen in seinem Namen auszulösen, mit Angabe von Häufigkeit und Berechnung des Betrags. Dieser Hinweistext gehört in den Checkout. Auch hier gilt: Ausnahmen sind nicht garantiert, die Bank kann bei einer Folgezahlung trotzdem Authentifizierung verlangen.

Dann greift die Wiederholungslogik von WooCommerce Subscriptions. Laut Dokumentation ist der automatische Wiederholungsversuch standardmäßig aus und lässt sich unter den Abo-Einstellungen im Bereich Zahlungswiederherstellung einschalten. Die Voreinstellung umfasst fünf Versuche über etwa sieben Tage. Für SEPA-Zahlungen löst sie nicht aus, und PayPal Standard erlaubt keine automatischen Wiederholungen. Während der Wartezeit steht die Verlängerungsbestellung auf “Ausstehend” und das Abo auf “In Wartestellung”. Sind alle Versuche gescheitert, geht die Bestellung auf “Fehlgeschlagen”, und der Kunde bekommt, sofern aktiviert, die Rechnungs-E-Mail zur Verlängerung. Ohne den Wiederholungsmechanismus bleibt das Abo laut Dokumentation zum Verlängerungsprozess in Wartestellung, bis der Kunde im Konto zahlt. Ob eine Abo-Zahlung wegen fehlender Authentifizierung scheitert, sieht der Kunde nur, wenn Ihre E-Mail den Grund nennt. Den Text dieser E-Mail prüfe ich mit Ihnen.

#Rückbuchungen und Haftungsverschiebung

Wird eine mit 3D Secure authentifizierte Zahlung später als betrügerisch bestritten, geht die Haftung nach Stripe in der Regel vom Händler auf die kartenausgebende Bank über. Stripe betont, dass das nicht garantiert ist. Ein erfolgreicher 3-D-Secure-Lauf bestätigt nur die Authentifizierung. Außerdem greift der Schutz nur bei Betrugsvorwürfen: Wer “Ware nicht erhalten” meldet, folgt dem normalen Streitverfahren. Auf eine Anfrage der Bank zu einer authentifizierten Zahlung müssen Sie antworten, sonst droht eine Rückbuchung wegen fehlender Antwort, die den Schutz aufheben kann. Dafür brauche ich im Shop Daten, die Sie im Streitfall vorlegen: Bestellinhalt, Lieferweg, Empfänger. Ich baue die Bestellansicht so, dass diese Angaben an einer Stelle stehen.

#Was ich auf der Testumgebung prüfe

Zahlungen teste ich nie am Live-Shop. Auf der Staging-Kopie verwende ich den Testmodus des Anbieters mit eigenen Testschlüsseln. Bei Stripe gibt es dafür Testkarten, jeweils mit beliebigem CVC und künftigem Ablaufdatum. Die folgende Liste ist ein Ausschnitt der Fälle, die ich durchspiele.

Dazu gehören Prüfungen, die nichts mit Karten zu tun haben. Wird ein Webhook doppelt zugestellt, darf die Bestellung nicht doppelt auf bezahlt springen. Schließt der Kunde den Tab im Bank-Dialog, muss die Bestellung später aufgelöst werden. Eine Teilerstattung muss im Streitfall Folgen haben, die die Buchhaltung versteht. Bei Abos gehört ein Durchlauf dazu: Anmeldung, erste Verlängerung, abgelehnte Verlängerung, Wiederholung, manuelle Zahlung durch den Kunden. Welche anderen Anbieter Sie nutzen, ob PayPal, Mollie oder ein Bankprodukt, prüfe ich in deren Entwicklerdokumentation auf dieselben Punkte, bevor ich eine Schätzung abgebe.

#Was ich von Ihnen brauche

• Welche Zahlungsarten und welcher Anbieter heute laufen, und ob Abos oder gespeicherte Karten dazugehören.
• Zugang zum Shop und eine Staging-Umgebung, oder die Freigabe, eine anzulegen.
• Zugang zum Testmodus Ihres Zahlungsanbieters, nicht zum Live-Konto.
• Beispiele für Bestellungen, bei denen Kunden Zahlungen abgebrochen haben oder Rückbuchungen kamen.
• Layout, Texte und Mailvorlagen, wenn der Checkout sichtbar geändert werden soll. Ich setze sie um, ich gestalte nicht.

#Wie die Zusammenarbeit läuft

Sie schicken mir die Shop-Adresse und das Ziel per Formular. Ich lese die Zahlungseinstellungen und schreibe Ihnen, was ich finde und was offen ist. Danach folgen ein schriftlicher Umfang mit Annahmen und eine Testfall-Liste wie die obige, angepasst auf Ihren Anbieter. Umgesetzt wird auf Staging, Sie nehmen schriftlich ab, dann geht es live. Auf Wunsch folgt eine Wartung mit getesteten Updates, Backups außerhalb des Hostings und einem monatlichen Bericht. Stunden aus dem Wartungspaket verfallen am Monatsende und laufen nicht in den nächsten Monat. Für die Einschätzung vorab berechne ich nichts. Zur Betreuung bestehender Shops lesen Sie auch die Wartung in Frankfurt, zu Datenschutz-Meldewegen in Hessen den HBDI.

#Häufige Fragen

#Gilt SCA auch für mein kleines WooCommerce-Geschäft?

Ja, wenn Sie Kartenzahlungen von Kunden im Europäischen Wirtschaftsraum annehmen. Die Pflicht liegt formal beim Zahlungsdienstleister, nach § 55 ZAG, doch Ihr Shop muss die Authentifizierung anzeigen können, sonst werden Zahlungen abgelehnt.

#Welche Zahlungen brauchen keine Authentifizierung?

Dazu zählen Kleinbeträge bis dreißig Euro mit Grenzen für die Summe und die Anzahl, risikoarme Zahlungen nach Transaktionsrisikoanalyse und Folgezahlungen einer Serie. Die Entscheidung trifft der Zahlungsdienstleister, und die Bank kann trotzdem eine Authentifizierung verlangen.

#Warum schlägt die Verlängerung eines Abos fehl, obwohl die Karte gespeichert ist?

Die Bank kann bei einer Folgezahlung ohne Kunde im Shop dennoch eine Authentifizierung verlangen. Dann bleibt das Abo in Wartestellung, bis der Kunde zahlt oder eine Wiederholung gelingt. Wichtig sind eine Zustimmung beim Speichern der Karte und eine verständliche E-Mail.

#Schützt 3-D Secure mich vor Rückbuchungen?

Bei Betrugsvorwürfen verschiebt sich die Haftung in der Regel auf die Bank, garantiert ist das nicht. Bei “Ware nicht erhalten” schützt es nicht. Antworten Sie auf Anfragen der Bank, sonst kann der Schutz entfallen.

#Kann ich das am Live-Shop testen?

Das empfehle ich nicht. Ich teste auf Staging im Testmodus des Anbieters mit Testkarten für jeden Fall. Erst danach wird der Live-Modus freigeschaltet.

#Kommen Sie für ein Gespräch nach Frankfurt?

Nein. Ich arbeite remote und schriftlich. Das gilt für Angebot, Abstimmung und Abnahme.

#Ihre Anfrage

Schreiben Sie mir über das Kontaktformular: Shop-Adresse, Zahlungsanbieter, Ziel und gewünschter Zeitrahmen, dazu den Stand von Plugins und Hosting, soweit bekannt. Ich antworte schriftlich an Werktagen, und die erste Einschätzung zu Ihrem Checkout bekommen Sie gratis.