Skip to main content
The payment node bundles the complete payment configuration of the shop, including individual payment methods (display, rules) and payment providers such as PayPal, Stripe, or Computop.

payment* - Basic structure

Below is the basic structure of the payment node

Parameter description


payment.computopHosted - Computop Hosted Payments

With payment.computopHosted, Computop can be integrated as a hosted payment page. The node controls, for example, operating mode (Live / Test), encryption, and the language / template of the payment page. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.computopHosted (Deeplink-Übersicht)

Example configuration (payment.computopHosted.creditcard)

Parameter description


payment.payment - Create payment methods

The payment.payment node bundles all payment methods of the shop. Here you can, for example, define whether a payment method is active, how it should be named and look in the checkout, which provider handles it, and which rules apply. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.payment (Deeplink-Übersicht)
Payment methods can be bound to a currency or region (e.g. Bancontact: only EUR, primarily Belgium). Which currencies and countries a payment method supports is determined by the payment service provider. An activated payment method is therefore offered regardless of the shop currency and may cause an error at the payment service provider. Before activation, check the provider documentation to see whether the payment method fits the currency and target country of your shop, and deactivate any methods that do not fit.
If the checkout spans multiple pages and the Stripe widget is to be loaded before the order overview, create a separate payment method with Stripe as the clearing service for Google Pay and for Apple Pay. The template can then refer to the selected wallet from the payment methods page onwards. The integration in the template is described in Stripe in the frontend.

Example configuration (payment.payment.paypalCheckout)

Parameter description


payment.paymentField - Additional fields for payment methods

Some payment methods require information that is not part of the address. PayPal purchase on invoice, for example, requires the buyer’s date of birth and phone number. With the payment.paymentField node, you create such additional fields. The shop requests them in the checkout together with the payment method and writes the inputs to the order data. From there, they can be exported to external systems like all other order data. You create an additional field in three steps:
  1. Create the field in payment.paymentField.
  2. Assign the field to the payment method under additionalFields; see payment.payment.
  3. Output the field in the template and save it with the CheckoutSetPaymentFields action. The fields of a payment method are available in the template under $wsConfig.payments in the fields entry.
Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.paymentField (Deeplink-Übersicht)

Example configuration (payment.paymentField.birthdatePayPal)

The example creates a required field for the date of birth. The value is remembered in the customer account and must match the format JJJJ-MM-TT (YYYY-MM-DD).
dataChecker.regex checks whether the entire value matches the expression. A date field always returns month and day with two digits, for example 1990-05-01. The expression must therefore allow leading zeros.

Parameter description

A field whose display conditions are not met is treated as non-existent. It does not appear in the template, is not checked and, even as a required field, does not block order completion.

Multiple fields with the same name

Because the shop addresses additional fields via name, multiple configuration nodes can have the same name. This lets you request the same information differently depending on the situation, for example with country-dependent selection lists or checks. The variants are then distinguished via displayConditions.
The display conditions of fields with the same name must be mutually exclusive. If two fields with the same name are visible at the same time, both write to the same value.

Remembering inputs

With rememberInput: true, the shop stores the entered value in the customer account after the order. This only applies to logged-in customers. For guest orders, the value remains in the current session and is not stored. The remembered value is not inserted automatically at the next checkout. The template decides whether to prefill the field with it. The value is available there as rememberedValue on the field; see $wsConfig.payments.

Additional fields in the order data

With the order, the shop writes the additional fields of the selected payment method to the order.paymentFields block. The key is the technical name of the field, the value is the customer’s input:
All fields assigned to the payment method are included. A field that was not displayed because of its display condition is included with an empty value or with an earlier input from the same session.

Example: PayPal purchase on invoice

For purchase on invoice, PayPal requires the buyer’s date of birth and phone number. You define which additional fields provide this information in the payment method under onlineClearing.options.clearingFields:
The shop passes the value of the additional field bday to PayPal as the date of birth and the value of phone as the phone number. In each case, you enter the technical name from name, not the ID of the configuration node. Both fields must also be assigned to the payment method under additionalFields; otherwise the checkout does not request them. For the phone number, the shop reads the country code from the beginning of the input. If the number starts with + or 00, the following two digits are treated as the country code. If neither is present, the shop assumes the country code 49 for Germany. This rule splits country codes with one or three digits incorrectly, for example +1 or +352. The shop does not pass on numbers with four characters or fewer. A check via validations in the additional field catches incorrect formats before PayPal rejects the payment.
Without clearingFields, the shop takes the date of birth and phone number from the billing address. This behavior is only intended for existing shops and is considered deprecated. New setups use additional fields.

payment.payPalCheckout - PayPal Checkout configuration

The payment.payPalCheckout node configures the PayPal Checkout in the shop. This includes, for example, activation, setting the mode (Live / test mode), and the language. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.payPalCheckout (Deeplink-Übersicht)

Example configuration

Parameter description


payment.payPalCheckoutErrors - Error texts for declined PayPal payments

If PayPal declines a payment or the shop’s check fails, the buyer returns to the checkout and sees the reason there. The payment.payPalCheckoutErrors node defines which text appears. Each decline reason reported by PayPal is assigned its own parameter. In addition, there are reasons from the shop’s own checks, which PayPal itself never reports. In the template, the reason is available under $wsCheckout.problems.clearing. The code property contains the name of the parameter, text the ready-made text from this node. If PayPal reports a reason for which there is no parameter here, the shop uses the general text from 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.
Below is an excerpt from the configuration for payment.payPalCheckoutErrors:

Parameter description

All parameters are located under errorCodes and are of type string. Each parameter refers to a text snippet named ws.error.payPalCheckout.<Parameter>, for example ws.error.payPalCheckout.cardExpired. The table shows the German default text, translated into English. Dieser Text wird über einen Textbaustein realisiert.
Alles zu Textbausteinen in Konfigurationen finden Sie hier.
Reasons reported by PayPal Reasons from the shop’s checks

payment.payPalPlus - PayPal Plus configuration

PayPal Plus was an integrated payment solution for online merchants that bundled PayPal, direct debit, credit card, and purchase on account in one module. In the meantime, PayPal Plus has been replaced by the new PayPal Checkout. The integration has therefore been removed from the current software generation.The payment.payPalPlus node formerly configured PayPal Plus in the shop. This included, for example, activation, setting the mode (Live / test mode), and the language.Example configuration
Parameter description

payment.stripe - Stripe configuration

The payment.stripe node configures Stripe as a payment service provider. This includes, for example, activation, setting the mode (Live / test mode), and the language. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.stripe (Deeplink-Übersicht)

Example configuration

Parameter description


payment.stripeErrors - Error texts for declined Stripe payments

If Stripe declines a payment, the buyer returns to the checkout and sees the reason there. The payment.stripeErrors node defines which text appears. Each decline reason reported by Stripe is assigned its own parameter. The shop first evaluates Stripe’s exact decline reason (decline_code) and then the more general error code (code). In the template, the reason is available under $wsCheckout.problems.clearing. The code property contains the name of the parameter, text the ready-made text from this node. If Stripe reports a reason for which there is no parameter here, the shop uses the general text from 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.
Below is an excerpt from the configuration for payment.stripeErrors:

Parameter description

All parameters are located under errorCodes and are of type string. Each parameter refers to a text snippet named ws.error.stripe.<Parameter>, for example ws.error.stripe.insufficientFunds. You can view the German default texts in the text snippet service. Dieser Text wird über einen Textbaustein realisiert.
Alles zu Textbausteinen in Konfigurationen finden Sie hier.

payment.transactionSettings - Transaction settings (global)

The payment.transactionSettings node defines which actions can be performed in the store backend for payments, for example refunds, cancellations, status updates, or capturing the amount. For each payment provider, it is configured whether the respective action is allowed and which inputs are requested for it. Die Einstellung kann über folgenden Link direkt im Admin-Interface geöffnet werden: https://<shop-domain>/admin/config/payment.transactionSettings (Deeplink-Übersicht)

Example configuration

Parameter description


payment.* - Validation and check services

The predefined validation and check services for the payment node are used in validations and services. An overview can be found here: Validation and check services The online clearing services referenced by the onlineClearing field of a payment method are also described on the Validation and check services page.