WL SIPS DOCS

Release 22.5

go directly to content

Search by keywords

Sofort integration

To search in the page use Ctrl+F on your keyboard

WL Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment upon shipping, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the Sofort means of payment integration into WL Sips.

This document is intended to help you implement the Sofort means of payment on your e-commerce site.

It includes:

  • functional information for you
  • implementation instructions for your technical team

To get an overview of the WL Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Sofort Banking is a very popular mean of payment by transfer in Germany, but also available for customers holding a bank account in the following countries: Austria, Switzerland, Poland, Italy, Spain, Belgium, Netherlands.

To pay with this mean of payment, customers will authenticate themselves on their online bank, then validate the payment.

Payment channels
Internet V Default payment channel
MOTO X
Fax X
IVS X
Means of payment
Immediate payment V Default method
End-of-day payment X
Deferred payment X
Payment upon shipping X
Payment in instalments X
Subscription payment X
Batch payment X
OneClick payment X
Currency management
Multicurrency acceptance V Sofort Bank: EUR only
Another bank: EUR, GBP, CHF
Currency settlement V

Sofort Bank: EUR only

Another bank: EUR, GBP, CHF

The response provided by Sofort during the payment is only temporary; it may vary the following days.

If your merchant account is at Sofort Bank, the response is confirmed from 1 to 10 days later. It is for this reason that the transaction changes from the TO_CONFIRM_CAPTURE status to the CAPTURED status, if Sofort confirms the payment definitively or to the CAPTURE_REFUSED status, if Sofort refuses definitively the payment. You will be notified by the automatic response of the payment final result.

If your merchant account is not at Sofort Bank, the response is never confirmed. You must contact your bank directly for the final payment result.

A transaction with CAPTURED status is considered reconciled, and Sofort guarantees that the funds have been transferred. This transaction appears then in the WL Sips Reconciliations reports, if you have these reports.

A transaction with CAPTURED status is considered reconciled. However, it's not a guarantee that the funds have been transferred to your account.

In order to use the Sofortüberweisung mean of payment on WL Sips, you need to create a Sofort "Gateway" project.

You must first create a Sofort customer account and then create a "Gateway Project":



Optional fields must be left blank. The only technical fields to be populated are:

  • automatic retransmission
  • set the time out to 600 seconds


You must send your configuration keys to Worldline so that WL Sips can make payments and transfers to your project (hidden example).



You can find this key in the "API key" table in the Sofort extranet.



WL Sips offers you two solutions to integrate the Sofort mean of payment:

  • Sips Paypage which directly acts as the payment interface with clients via their web browser.
  • Sips Office which gives you the possibility to display your payment pages and works through a server-to-server dialog.

The diagrams below explain the different transaction statuses according to the chosen capture mode:

  • Merchant account at the Sofort bank:

Description of the possible statuses for a Sofort transaction

In cancellation mode (captureMode = AUTHOR_CAPTURE), if the transaction is waiting for confirmation of authorisation, it is set to TO_CONFIRM_CAPTURE status. If the transaction is refused (responseCode not equal to 00), it is set to REFUSED status.
  • Merchant account outside the Sofort bank:

Description of the possible statuses for a Sofort transaction

In cancellation mode (captureMode = AUTHOR_CAPTURE), if the transaction is accepted, the transaction is set to CAPTURED status.

The payment process for Sips Paypage is described below:


Steps of a Sofort payment via Paypage

1) The customer proceeds with the payment. 2) They are redirected to the means of payment selection page hosted by WL Sips, they select Sofort. 3) They are redirected to Sofort page where they select the bank 4) They are then redirected to the online bank where they authenticate themselves. 5) They are redirected to a WL Sips page. 6) If they click on the back to eshop button, they are redirected to your website which triggers the manual response to be sent. 7) WL Sips sends an automatic response.

The following fields have a particular behaviour:

Field name Remarks/rules
captureMode Tհe value sent in the request is ignored.
The capture mode is forced to AUTHOR_CAPTURE.
captureDay Tհe value sent in the request is ignored.
The capture delay is forced to 0.
paymentPattern Tհe value sent in the request is ignored.
The payment type is forced to ONE_SHOT.
customerLanguage
Allows to choose the language used on WL Sips and Sofort pages.

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
paymentMeanBrand = SOFORTUBERWEISUNG
paymentMeanType = CREDIT_TRANSFER
You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud.
If you have not opted for the "new payment attempt" option (please read the Functionality set-up Guide for more details), you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to the number of attempts reached responseCode = 75 The customer has made several attempts that have all failed.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

The payment process for Sips Office is described below:


Steps of a Sofort payment via Paypage

1) The customer proceeds with the payment directly on your website. 2) You initialise the payment with WL Sips (creditTransfertInitialize). 3) You redirect the customer to the Sofort identification and payment pages (redirectionUrl). 4) Sofort redirects then the customer to their online bank to authenticate and make the payment. 5)You finalise the payment with WL Sips (creditTransfertFinalize). 6) You display the payment result to the customer.

The Sofort transfer initialisation is done by calling the creditTransfertInitialize method.

You have to populate the following specific fields in the initialisation request for a Sofortüberweisung transfer:

Field name Remarks/rules
captureMode Tհe value sent in the request is ignored.
The capture mode is forced to AUTHOR_CAPTURE.
captureDay Tհe value sent in the request is ignored.
The capture delay is forced at 0.
paymentPattern Tհe value sent in the request is ignored.
The payment type is forced to ONE_SHOT.
customerLanguage
Allows to choose the language used on WL Sips and Sofort pages.
paymentMeanBrand
Must be populated with Sofortüberweisung.

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Transfer initialisation accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
messageVersion = message version retrieved in response to the payment initialisation.
paymentMeanBrand = SOFORTUBERWEISUNG
redirectionData = redirection data retrieved in response to the payment initialisation.
redirectionUrl = URL-intent
Redirect the customer to redirectionUrl.
Transfer initialisation rejected
responseCode = <> 00
See the field errorFieldName, then fix the request.
If the problem persists, contact the technical support.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

The customer must be redirected to the redirectionUrl URL provided in response of the creditTransferInitialize method. This redirection consists in making a POST call on the redirectionUrl URL received in the response to the payment initialisation. The POST settings to be transmitted are redirectionData and messageVersion also received in the response to the payment initialisation.

At the end of the payment process, the customer is redirected to the URL provided in the merchantReturnUrl initialisation request. The following fields are sent to POST and must be retrieved to finalise the payment.

Field name Remarks/rules
responseCode Redirection process response code
redirectionData Redirection data retrieved in response to the payment initialisation.
messageVersion Message version retrieved in response to the payment initialisation.
amount Transaction amount in cents
merchantId Shop identifier
transactionReference Transaction reference
transactionId Transaction identifier
transactionDate Transaction date

The method used to finalise a transfer is CreditTransferFinalizeAndOrder.

This request must be sent for each transaction to have a status because there is no automatic notification. The request can be made when the customer navigates back or not from the website of his bank, within 30 minutes after the redirection.

You have to populate the following specific fields in the finalisation request for a Sofortüberweisung transfer:

Field name Remarks/rules
redirectionData Redirection data retrieved after the customer returns to your website (cf. Redirecting the customer to his online bank website).
messageVersion Message version retrieved after the customer returns to your website (cf. Redirecting the customer to his online bank website).

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
paymentMeanBrand = SOFORTUBERWEISUNG
You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

The following operations are available on Sofort transactions:

Cash management
Cancellation X Cancallation is not available because a transfer cannot be cancelled.
Validation X
Refund V Refund available on the total or partial amount of the transaction, only for the merchant accounts of the Sofort bank.
Duplication X
Credit X

Depending on your bank, the life cycle can differ. Two cases are possible:

  • Merchant account at Sofort bank:

The diagram below allows you to know which cash management operation is available when a transaction is in a given status:


Cash management operations availability

In case of refusal, the transaction changes from TO_CONFIRM_CAPTURE to CAPTURE_REFUSED status, in case of acceptance, the status is set to CAPTURED. When the status is CAPTURED, a total or partial refund can be made. In the case of partial refund the status remains CAPTURED and in the case of total refund the status becomes CREDITED.
  • Merchant account outside Sofort bank:

No cash transaction is allowed if your merchant account is not at Sofort Bank.

A Sofortüberweisung transaction may be refunded only if you have a bank account at Sofort Bank. All other accounts are not allowed to refund the transactions.

The refund is the only cash management operation available. The partial and full refunds are both allowed.

By default, a Sofortüberweisung transaction can only be refunded within 3 months. After this delay, Sofort deletes the issuer identifiers from the system (because of the laws relating to the protection of privacy in Germany). Please contact Sofort customer service if this delay must be extended.

A Sofortüberweisung transaction can only be refunded if the currency is Euro.

In order to use the refund feature, you must sign a proxy letter to authorise WL Sips to make credit transfers from your Sofort account.

The reports provided by WL Sips allow you to have a comprehensive and consolidated view of your transactions, cash operations, accounts and chargebacks. You can use this information to improve your information system.

The availability of Sofort transactions for each type of report is summarised in the table below:

Reports availability
Transactions report V
Operations report V
Reconciliations report V
Chargebacks report X
Note: for Sofort transactions, the paymentMeanBrand field is populated with the value SOFORTUBERWEISUNG.

You can view your Sofortüberweisung transactions and perform various cash management operations with Sips Office Extranet.



The Sofort extranet can only be used for viewing purposes. The Sofort ID field corresponds to the authorisationId field for WL Sips transactions and the payment reason field corresponds to the transactionReference field on WL Sips, reduced to 27 characters. Therefore, you can easily find your WL Sips transactions in the Sofort extranet.

Attention: all cash management operations on a Sofortüberweisung transaction must be carried out using WL Sips tools. A cash management action from a Sofortüberweisung merchant account may lead to an inconsistency of the transaction status between WL Sips and Sofort.

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration