Skip to main content
Der Knoten payment bündelt die komplette Zahlungskonfiguration des Shops inklusive einzelner Zahlungsarten (Anzeige, Regeln) und Payment-Providern wie PayPal, Stripe oder Computop.

payment* - Grundstruktur

Nachfolgend der Grundaufbau des Knotens payment

Parameterbeschreibung


payment.computopHosted - Computop Hosted Payments

Mit payment.computopHosted lässt sich Computop als gehostete Zahlungsseite einbinden. Der Knoten steuert beispielsweise Betriebsmodus (Live / Test), Verschlüsselung und Sprache / Template der Bezahlseite. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.computopHosted (Deeplink-Übersicht)

Beispielkonfiguration (payment.computopHosted.creditcard)

Parameterbeschreibung


payment.payment - Zahlungsarten anlegen

Der Knoten payment.payment fasst alle Zahlarten des Shops zusammen. Hier kann beispielsweise definiert werden, ob eine Zahlart aktiv ist, wie sie im Checkout heißen und aussehen soll, welcher Provider sie bedient und welche Regeln gelten. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.payment (Deeplink-Übersicht)
Zahlungsarten können an eine Währung oder Region gebunden sein (beispielsweise Bancontact: nur EUR, primär Belgien). Welche Währungen und Länder eine Zahlungsart unterstützt, wird vom Zahlungsanbieter bestimmt. Eine aktivierte Zahlungsart wird daher unabhängig von der Shop-Währung angeboten und kann eventuell beim Zahlungsdienstleister zu einem Fehler führen. Prüfen Sie daher vor der Aktivierung anhand der Anbieter-Dokumentation, ob die Zahlungsart zu Währung und Zielland Ihres Shops passt, und deaktivieren Sie nicht passende Methoden.
Läuft der Bestellablauf über mehrere Seiten und soll das Stripe-Widget bereits vor der Bestellübersicht geladen werden, legen Sie für Google Pay und Apple Pay je eine eigene Zahlungsart mit Stripe als Clearing-Service an. Das Template kann sich dann ab der Zahlungsarten-Seite auf das gewählte Wallet beziehen. Den Einbau im Template beschreibt Stripe im Frontend.

Beispielkonfiguration (payment.payment.paypalCheckout)

Parameterbeschreibung


payment.paymentField - Zusatzfelder für Zahlungsarten

Manche Zahlungsarten brauchen Angaben, die nicht in der Adresse stehen. PayPal Kauf auf Rechnung verlangt beispielsweise das Geburtsdatum und die Telefonnummer des Käufers. Mit dem Knoten payment.paymentField legen Sie solche Zusatzfelder an. Der Shop fragt sie im Checkout zusammen mit der Zahlungsart ab und schreibt die Eingaben in die Bestelldaten. Von dort lassen sie sich wie alle anderen Bestelldaten an externe Systeme exportieren. Ein Zusatzfeld entsteht in drei Schritten:
  1. Feld in payment.paymentField anlegen.
  2. Feld der Zahlungsart unter additionalFields zuordnen, siehe payment.payment.
  3. Feld im Template ausgeben und mit der Aktion CheckoutSetPaymentFields speichern. Die Felder einer Zahlungsart stehen im Template unter $wsConfig.payments im Eintrag fields bereit.
Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.paymentField (Deeplink-Übersicht)

Beispielkonfiguration (payment.paymentField.birthdatePayPal)

Das Beispiel legt ein Pflichtfeld für das Geburtsdatum an. Der Wert wird im Kundenkonto gemerkt und muss dem Format JJJJ-MM-TT entsprechen.
dataChecker.regex prüft, ob der gesamte Wert zum Ausdruck passt. Ein Datumsfeld liefert Monat und Tag immer zweistellig, beispielsweise 1990-05-01. Der Ausdruck muss deshalb führende Nullen zulassen.

Parameterbeschreibung

Ein Feld, dessen Anzeigebedingungen nicht erfüllt sind, gilt als nicht vorhanden. Es erscheint nicht im Template, wird nicht geprüft und blockiert auch als Pflichtfeld den Bestellabschluss nicht.

Mehrere Felder mit demselben Namen

Weil der Shop Zusatzfelder über name anspricht, können mehrere Konfigurationsknoten denselben Namen tragen. So lässt sich dieselbe Angabe je nach Situation unterschiedlich abfragen, beispielsweise mit länderabhängigen Auswahllisten oder Prüfungen. Die Varianten unterscheiden sich dann über displayConditions.
Die Anzeigebedingungen gleichnamiger Felder müssen sich gegenseitig ausschließen. Sind zwei gleichnamige Felder gleichzeitig sichtbar, schreiben beide in denselben Wert.

Eingaben merken

Mit rememberInput: true speichert der Shop den eingegebenen Wert nach der Bestellung im Kundenkonto. Das gilt nur für angemeldete Kunden. Bei Gastbestellungen bleibt der Wert in der laufenden Sitzung und wird nicht gespeichert. Der gemerkte Wert wird beim nächsten Checkout nicht automatisch eingesetzt. Das Template entscheidet, ob es das Feld damit vorbelegt. Der Wert steht dort als rememberedValue am Feld bereit, siehe $wsConfig.payments.

Zusatzfelder in den Bestelldaten

Mit der Bestellung schreibt der Shop die Zusatzfelder der gewählten Zahlungsart in den Block order.paymentFields. Schlüssel ist der technische Name des Feldes, Wert die Eingabe des Kunden:
Enthalten sind alle Felder, die der Zahlungsart zugeordnet sind. Ein Feld, das wegen seiner Anzeigebedingung nicht angezeigt wurde, steht mit leerem Wert darin oder mit einer früheren Eingabe aus derselben Sitzung.

Beispiel: PayPal Kauf auf Rechnung

PayPal braucht für den Kauf auf Rechnung das Geburtsdatum und die Telefonnummer des Käufers. Welche Zusatzfelder diese Angaben liefern, legen Sie in der Zahlungsart unter onlineClearing.options.clearingFields fest:
Der Shop übergibt den Wert des Zusatzfeldes bday als Geburtsdatum und den Wert von phone als Telefonnummer an PayPal. Eingetragen wird jeweils der technische Name aus name, nicht die ID des Konfigurationsknotens. Beide Felder müssen der Zahlungsart zusätzlich unter additionalFields zugeordnet sein, sonst fragt der Checkout sie nicht ab. Bei der Telefonnummer liest der Shop die Ländervorwahl aus dem Anfang der Eingabe. Beginnt die Nummer mit + oder 00, gelten die folgenden zwei Ziffern als Ländervorwahl. Fehlt beides, nimmt der Shop die Vorwahl 49 für Deutschland an. Ländervorwahlen mit einer oder drei Ziffern, beispielsweise +1 oder +352, teilt diese Regel falsch auf. Nummern mit höchstens vier Zeichen übergibt der Shop nicht. Eine Prüfung per validations im Zusatzfeld fängt falsche Formate ab, bevor PayPal die Zahlung ablehnt.
Ohne clearingFields übernimmt der Shop Geburtsdatum und Telefonnummer aus der Rechnungsadresse. Dieses Verhalten ist nur noch für bestehende Shops vorgesehen und gilt als veraltet. Neue Einrichtungen nutzen Zusatzfelder.

payment.payPalCheckout - PayPal Checkout Konfiguration

Der Knoten payment.payPalCheckout konfiguriert den PayPal Checkout im Shop. Darunter beispielsweise die Aktivschaltung, die Einstellung des Modus (Live / Testmodus) und die Sprache. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.payPalCheckout (Deeplink-Übersicht)

Beispielkonfiguration

Parameterbeschreibung


payment.payPalCheckoutErrors - Fehlertexte zu abgelehnten PayPal-Zahlungen

Lehnt PayPal eine Zahlung ab oder scheitert die Prüfung des Shops, kehrt der Käufer in den Checkout zurück und sieht dort den Grund. Der Knoten payment.payPalCheckoutErrors legt fest, welcher Text dabei erscheint. Jedem Ablehnungsgrund, den PayPal meldet, ist ein eigener Parameter zugeordnet. Hinzu kommen Gründe aus den eigenen Prüfungen des Shops, die PayPal selbst nie meldet. Im Template steht der Grund unter $wsCheckout.problems.clearing zur Verfügung. Die Eigenschaft code enthält den Namen des Parameters, text den fertigen Text aus diesem Knoten. Meldet PayPal einen Grund, für den es hier keinen Parameter gibt, verwendet der Shop den allgemeinen Text aus checkout.clearingErrors. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.payPalCheckoutErrors (Deeplink-Übersicht)
**Fehlertexte sind schreibgeschützt.** Die Fehlercode-Felder auf dieser Seite enthalten den Namen eines Textbausteins (ws.error.<configId>.<errorCode>), nicht den Fehlertext. Gepflegt wird der Text ausschließlich im Textbaustein-Dienst des Admin-Interface – Änderungen an der Konfiguration werden beim Speichern abgewiesen, auch über die [REST API](/schnittstellen/admin-interface-api/api-referenz-konfiguration). E-Mail-Vorlagen sind nicht betroffen.
Nachfolgend ein Ausschnitt aus der Konfiguration für payment.payPalCheckoutErrors:

Parameterbeschreibung

Alle Parameter liegen unter errorCodes und sind vom Typ string. Jeder Parameter verweist auf einen Textbaustein mit der Bezeichnung ws.error.payPalCheckout.<Parameter>, beispielsweise ws.error.payPalCheckout.cardExpired. In der Tabelle steht der deutsche Standardtext. Dieser Text wird über einen Textbaustein realisiert.
Alles zu Textbausteinen in Konfigurationen finden Sie hier.
Von PayPal gemeldete Gründe Gründe aus den Prüfungen des Shops

payment.payPalPlus - PayPal Plus Konfiguration

PayPal Plus war eine integrierte Zahlungslösung für Online-Händler, die PayPal, Lastschrift, Kreditkarte und Kauf auf Rechnung in einem Modul gebündelt hat. Inzwischen wurde PayPal Plus durch das neue PayPal Checkout abgelöst. Die Integration wurde daher aus der aktuellen Software-Generation entfernt.Der Knoten payment.payPalPlus konfigurierte ehemals PayPal Plus im Shop. Darunter beispielsweise die Aktivschaltung, die Einstellung des Modus (Live / Testmodus) und die Sprache.Beispielkonfiguration
Parameterbeschreibung

payment.stripe - Stripe Konfiguration

Der Knoten payment.stripe konfiguriert Stripe als Zahlungsdienstleister. Darunter beispielsweise die Aktivschaltung, die Einstellung des Modus (Live / Testmodus) und die Sprache. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.stripe (Deeplink-Übersicht)

Beispielkonfiguration

Parameterbeschreibung


payment.stripeErrors - Fehlertexte zu abgelehnten Stripe-Zahlungen

Lehnt Stripe eine Zahlung ab, kehrt der Käufer in den Checkout zurück und sieht dort den Grund. Der Knoten payment.stripeErrors legt fest, welcher Text dabei erscheint. Jedem Ablehnungsgrund, den Stripe meldet, ist ein eigener Parameter zugeordnet. Der Shop wertet zuerst den genauen Ablehnungsgrund von Stripe aus (decline_code) und danach den allgemeineren Fehlercode (code). Im Template steht der Grund unter $wsCheckout.problems.clearing zur Verfügung. Die Eigenschaft code enthält den Namen des Parameters, text den fertigen Text aus diesem Knoten. Meldet Stripe einen Grund, für den es hier keinen Parameter gibt, verwendet der Shop den allgemeinen Text aus checkout.clearingErrors. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.stripeErrors (Deeplink-Übersicht)
**Fehlertexte sind schreibgeschützt.** Die Fehlercode-Felder auf dieser Seite enthalten den Namen eines Textbausteins (ws.error.<configId>.<errorCode>), nicht den Fehlertext. Gepflegt wird der Text ausschließlich im Textbaustein-Dienst des Admin-Interface – Änderungen an der Konfiguration werden beim Speichern abgewiesen, auch über die [REST API](/schnittstellen/admin-interface-api/api-referenz-konfiguration). E-Mail-Vorlagen sind nicht betroffen.
Nachfolgend ein Ausschnitt aus der Konfiguration für payment.stripeErrors:

Parameterbeschreibung

Alle Parameter liegen unter errorCodes und sind vom Typ string. Jeder Parameter verweist auf einen Textbaustein mit der Bezeichnung ws.error.stripe.<Parameter>, beispielsweise ws.error.stripe.insufficientFunds. Die deutschen Standardtexte sehen Sie im Textbaustein-Dienst. Dieser Text wird über einen Textbaustein realisiert.
Alles zu Textbausteinen in Konfigurationen finden Sie hier.

payment.transactionSettings - Transaktionseinstellungen (global)

Über den Knoten payment.transactionSettings werden die Aktionen festgelegt, die im Store-Backend für Zahlungen ausgeführt werden können, beispielsweise Rückzahlungen, Stornierungen, Aktualisierung des Status oder das Einziehen des Betrags. Für jeden Zahlungsanbieter wird konfiguriert, ob die jeweilige Aktion erlaubt ist und welche Eingaben dabei abgefragt werden. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.transactionSettings (Deeplink-Übersicht)

Beispielkonfiguration

Parameterbeschreibung


payment.* - Validierungs- und Prüfservices

Die fest vorgegebenen Validierungs- und Prüfservices für den Knoten payment werden in Validations und Services verwendet. Eine Übersicht ist hier zu finden: Validierungs- und Prüfservices Die Online-Clearing-Services, auf die das Feld onlineClearing einer Zahlungsart verweist, beschreibt ebenfalls die Seite Validierungs- und Prüfservices.