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)
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:
- Create the field in
payment.paymentField. - Assign the field to the payment method under
additionalFields; seepayment.payment. - Output the field in the template and save it with the
CheckoutSetPaymentFieldsaction. The fields of a payment method are available in the template under$wsConfig.paymentsin thefieldsentry.
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 vianame, 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.
Remembering inputs
WithrememberInput: 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 theorder.paymentFields block. The key is the technical name of the field, the value is the customer’s input:
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 underonlineClearing.options.clearingFields:
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)
Below is an excerpt from the configuration for payment.payPalCheckoutErrors:
Parameter description
All parameters are located undererrorCodes 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
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)
Below is an excerpt from the configuration for payment.stripeErrors:
Parameter description
All parameters are located undererrorCodes 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.