Konfigurationen
Folgende Einstellungen sind relevant für die Konfiguration der Zahlungsart stripe:Module
Folgende Module sind relevant für die Integration der Zahlungsart stripe im Bestellprozess:- $wsStripe - stripe-Zahlungsarten Modul
- $wsCheckout - Checkout-Zustand, Adressen, Versand, Zahlung, Probleme, Summen
- $wsActions - Aktionen erzeugen und auswerten
- $wsAccount - Login-Status, E-Mail, Adressen, loadAddress()
- $wsViews - Aktuelle URL, Zielseiten, View-URLs
- $wsBasket - Warenkorb und Bestellübersicht
- $wsConfig - Konfigurationswerte, zum Beispiel Anreden und Währung
Aktionen
Folgende Aktionen sind relevant für die Integration der Zahlungsart stripe:Zusätzliche relevante Informationen
Folgende zusätzlichen Inhalte müssen für die Zahlungsart integriert werden.Frontend-Integration
Stripe stellt ein eigenes JavaScript-SDK bereit, das in das Template eingebunden werden muss. Es übernimmt die Darstellung der Zahlungsfelder und die Kommunikation mit Stripe. HTML-StrukturFolgender HTML-Block muss im Template plaziert werden:
#wsStripePaymentElementist der Container, in den Stripe die Zahlungsfelder (beispielsweise Kreditkartennummer oder PayPal-Button) automatisch einbettet- Das Formular sendet beim Klick auf “Mit Stripe bezahlen” den Bezahlvorgang ab
Der folgende Script-Block muss direkt nach dem HTML-Block eingefügt werden. Er muss in
{{ autoescape “js” }} eingeschlossen sein, damit Template-Variablen im JavaScript-Kontext korrekt verarbeitet werden.
Der Ablauf im Script ist folgender:
- Stripe initialisieren - Das SDK wird mit den Zugangsdaten aus $wsStripe.configuration gestartet
- Zahlungsfelder anzeigen - Stripe rendert die Zahlungsauswahl (Kreditkarte, PayPal und weitere) in den
#wsStripePaymentElement-Container. Die Adresseingabefelder von Stripe werden dabei deaktiviert, weil die Adresse des Kunden bereits im Shop bekannt ist und automatisch übergeben wird. - Bezahlung auslösen - Beim Absenden des Formulars werden die eingegebenen Zahlungsdaten zusammen mit der Rechnungsadresse aus $wsAccount an Stripe geschickt. Stripe gibt dafür ein Confirmation-Token zurück.
- Token an den Shop senden - Das Token wird an den Shop übermittelt, der damit den eigentlichen Zahlungsvorgang bei Stripe startet.
- Ergebnis verarbeiten - Schlägt die Zahlung fehl, wird eine Fehlermeldung angezeigt. Ist eine zusätzliche Bestätigung nötig, beispielsweise 3D Secure, übernimmt Stripe das automatisch.
- Weiterleitung - Nach erfolgreicher Zahlung wird der Kunde zur Bestellbestätigungsseite weitergeleitet.
Mehrseitiger Bestellablauf: Google Pay und Apple Pay
Bei der oben beschriebenen Frontend-Integration wird davon ausgegangen, dass das Payment-Element auf der letzten Seite des Bestellablaufs, also auf der Seite der Bestellübersicht, steht. Bei einem Bestellablauf mit mehreren Schritten ist es sinnvoll, das Widget bereits auf der Seite mit den Zahlungsarten zu laden, damit der Kunde seine Zahlungsdaten direkt bei der Auswahl eingeben kann. Das funktioniert für Kreditkarte und die übrigen Stripe-Zahlungsarten. Google Pay und Apple Pay verhalten sich anders und benötigen eine eigene Integration. Der folgende Abschnitt erklärt zunächst, woran das liegt, und zeigt anschließend den Einbau.Warum Wallets eine Sonderrolle haben
Für Stripe sind Google Pay und Apple Pay keine eigenen Zahlungsarten, sondern sie hängen an der Zahlungsartcard. Sobald card erlaubt ist und das Gerät des Kunden ein Wallet unterstützt, blendet das Payment-Element das Wallet von sich aus ein. Daraus ergeben sich drei Punkte, die in einem mehrseitigen Bestellablauf zu Problemen führen können.
- Der Wallet-Dialog schließt die Zahlung ab. Klickt der Kunde darin auf “Bezahlen”, autorisiert er die Zahlung sofort. Steht das Widget auf der Seite mit den Zahlungsarten, hat der Kunde bereits bezahlt, bevor er die Bestellbestätigung gesehen, die Versandart gewählt und die AGB bestätigt hat.
- Der Betrag steht fest, sobald das Widget geladen ist.
stripe.elements()erhält beim Aufruf die Parameteramountundcurrencyund genau dieser Betrag erscheint im Wallet-Dialog. Ändert sich die Summe danach noch, beispielsweise durch eine andere Versandart oder Kosten der Zahlungsart, zeigt der Dialog weiterhin den alten Betrag an. Das lässt sich nur mitelements.update({ amount: ... })korrigieren, und zwar bevor der Dialog geöffnet wird. - Der Wallet-Dialog erfordert eine unmittelbare Nutzeraktion. Browser öffnen den Apple-Pay- und Google-Pay-Dialog nur durch direkten Klick. Eine vorgeschaltete AJAX-Prüfung, wie sie auf einer Seite mit Zahlungsarten üblich ist, kostet diese Nutzeraktion und der Dialog öffnet sich nicht mehr.
Die Adresse aus dem Wallet hat bei Google Pay und Apple Pay Vorrang vor den
billing_details, die das Template mitgibt. Deshalb kann bei Stripe eine andere Rechnungsadresse stehen als im Shop. Die Bestellung wird vom Shop weiterhin mit den im Checkout gewählten Adressen angelegt.Empfohlener Einbau: Widget auf der Bestellübersicht
Am einfachsten ist es, das Payment-Element dort zu belassen, wo die Integration es vorsieht: auf der Bestellübersicht, also Schritt 3 im MultiPage Checkout. Auf der Zahlungsarten-Seite wählt der Kunde nur aus, das Widget wird dort nicht geladen. Damit fallen alle drei Punkte oben weg, weil Betrag, Versandart und AGB-Bestätigung zu diesem Zeitpunkt feststehen. Wenn das Widget trotzdem früher angezeigt werden soll, damit der Kunde seine Zahlungsdaten bereits bei der Auswahl eingeben kann, muss die Zahlungsart schon vor dem Laden des Widgets feststehen. Dafür gibt es zwei Varianten. Beide beruhen darauf, dass im Shop eigene Zahlungsarten mit Stripe als Clearing-Service angelegt werden und das Template das Widget an die gewählte Zahlungsart klammert. Sie unterscheiden sich darin, wie weit diese Aufteilung geht.Variante 1: eigene Zahlungsarten für Google Pay und Apple Pay
Bei dieser Variante werden lediglich die beiden Wallets voneinander getrennt. Alle übrigen Zahlungsarten von Stripe bleiben wie bisher in einer Zahlungsart zusammen.Konfiguration
Legen Sie im Konfigurationsdienst unterpayment.payment je eine eigene Zahlungsart für Google Pay und Apple Pay an und hinterlegen Sie bei beiden Stripe als Clearing-Service unter onlineClearing. Neben der bestehenden Stripe-Zahlungsart stehen dann drei Einträge zur Auswahl, beispielsweise mit den Kennungen stripe, googlePay und applePay.
Damit weiß der Shop ab der Zahlungsarten-Seite, welches Wallet der Kunde gewählt hat. Das Template kann sich im weiteren Verlauf darauf beziehen.
Zahlungsarten-Seite
Auf der Seite “Zahlungsarten” laden Sie das Payment-Element wie gewohnt, schalten die Wallets dort aber ab. Der Kunde gibt dort also nur seine Karten- oder anderen Zahlungsdaten ein. Es kann sich kein Wallet-Dialog öffnen.Bestellübersicht
In der Bestellübersicht wird für Google Pay und Apple Pay statt des Payment Elements das Express Checkout Element angezeigt. Es wird der Wallet-Button angezeigt und die Zahlung wird erst ausgelöst, wenn alle Angaben feststehen.elements-Instanz wie das Payment Element. Über allowedPaymentMethodTypes: ['card'] bleiben nur die beiden Wallets übrig. Über paymentMethods wird das nicht gewählte Wallet ausgeblendet.
Variante 2: jede Stripe-Zahlungsart einzeln anlegen
Diese Variante geht einen Schritt weiter. Anstatt nur die Wallets abzutrennen, legen Sie jede Stripe-Zahlungsart einmal im Shop an, beispielsweise Kreditkarte, SEPA-Lastschrift, Klarna und PayPal, jeweils mit Stripe als Clearing-Service. Der Kunde wählt damit bereits auf der Zahlungsarten-Seite die konkrete Zahlungsart aus, und das Widget lädt nur noch diese eine. Gesteuert wird das überallowedPaymentMethodTypes. Die Option nimmt die Stripe-Kennungen der Zahlungsarten entgegen, beispielsweise card, sepa_debit, klarna oder paypal. Das Template setzt die passende Kennung zur gewählten Zahlungsart:
card und erhalten allowedPaymentMethodTypes: ['card'] und werden über wallets bzw. paymentMethods ein- und ausgeblendet. Der Einbau auf Zahlungsarten-Seite und Bestellübersicht ist identisch zu Variante 1.
Welche Variante wann sinnvoll ist
Variante 1 ist der kleinere Eingriff. Sie lohnt sich, wenn der Shop das Stripe-Widget weiterhin als Zahlungsart führt und nur das Problem mit den Wallets lösen möchte. Variante 2 lohnt sich, wenn der Kunde bereits in der Zahlungsartenauswahl des Shops die konkrete Zahlungsart sehen soll, statt sie erst im Stripe-Widget auszuwählen. Der Konfigurationsaufwand ist jedoch höher, weil jede Zahlungsart einzeln angelegt und gepflegt werden muss.Vor dem Livegang prüfen
- Domain registrieren. Google Pay und Apple Pay erscheinen nur auf Domains, die bei Stripe als Payment Method Domain registriert sind, und zwar getrennt für Testmodus und Livemodus.
- HTTPS. Das Express Checkout Element arbeitet mit einem iframe und setzt eine Auslieferung über
https://voraus. - Betrag im Wallet-Dialog. Vergleichen Sie den Betrag im Apple-Pay- beziehungsweise Google-Pay-Dialog mit der Bestellsumme, insbesondere wenn Versandart oder Kosten der Zahlungsart die Summe verändern.
- Geräte ohne Wallet. Testen Sie den Fall, dass das Wallet nicht verfügbar ist, und stellen Sie sicher, dass der Kunde dann eine andere Zahlungsart wählen kann.
- Rechnungsadresse. Prüfen Sie im Stripe-Dashboard, welche Adresse bei der Zahlung ankommt, wenn das Wallet eine eigene Adresse liefert.
Weiterführende Links
- Generelle Doku für das Stripe Frontend: https://docs.stripe.com/js
- Express Checkout Element (Google Pay und Apple Pay): https://docs.stripe.com/elements/express-checkout-element
- Domain für Wallets registrieren: https://docs.stripe.com/payments/payment-methods/pmd-registration
- MultiPage Checkout
