WL SIPS DOCS

Release 21.4

go directly to content
Search by keywords

Set-up guide

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

This document is a WL Sips feature setup guide. It explains how to use the available features in the various payment interfaces (Sips Paypage, Sips Office). It also summarises feature availability in each of the interfaces and provides detailed information on the potential impact on your WL Sips and/or acquirer configuration (requiring verification with the latter).

Specific guides look at the setup of particular features:

Means of payment \ Interfaces Sips Paypage Sips Office Sips Office Batch Sips In-App Sips Walletpage
CB yes yes yes yes yes
Visa yes yes yes yes yes
MasterCard yes yes yes yes yes
American Express yes yes yes yes yes
VPay yes yes yes yes yes
Maestro yes yes yes yes yes
Visa Electron yes yes yes yes yes
AcceptGiro yes no no no yes
Apple Pay no yes no no no
Bancontact yes yes no yes yes
Bancontact mobile yes yes no yes no
Floa Bank CB 3X yes no no no no
Floa Bank CB 4X yes no no no no
CACF yes no no no no
CACF 3X yes yes no no no
CACF 4X yes yes no no no
Cadhoc yes yes no no no
Cadocarte yes yes no no no
CUP card by Floa Bank no yes no no no
Carte Oney yes yes yes no yes
Carte Cadeau Oney yes yes no no no
Cetelem CPay (formerly Cetelem Aurore) yes no no no no
Cetelem 3X 4X CB yes no no no yes
Cetelem Presto yes no no no no
Chèque-Vacances Connect yes yes no no no
Cofidis Pay 5x10x20x yes no no no no
Cofidis 3xCB yes no no no no
Cofidis 4XCB yes no no no no
Cofinoga yes yes yes no no
Cofinoga 3XCB yes no no no no
Titres Restaurants Dématérialisés - Conecs yes yes no no no
China Union Pay yes no no no no
Diners yes no no no no
e-Chèques Vacances yes yes no no no
Facily Pay yes no no no no
Franfinance 3XWEB yes no no no no
Franfinance 4XWEB yes no no no no
Giropay yes no no no no
iDEAL (old contracts) yes yes no no no
iDEAL (new contracts) yes no no no no
Illicado yes yes no no no
Incasso yes no no no no
Japan Credit Bureau yes no no no no
Lepotcommun yes yes no no no
Lydia yes yes no no no
Lyf Pay yes no no no no
Masterpass
(for future usage)
yes yes no no no
Oney 3x 4x yes no no no no
Paybutton ING yes no no no no
Paybutton KBC/CBC Online yes no no no no
Paylib yes yes no no no
PayPal yes yes no no yes
Paytrail yes no no no no
Rembours yes no no no no
SEPA Direct Debit (SDD) yes yes yes no no
Sofortüberweisung yes yes no no no
Spiritofcadeau yes yes no no no
Visa Checkout yes yes no yes no

Means of payment available (yes) / Means of payment unavailable (no)

Features activation may require configuration on the WL Sips and/or acquirer side.

  • WL Sips configuration: activation or deactivation of the feature requires a change of configuration on the WL Sips platform and may involve, eventually, an amendment of the acceptance contract.
  • Acquirer verification: activation or deactivation of the feature may involve an amendment of the acquisition contract.You need to check with your acquirer.

Use of a feature may also involve the addition of certain parameters in the payment request and a possible change of connectors.

When you register, Worldline makes available on Sips Download a secret key which allows to secure the exchanges between your site and the WL Sips server. A secret key compromised (and used by a malicious third party) might disrupt the regular operation of your shop and might in particular generate unauthorised sales or cash transactions (e.g. refunds). In the event that a secret key is compromised, you are required to ask as quickly as possible for its revocation then for its renewal via Sips Download.

To ensure compliance with the PCI DSS standard, an alerting system is set up to warn you that your secret key expires and so to renew it via the Sips Download interface. This alerting is done in 3 steps by sending informative e-mails which are by default set as follows:

  • 1st alert 90 days before the key expiry date – main recipients: your Administrator and Technical contacts
  • 2nd alert 45 days before the key expiry date – main recipients: your Administrator and Technical contacts; secondary recipient: your Account Manager
  • 3rd alert 20 days before the key expiring date– main recipients: your Administrator and Technical contacts; secondary recipient: your Account Manager

You may request different thresholds to be set for the sending of alert e-mails. To do so, please contact our technical support.

This alerting process terminates for a given key if it is disabled before the expiry date or if the expiry date is exceeded.

This management of your secret keys allows you to be autonomous in the management of your keys by validating the actions yourself, while taking responsibility.

Two transaction identification modes are available on WL Sips 2.0 : the "TransactionReference" mode and the "TransactionId" mode. The difference between the two modes is the identification scope: the TransactionReference must be unique throughout the life of the shop, whereas the TransactionId must be unique for the day.

An option also lets you choose the generation mode:

  • you supply the transaction ID in the payment request or
  • you let WL Sips generate it automatically and you retrieve it in the response
Note: the TransactionReference is the default identification mode, the transactionId 1.0 has been continued in 2.0 to facilitate the migration of 1.0 merchants to 2.0.

During the creation of a transaction and depending on the selected mode, WL Sips accepts or rejects the creation and generates complementary IDs.

There are various possible cases:

Table 1. Shop in TransactionReference mode - The merchant logs into WL Sips with a transactionReference that they generated
Data Transaction creation via:
Sips Paypage Sips Office Sips Office Extranet
transactionReference supplied by the merchant Standard use case Standard use case proposed by WL Sips, can be amended and is displayed in red
transactionId supplied by the merchant Rejection Code = 12 Rejection Code = 12 N/A
transactionId absent OK OK N/A
transactionReference absent Rejection Code = 12 Rejection Code = 12 Rejection Code = 12
Complementary reference generated by WL Sips s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate s10TransactionId s10TransactionIdDate
Response content s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 2. Shop in TransactionReference mode - The merchant logs into WL Sips without a TransactionReference (Tref auto)
Data Transaction creation via:
Sips Paypage Sips Office Sips Office Extranet
transactionReference generated by WL Sips Standard use case N/A generated by WL Sips and displayed in red
transactionId supplied by the merchant Rejection Code = 12 N/A
transactionId absent OK N/A
transactionReference supplied by the merchant Rejet Code = 12 Rejection Code = 12
Complementary reference generated by WL Sips transactionReference s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate
Response content s10TransactionId s10TransactionIdDate transactionReference
Table 3. Shop in TransactionId mode - The merchant logs into WL Sips with a transactionId that they generated
Data Transaction creation via:
Sips Paypage Sips Office Sips Office Extranet
transactionId supplied by the merchant Standard use case Standard use case proposed by WL Sips, can be amended and is displayed in red
transactionId absent Rejection Code = 12 Rejection Code = 12 Rejection Code = 12
transactionReference supplied by the merchant Rejection Code = 12 Rejection Code = 12 N/A
transactionReference absent OK OK N/A
Complementary reference generated by WL Sips transactionReference transactionReference transactionReference
Response content s10TransactionId s10TransactionIdDate transactionReference s10TransactionId s10TransactionIdDate transactionReference
Table 4. Shop in TransactionId mode- The merchant logs into WL Sips without a TransactionId (Tid auto)
Données Transaction creation via:
Sips Paypage Sips Office Sips Office Extranet
transactionId generated by WL Sips Standard use case N/A generated by WL Sips and displayed in red
transactionId supplied by the merchant Rejection Code = 12 N/A
transactionReference supplied by the merchant Rejection Code = 12 N/A
transactionReference absent OK N/A
Complementary reference generated by WL Sips s10TransactionId s10TransactionIdDate TransactionReference s10TransactionId s10TransactionIdDate TransactionReference
Response content s10TransactionId s10TransactionIdDate transactionReference

For cash management operations, the identification method of a transaction is not limited to the mode selected at creation.

The tables below outline the various possibilities.

Table 5. Shop in transactionReference mode - Original transaction generated with a transactionReference
Data Cash management
transactionId supplied by the merchant OK
transactionReference supplied by the merchant OK
Consistent transactionReference and transactionId supplied by the merchant OK
transactionReference and transactionId not referencing the same transaction supplied by the merchant Rejection Code = 12
New transaction (duplication, recycling and cardholder credit) See transaction creation table above
Table 6. Shop in transactionId mode - Original transaction generated with a transactionId
Data Cash management
transactionId supplied by the merchant OK
transactionReference supplied by the merchant OK
Consistent transactionReference and transactionId supplied by the merchant OK
transactionReference and transactionId not referencing the same transaction supplied by the merchant Rejection Code = 12
New transaction (duplication, recycling and cardholder credit) See transaction creation table above

The s10TransactionId, s10TransactionIdDate and transactionReference fields appear in the transactions, operations, reconciliations and chargebacks reports, whatever the transaction identification mode.

For duplication and recycling operations, the original transaction is identifiable via the "s10FromTransactionId", "s10FromTransactionIdDate" and "fromTransactionReference" fields of the transactions report.

For further details, please read the Sips Paypage customisation guides.

The WL Sips means of payment selection page is not displayed automatically. It can be managed either on your merchant website or by WL Sips. An option lets you automatically display this page by WL Sips.

Note: the display of the WL Sips means of payment selection page is useless if the brand selection option (MIF) is activated on your webshop and if you only offer the CB, VISA and Mastercard means of payment.

However, in cases where the means of payment are not of the same type (card and Paypal for example), the selection page is displayed automatically. When several means of payment are configured in your contract, you can filter those that will be displayed in the means of payment selection page via the paymentMeanBrandList field:

  • A single means of payment: the means of payment selection page is not displayed,
  • A list of means of payment: the means of payment are displayed in the feed order of the; field
  • Blank field: all configured means of payment are displayed.

WL Sips displays the means of payment matching simultaneously with

  • the list of means of payment provided in your configuration

and

  • the transaction data (checking the transaction currency, for example).

If no compatible means of payment is found, WL Sips refuses the transaction.

Sample means of payment selection page:


Payment-mean-selection

Table 7. Summary
Available connectors Sips Paypage
WL Sips configuration YES Means of payment selection page not displayed by default.
Acquirer checking NO
Parameter in the payment request YES paymentMeanBrandList: Optional, choice of means of payment to be displayed. Possible values are listed in the data dictionary.

The payment confirmation page or "payment ticket" is displayed by default by WL Sips. However, you can choose to display it yourself on your website by using the elements provided in the response message sent to the response URL (normalReturnUrl). You can also decide dynamically, depending on the context of the transaction, not to display the ticket produced by WL Sips.

Table 8. Summary
Available connectors Sips Paypage
WL Sips configuration YES WL Sips ticket displayed by default
Acquirer checking NO
Parameter in the payment request YES paypageData.bypassReceiptPage: indicator that lets you hide the ticket page during payment.

You can decide on the maximum number of attempts to enter the PAN:

  • when a customer accesses the payment details entry page
  • or a user makes an entry via Sips Office Extranet

Beyond this limit, the transaction is refused and the following message is displayed :


Number-payment-attempts

Table 9. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration YES Three attempts by default on the payment pages and on Sips Office Extranet.
Acquirer checking NO
Parameter in the payment request NO

Usually, a new payment attempt is proposed to the customer in case of an invalid PAN. This additional option allows to extend the new payment attempts on other cases of refusal :

  • acquirer rejection (except fraud)
  • 3-D Secure authentication failure
  • fraud engine rejection (except fraud)

The maximum number of payment attempts is set in your merchant configuration (see previous paragraph "Number of payment attempts").

The following message is displayed to your client:


Payment-retry

Note: if the payment returns an acquirer code 03 (invalid acceptor) then all the means of payment attached to this same acquirer contract will not be offered during the new payment attempt.

Example of means of payment linked to a same acquiring contract: CB, Visa, Mastercard, Paylib, Masterpass.
If no other means of payment can be offered, the payment will be definitely refused witthout possible retry.

Table 10. Summary
Available connectors Sips Paypage
WL Sips configuration YES
Acquirer checking NO
Parameter in the payment request NO

You may choose to get an automatic notification sent to your website in case of a technical error. This type of error happens in exceptional circumstances.

Table 11. Summary
Available connectors Sips Paypage
WL Sips configuration YES
Acquirer checking NO
Parameter in the payment request NO

The customer has a 15-minute period of inactivity to carry out the payment. Beyond this allotted time, the user session expires and the customer is not able to complete their purchase. This period is set to 15 minutes in accordance with the PCI DSS regulation (condition 8.1.7).

In addition to this regulatory limit, you have the option (business session timeout) of proposing a maximum period of time spent on the WL Sips payment pages. This period begins when the customer arrives on the WL Sips payment pages.

Table 12. Summary
Available connectors Sips Paypage
WL Sips configuration YES
Acquirer checking NO
Parameter in the payment request NO

The name of the webshop configured in WL Sips can be displayed in the banner on the payment page.


Display-store-name

Table 13. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration YES Display of webshop name not activated by default
Acquirer checking NO
Parameter in the payment request NO
Entry of card number in seperate blocks

Card number entry can be divided into blocks of four numbers. In the case of Amex and BCMC, this option is adapted to the length of the card number.


card-number-seperate-blocks

Table 14. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration YES
Card number entry in separate blocks not activated by default
Acquirer checking NO
Parameter in the payment request NO
Entry of cardholder name

In order to secure the validity of the entry, an option allows the display of a mandatory field below the card information entry area, asking the cardholder to enter their name.

This option is available only for card payment.

This data is sent to some acquirers (mainly UK acquirers) in the authorisation request. However, this entry can be used to discourage potential fraudsters.


Card-horlder-name

Table 15. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration YES Entry of cardholder name not activated by default
Acquirer checking NO
Parameter in the payment request NO

This page is displayed in the event of a payment initialisation error only via the POST connector (incorrectly formatted query for example).


Error-display-initialization

The redirection button redirects the user to the merchant’s website (with the manual response). The display of the redirection button is configurable:

Table 16. Summary
Available connectors Sips Paypage (POST)
WL Sips configuration YES Parameter “Display the error page”
Acquirer checking NO
Parameter in the payment request YES manualErrorResponseInitPOST: merchant's URL to return to the website in case of payment initialisation error.

At the same time, an automatic response can be sent. The sending of this automatic response is configurable:

Table 17. Summary
Available connectors Sips Paypage (POST)
WL Sips configuration YES Parameter “Display the error page”
Acquirer checking NO
Parameter in the payment request YES automaticErrorResponseInitPOST: merchant's URL to receive the automatic response in case of payment initialisation error.
Hiding the entry of sensitive data

Sensitive information (card number and CVV) can be hidden in the means of payment entry page.


Hiding-sensitive-information



If this functionality is activated, then sensitive information will also be hidden if you create a transaction using a payment card in the Sips Office Extranet interface.


pan-hidden-soe

Table 18. Summary
Available connectors Sips Paypage, , Sips Walletpage
WL Sips configuration YES Hiding sensitive information on entry page is not activated by default
Acquirer checking NO
Parameter in the payment request NO

WL Sips payment pages can be integrated into a webshop page. This has no impact on your pages and you can use this feature without any WL Sips configuration.

For more information, please read the Sips Paypage iFrame user guide.

Table 19. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request NO

To select your payment channel, you must fill in the orderChannel field in the payment request. This information is important because it determines the rules of acceptance and acquisition for transaction processing.

To use the internet channel, you must subscribe to a VADS (secure distance selling) contract with the acquirer.

Table 20. Summary
Available connectors Sips Paypage, Sips Office Sips Office Batch
WL Sips configuration YES
Acquirer checking YES mandatory VADS contract
Parameter in the payment request YES orderChannel: INTERNET

When using the MOTO (Mail Order Telephone Order), MAIL_ORDER or TELEPHONE_ORDER channels, the transaction is processed in distance selling acceptance. You have to subscribe to a VAD contract (distance selling) with the acquirer.

Note: On connectors side, it is adviced using MAIL_ORDER or TELEPHONE_ORDER instead of MOTO.
Table 21. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch
WL Sips configuration YES
Acquirer checking YES mandatory VAD contract supporting MOTO
Parameter in the payment request YES orderChannel:

MOTO
TELEPHONE_ORDER
MAIL_ORDER
FAX

The IVR (Interactive Voice Response) channel is assimilated to the MOTO channel. The transaction is processed in distance selling acceptance. You have to subscribe to a VAD contract (distance selling) with the acquirer, supporting MOTO channel.

Table 22. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES (MOTO channel configured)
Acquirer checking YES mandatory VAD contract supporting MOTO
Parameter in the payment request YES orderChannel: IVR

Use of the mobile application does not require any acquirer configuration. To find out more about this connector, please read the Sips In-App JSON documentation.

Table 23. Summary
Available connectors Sips In-App
WL Sips configuration YES
Acquirer checking NO Assimilated to the internet channel
Parameter in the payment request YES orderChannel: INAPP

The paymentPattern, captureMode and captureDay fields let you set the payment collecting methods.

To find out more about the availability of these methods for each means of payment, please refer to their integration guides.

In the case of end-of-day payment, all transactions accepted during the day are sent for payment collection in the evening. This method applies to the means of payment functioning on dual-message mode (a message for authorisation and a message for collection).

If this method is not supported by a specific means of payment,WL Sips overrides the captureMode parameter with the default value of the means of payment in question (for more information, please read the integration guides of the means of payment).

Table 24. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: AUTHOR_CAPTURE
  • captureDay: 0 (0 deferred day, evening collecting)

In the case of deferred payment, payment collection of the transaction is done N days after online acceptance.

The validity period of the authorisations of the means of payment is set out in the contract between you and the acquirer (six days by default for CB, VISA and Mastercard).

Depending on the validity period of the authorisation, the number of days of deferred collecting that is communicated in the payment request can have an impact on the transaction life cycle:

  • 1st case: the deferred payment is lower or equal to the validity period of the authorisation. The authorisation given by the acquirer is always valid for the total amount of the initial transaction. If the transaction is not cancelled, it is paid on the date of the transaction +N days.
  • 3-D Secure specific case: in order to benefit from the liability shift during a 3-D Secure transaction, the deferred payment cannot be greater than the maximum validity period of the authorisation given by the acquirer. If needed, WL Sips overrides the payment deferral if the value you enter is greater.
  • 2nd case: the deferred payment is greater than the validity period of the authorisation. The authorisation given during the online purchase by the acquirer is no longer valid during the payment. Depending on the acquirer, WL Sips chooses one of the following scenarios:
    • Acquirer is compliant with the "Account verification" feature: an account verification is sent to the acquirer with the objective to check the transaction card number before performing an authorisation. If the response is positive, WL Sips sends the authorisation request with the real amount of the transaction at D+N. In the case of acceptance, the transaction is sent for collecting.
    • Acquirer is not compliant with the "Account verification" feature: the procedure is the same, but the information request made online is replaced by an imprint (an authorisation request of a small amount).
      As a result,WL Sips makes two authorisation requests:
      • The first authorisation request (of a small amount), called the imprint, to check the card during online acceptance.
      • The second authorisation request for the real amount before payment collecting.

If the means of payment is not compatible with the deferral you have requested, WL Sips overrides the captureDay field.

Table 25. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: AUTHOR_CAPTURE
  • captureDay: N (Number of days of deferred payment)
Note: the account checking is a regulatory development of CB, VISA and MASTERCARD and replaces the imprint. This feature is subject to the acquirer compliance.

In the case of payment upon shipping, the transaction is sent for payment collecting following your validation. You indicate the validity period for your transaction in the captureDay field. If you do not validate a given transaction before this period ends, this transaction expires. If you forget to validate within the periods, you can submit the transaction again via the duplication operation. You can validate all or part of the transaction amount, but it is not possible to validate an amount greater than the initial transaction amount.

If the VALIDATION method is not supported by the means of payment, WL Sips overrides it with the default payment modality.

Table 26. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES VALIDATION option to activate
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: VALIDATION
  • captureDay: N (validity period before the validation)

The payment in instalments is adressed to the merchant who want to offer payment facilities to their customers.

To get a functional description and implementation instructions for the payment in instalments, please refer to the payment in instalments guide.

In the case of immediate payment, the transaction is captured during online authorisation. This payment method is not used very frequently and only for means of payment supporting single-message mode (a single message for authorisation and payment).

If this method is not supported by the means of payment, WL Sips overrides the captureMode parameter with the default value corresponding to the means of payment in question (for more information, see the means of payment integration guides).

The means of payment supporting this mode are the following:

  • Bancontact
  • Bancontact mobile
  • BCACB 3X 4X
  • Cadhoc
  • Cadocarte
  • Carte Cadeau Oney
  • Cetelem 3X 4X CB
  • Cetelem Presto
  • Chèque-Vacances Connect
  • Cofinoga 3XCB
  • China Union Pay
  • Diners
  • e-Chèque Vacances
  • Giropay
  • iDEAL
  • Illicado
  • Japan Credit Bureau
  • Lepotcommun
  • Lydia
  • Paybutton ING
  • Paybutton KBC/CBC Online
  • Pay By Bank
  • Paytrail
  • Sofortüberweisung
  • Spiritofcadeau
Table 27. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request YES
  • captureMode: IMMEDIATE
  • captureDay: 0

Batch payment is a deferred exchange of information (in file mode) between you and WL Sips. It allows you to create transaction and/or operation files and then upload them to a secure WL Sips FTP Account.

It is therefore different from a number N of information communicated in real time (transaction mode).

File mode:


File-mode

  1. You have a number N of individual payment transactions and/or operations (N1, N2, N3, N4, etc.).
  2. Based on the Sips Office Batch specifications, you create a 'request' file containing these transactions and/or operations, and upload this file to a secure WL Sips FTP account.
  3. WL Sips performs rights and file consistency checks (format, size), then processes the information contained in this file and sends authorisation requests to the acquirers.
  4. The acquirers process the authorisation requests received and send the responses to WL Sips.
  5. WL Sips creates the 'response' file containing the responses to payments and/or transactions and uploads this file to your secure WL Sips FTP account.
  6. You download the 'response' file via your secure WL Sips FTP account and then integrate this file into your own information system.

Batch payment proves particularly useful if you have to process a very large number of flows since it saves you from having to provide a real-time response to your customers.

Table 28. Summary
Available connectors Sips Office Batch
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request N/A

The acquirer's authorisation remains valid for a certain time (six days by default for CB, VISA and Mastercard):

  • During this period, the transaction is sent for collecting with the authorisation carried out online.
  • Beyond this period, a new authorisation request is sent to the acquirer prior to payment collecting.

The validity period may depend on the acquisition contract concluded between you and the acquirer, this is why an option lets you fix the authorisation period associated with your acquisition contract. This feature is available only for certain means of payment. For more information, see the implementation guides.

Table 29. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES By default six days for CB / Visa / Mastercard cards
Acquirer checking YES
Parameter in the payment request NO

In the case of multi-currency transactions, acceptance relates to the customer's currency, but payment is settled in your currency.

You must subscribe to this option with the acquirer.

The acceptance stages for multi-currency transactions are as following:

  1. You must manage the price of your online sales in several currencies.
  2. When you submit the transaction to the WL Sipsserver, you fill in the currency you want in the currencyCode field.
  3. The transaction is sent for authorisation and for payment collecting with the same currency code.
  4. During payment acquisition, the acquirer converts the transaction into your settlement currency.
Table 30. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES The accepted currencies must be defined in the WL Sips configuration.
Acquirer checking YES
Parameter in the payment request YES currencyCode: Transaction currency code. The possible values are listed in document Data dictionary.

In the case of settlement in various currencies, acceptance and settlement are done in the same currency.

You specify the code for the currency used by the customer in the payment request. You must have an acquisition contract and a bank account in the concerned currencies.

Note: to implement this advanced feature, please contact the technical support.
Table 31. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES The accepted currencies must be defined in the WL Sips configuration.
Acquirer checking YES Acquisition contract with settlement in various currencies.
Parameter in the payment request YES currencyCode: transaction currency code. The possible values are listed in the data dictionary.

settlement-in-different-currencies

Dynamic currency conversion (DCC) is a financial service for Visa and Mastercard cardholders. It lets the customer pay in their currency and the merchant to be paid in theirs.

DCC enables you and the local bank, which is the acquirer (handles payment in your name), to take advantage of the exchange fees normally added to such transactions by VISA and Mastercard and the international issuing banks. You always receive the settlement in your basic currency.

To use the Dynamic Currency Conversion (DCC), you must:

  • subscribe to an acquisition contract with the DCC option.
  • subscribe to an exchange rate service.
  • request the DCC option when enroling in the WL Sips service.
Note: to implement this advanced feature, please contact the technical support.
Table 32. Summary
Available connectors Sips Paypage
WL Sips configuration YES The accepted currencies must be defined in the WL Sips configuration and agreed with the acquirer and the exchanger.
Acquirer checking YES
Exchange contract YES
Parameter in the payment request YES currencyCode: indicate in this field the code of your basic currency. Possible values are listed in the data dictionary.

3-D Secure is a mandatory authentication protocol designed to reduce the risk of payment fraud on the Internet. Its purpose is to ensure that the card is used by its true owner. In addition to this security aspect, 3-D Secure allows you to benefit from the liability shift to the bank issuing the card, according to rules issued by the CB, VISA, MASTERCARD, AMEX and Bancontact networks.

For a detailed functional description and implementation details, please consult the 3-D Secure guide.

You have the possibility to send your authentication requests or authorisation requests to a PSP other than WL Sips, via the new version of the Sips Office connector.

Two use cases are possible:

  • You send your authentication request to WL Sips, in return you receive the 3-D Secure technical data. Then, you send your authorisation request to another PSP with 3-D Secure technical data in order to benefit from the payment guarantee.
  • You forward your authentication request to another PSP that can return the 3-D Secure technical data. Then, you send your authorisation request to WL Sips with 3-D Secure technical data in order to benefit from the payment guarantee.

For more information, please refer to the 3-D Secure guide.

SafeDebit security allows you to guarantee the payment of Sepa Direct Debit (SDD) in BtoC. This applies to all instalments, not only to the first payment. For this, you need to sign a contract with SSP (Score & Secure Payment).

Risk taking is an option you can subscribe to that allows you to force the creation of a mandate and any associated SDD. Forced payments via this option will not be guaranteed and therefore can not be compensated in case of an outstanding payment.

Note: an unsecured SDD payment will be considered declined if you have not subscribed to the risk-taking option.
For more information, please refer to our SDD integration guide.
Table 33. Summary
Available connectors Sips Paypage,Sips Office Extranet,Sips Office et Sips Walletpage
WL Sips configuration NO Actived if subscription to SSP
Acquirer checking NO
Parameter in the payment request NO Risk taking is managed at your level

Recurring payment defines the rules and conditions for the payment of a service over a given period, validated between the merchant and their client. Using recurring payment is a good way for paying services linked to subscriptions.

In its use case, there are two phases in recurring payment:

  • 1st phase: the collection of card details is done with the customer being present and is associated or not with a payment. This card information will be used for the following payments under the agreement between you and the customer.
  • 2nd phase: the Nth payments are sent without customer action, using card information stored during the 1st phase.

Supported means of payment: CB, Visa, Mastercard, American Express, Bancontact and SDD.

3-D Secure for card recurring payments

To secure recurring payments, it is mandatory to do the initial transaction (first payment) in 3-D Secure mode in order to authenticate the card holder. The Nth following payments are not in 3-D Secure mode because the card holder is not present.

Processing recurring payments according to PCI requirements

WL Sips allows you to use card information in a secure way, avoiding PCI constraints linked to card data storage. It is possible to send the Nth payments using several ways:

  • duplicate the initial transaction
  • payment via a Wallet (card stored in the wallet)
  • payment via a Token (card tokenised)
Attention: you have to inform your customers that you store their information and you have to inform them about the terms of recurring payments (duration, amount, periodicity…)

Details on how to handle subscription payments using duplication method is fully described on subcription payment using duplication guide.

Recurring payment via Wallet is proposed by the WL Sips subscription solution.

Please refer to the document subscription to have a functional description and to get the subscription payment implementation methods.

Here are the main use cases:

Saving a payment mean in the wallet during a payment via Sips Paypage

Via Sips Paypage, you can ask for the automatic enrollment of the payment mean in the wallet when the payment is accepted.

Attention: If the payment mean used is a card, you must keep track of the schemeTransactionIdentifier returned in response. You will have to transmit this value in the field InitialSchemeTransactionIdentifier for the recurring payments to chain them with the initial transaction (PSD2).
Table 34. Summary
Available connectors Sips Paypage
WL Sips configuration YES Automatic enrolment option in the wallet when a Sips Paypage payment is accepted.
Acquirer checking NO
Parameter in the request

YES
  • merchantWalletID: Wallet Id
  • paymentPattern: RECURRING_1
Reporting

  • Transactions report: YES
  • Operations report: NO
  • Sips Office Extranet: YES

Saving the payment mean in the wallet via Sips Walletpage without any payment

Via the Sips Walletpage interface you may can your customer to create a wallet by adding a payment mean.

This interface can no longer be used to set up a subscription with a card because as there is no payment involved, you will not receive any chaining identifier on response. Therefore, you will not be able to provide it on the recurring payments.

Table 35. Summary
Available connectors Sips Walletpage
WL Sips configuration YES Sips Walletpage option
Acquirer checking YES Recurring option
Parameter in the request

YES
  • merchantWalletID: Id in which the PAN or the mandate will be stored
  • walletActionNameList: ADDPM to add a payment mean
  • PaymentMeanBrandList: SEPA_DIRECT_DEBIT
Reporting

  • Transactions report: NO
  • Operations report: NO
  • Sips Office Extranet: NO

Saving a mandate in the wallet via the addDirectDebit method of Sips Office without any payment

Via the Sips Office or Sips Office Batch interfaces, you may create a wallet for your customer with their mandate Id.

Table 36. Summary
Available connectors Sips Office,
WL Sips configuration YES Wallet option
Acquirer checking YES Recurring option
Parameter in the request YES
  • merchantWalletID: wallet Id
  • mandateId: mandate Id
  • paymentMeanBrand: SEPA_DIRECT_DEBIT
Reporting

  

  • Transactions report: NO
  • Operations report: NO
  • Sips Office Extranet: NO

For the Nth payments, use the walletOrder method entering the wallet id in the merchantWalletID field.

Attention: If the payment mean associated to the wallet is a card, you have to set the field initialSchemeTransactionIdentifier with the value of the schemeTransactionIdentifier you received when the subscription was set up.
Table 37. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking YES Recurring option
Parameter in the request YES
  • paymentPattern: RECURRING_N
  • merchantWalletID: Id of the wallet in which the payment mean is stored
  • initialSchemeTransactionIdentifier : chaining identifier received when the subscription was set up (only applicable if the payment mean is a card)
Reporting

  

  • Transactions report: YES
  • Operations report: NO
  • Sips Office Extranet: YES
Note: the wallet is limited to one means of payment to ease the recurring payment. (1 wallet = 1 means of payment).

You only have to manage the wallet Id and not the Id of the means of payment stored in the wallet.

For the first payment, you indicate in the request that it is the first payment of a recurring payment. You have to subscribe to the token option of the WL Sips solution. In return, you receive a token that you will use for future recurring payments. During a 3-D Secure kinematic, the token is also returned at the check enrollment step by the Sips Office and Sips In-App connectors.

Attention: You must keep track of the schemeTransactionIdentifier returned in response. You will have to transmit this value in the field InitialSchemeTransactionIdentifier for the recurring payments to chain them with the initial transaction (PSD2).
Table 38. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App, Sips Office Extranet
WL Sips configuration YES Token option
Acquirer checking YES Recurring option
Parameter in the payment request YES paymentPattern: RECURRING_1
Reporting

  

  • Transactions report: YES
  • Operations report: NO
  • Sips Office Extranet: YES

For the Nth payments, you send in the request the token given back during the first transaction.

Attention: You have to set the field initialSchemeTransactionIdentifier with the value of the schemeTransactionIdentifier you received when the subscription was set up.
Table 39. Summary
Available connectors Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES Token option
Acquirer checking YES Recurring option, WIP option for Bancontact
Parameter in the payment request YES Via Sips Office or Sips Office Batch connector:
  • paymentPattern: RECURRING_N
  • panType: TOKEN_PAN
  • cardNumber: <token> token value
  • cardExpiryDate: card expiry date
  • cardEffectiveDate: if the card and the acquirer is from UK
  • cardSequenceNumber: if the card and the acquirer is from UK
Via Sips In-App connector (at payment request initialization):
  • paymentPattern: RECURRING_N
  • tokenPan: <token> token value
  • initialSchemeTransactionIdentifier : chaining identifier received when the subscription was set up
Reporting

  

  • Transactions report: YES
  • Operations report: NO
  • Sips Office Extranet: YES
Note: the token is valid as long as the card is valid. In case of an expired token, the customer will have to provide their new card information.

The token applies for CB, VISA et MASTERCARD cards.

OneClick payment is for merchants who want to ease the payment for their customers.

This service allows customers to register their payment details in a secure area called Wallet and thus avoid having to re-enter this information for future payments.

OneClick payment simplifies the payment act, improves the user experience particularly for mobile purchases, and thus increases the conversion rate.

For a functional description and the implementation methods of the OneClick payment, please read the OneClick document.

Transaction life cycles differ depending on the means of payment, so the new status of the transaction can differ as well. The detailed life cycles are available in the means of payment integration guides.

Tip: if you receive a response due to a technical error (responseCode 90 or 99) or a transaction status refusal (responseCode 24) in response to your cash management operation, we advise you to try again.

You may cancel non captured transaction either partially or totally by using the Cancel function available in the Sips Office, Sips Office Batch and Sips Office Extranet interfaces.

For CB, Visa and Mastercard means of payment, the cancellation operation is no longer possible on a transaction as soon as its bank remittance processing is carried out.

Example: if a transaction (CB, Visa or Mastercard) is carried out on day 1 (D), with captureDay set with 2 and captureMode set with AUTHOR_CAPTURE, it will not be possible to cancel the transaction from day 3 (D+2) 10:00 p.m. CET onwards.


Cancel

For most other means of payment, the cancellation operations are unavailable every day during the transaction remittance process to the bank (please read appendix 3 ), even on transactions not included in the remittance file.

The process duration may vary depending on the number of transactions to sent for remittance.

It is possible to know a transaction settlement date via Sips Office Extranet, via the reports or via the Sips Office getTransactionData function (captureLimitDate field).

In the case of a complete cancellation, the transaction status is set with "cancelled" (transactionStatus CANCELLED), but for a partial cancellation, the status remains unchanged.

The below checks are carried out:

  • You have the right of cancellation. If you do not, a responseCode 40 is returned.
  • The transaction exists in our database. If it does not, a responseCode 25 is returned.
  • The transaction status is "TO_CAPTURE" or "TO_VALIDATE" or "TO_AUTHORIZE" or "TO_CHALLENGE". If not, a responseCode 24 is returned. You may consult the remittance hours per acquirer / private in Appendix 3.
  • The amount to cancel is equal or lower than the transaction amount. If it is not, a responseCode 51 is returned.
  • No cash management operation is already in progress on the transaction. Otherwise, a responseCode 24 is returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 40. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  • Transactions report: NO
  • Operations report: YES, CANCEL
  • Sips Office Extranet: YES

Transactions created in validation mode (captureMode = VALIDATION), must be validated fully or partially in order to trigger the payment, by using the Validate function available in the Sips Office, Sips Office Batch and Sips Office Extranet interfaces.

The transaction is then set to the "to validate" status (transactionStatus = TO_VALIDATE) or to the "waiting for a validation with authorisation request" status (transactionStatus = TO_REPLAY), then to the "to capture" status (transactionStatus = TO_CAPTURE) or directly to the "captured" status (transactionStatus = CAPTURED) depending on the means of payment rules.

You can validate a transaction only once. In the case of a partial payment, the complement can be carried out via the duplication operation.

The below checks are carried out:

  • You have the right of validation. Otherwise, a responseCode 40 is returned.
  • The transaction exists in our database. Otherwise, a responseCode 25 is returned.
  • The transaction status is "TO_VALIDATE". Otherwise, a responseCode 24 is returned.
  • The amount to validate is equal or lower than the transaction amount. Otherwise, a responseCode 51 is returned.
  • The authorisation request is accepted by the acquirer in the case of a validation with authorisation request (specific to some means of payment). Otherwise, a responseCode other than 00 is returned.
  • No cash management operation is already in progress on the transaction. If not, a responseCode 24 is returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 41. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES VALIDATE
Acquirer checking NO
Reporting

  • Transactions report: NO
  • Operations report: YES, VALIDATE
  • Sips Office Extranet: YES

Case of immediate validations after payment

Your Internet sales business may have forced you to implement your payments in validation mode (captureMode field = VALIDATION), and to send a validation request via Sips Office immediately after the payment, either when your customer returns to your merchant website, or when you receive the automatic response. This operation mode is valid, but you must take some implementation precautions and talk with your account manager in order he/she validates your choice.

We use an asynchronous database writing system to optimise your Internet sales success. Through that asynchronous writing system, we are able to accept your payment transactions in real time, even if our database system has just experienced some disruption or slowed down.

However, during a maintenance or in case of an occasional blockage of our database system, the transactions are recorded with a lag time, compared to the payment real time processing. It is therefore necessary to follow the below tips for your automated validations implementation.

Response code Description Possible causes Implementation tips
00 The validation is accepted. NTR NTR
25 The validation is rejected as the transaction cannot be found in the database Case 1: you have made a mistake in the request. The transaction identification data (transactionReference, transactionId or transactionDate) is wrong, or you are trying to validate a payment that has not ended (for example, the customer has stopped the payment).
Case 2: the payment transaction has been processed to the end but it is not yet recorded in the database due to our asynchronous database writing system. We advise to set up an automatic recovery batch of these failed validation attempts and to run this batch at least 30 minutes after the payment, to allow the necessary time to insert the transaction in the database. If you receive a new code 25, this is not a case 2, but certainly a case 1, described below.
99 The validation failed as our cash management system is punctually unreachable Case 1: we are experiencing a technical incident, we are making every effort to restore the situation as soon as possible. You will receive an e-mail describing the incident. We advise to set up an automatic recovery batch of these failed validation attempts and to run this batch at least 30 minutes after the payment, to allow the necessary time for the service restoration. While receiving a code 99, recover your validation request.
Case 2: we are in maintenance. In case of a scheduled maintenance, an e-mail has been sent to you a few weeks ago.

In the case of a payment that has already been captured, you can refund the transaction partially or totally using the Refund function available in the Sips Office, Sips Office Batch and Sips Office Extranet interfaces.

Note: every day, during the transaction remittance process to the bank (which takes place between 10 p.m. and 11 p.m. CET for the majority of means of payment), refund operations are unavailable on all transactions.

Example: if a transaction (CB, Visa or Mastercard) is carried out on day 1 (D), with captureDay set with 2, it will be possible to refund the transaction totally or partially as soon as the settlement process is finished.


Refund

In case of a full refund, the transaction is set to the "refund" status (transactionStatus = TO_CREDIT) or to the "refunded" status (transactionStatus = CREDITED) depending on the means of payment rules. It means that the unavailability rule described above will apply if another refund (total or partial) is carried out.

In case of a partial refund, the transaction status is set back to "sent to bank" (transactionStatus = CAPTURED) after the settlement process.

The below checks are carried out:

  • You have the right of refund. If you do not, a responseCode 40 is returned.
  • The transaction exists in our database. If it does not, a responseCode 25 is returned.
  • The transaction status is "CAPTURED", or "TO_CREDIT". If not, a responseCode 24 is returned. You may consult the remittance hours per acquirer / private in Appendix 3.
  • The amount to refund is equal or lower than the transaction amount. If it is not, a responseCode 51 is returned.
  • The transaction to refund is not in a chargeback status. If it is, a reponseCode 24 is returned.
  • No cash management operation is already in progress on the transaction. Otherwise, a responseCode 24 is returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 42. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: NO
  • Operations report: YES, REFUND
  • Sips Office Extranet: YES

You can do an unlimited refund, i.e. you can refund an amount greater than the paid transaction.

To do an unlimited refund, you use the same function as in the case of a standard refund, but you must have an additional option and define an authorised excess percentage compared to the original transaction amount.

If the limit is exceeded, the refund is refused.

The below checks are carried out:

  • Checks identical to those carried out for a standard refund, except for the amount check.
  • The amount to refund is equal or lower than the authorised exceedance. If it is not, a responseCode 51 is returned.
  • No cash management operation is already in progress on the transaction. Otherwise, a responseCode 24 is returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 43. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: NO
  • Operations report: YES, REFUND
  • Sips Office Extranet: YES

You can create a transaction based on an existing transaction by using the "Duplication" function available in the Sips Office, Sips Office Batch et Sips Office Extranet interfaces. For example this function lets you recreate a transaction based on a transaction that has expired by mistake, but also lets you make payments in instalments.

The means of payment details are retrieved from the initial transaction by WL Sips. However, you can amend the business details (order number, payment collection method, etc.).

Duplicated transactions are handled just like a new transaction in recurring mode (paymentPattern field set to RECURRING_N).

The below checks are carried out:

  • You have the right of duplication. If you do not, a responseCode 40 is returned.
  • The transaction exists in our database. If it does not, a responseCode 25 is returned.
  • The means of payment used is compatible and allows duplication. If it is/does not, a responseCode 24 is returned.
  • The means of payment expiry date is still valid. If it is not, a responseCode 14 is returned.
  • The authorisation request is accepted and a responseCode 00 was returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 44. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: YES
  • Operations report: YES, DUPLICATE
  • Sips Office Extranet: YES

You can create a transaction based on an existing transaction initiated by one of your other webshops by using the Extended duplication function available in Sips Office and Sips Office Batch.

The means of payment details are retrieved on the initial transaction by WL Sips. However, you can amend the business details (order number, payment collection method, etc.).

Duplicated transactions are handled in the same way as new transactions in recurring mode (paymentPattern field set to RECURRING_N).

The below checks are carried out:

  • Same checks as the ones carried out on a standard duplication.
  • The webshop used to do the duplication has to be set up with the extended duplication right. If not, a responseCode 40 is returned.
Note: you may find all the response codes in the Data Dictionary here.
Table 45. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: YES
  • Operations report: YES, DUPLICATE
  • Sips Office Extranet: NO

This feature allows you to generate multiple payments collecting for the same transaction authorised. This function makes it possible to manage the shipping in several lots of the same order by charging the customer only after the shipment of each product.

As with duplication, you create a transaction based on an existing transaction, but there is one key difference between recycling and duplication:

  • In the case of recycling, the amount is limited to the residual amount (not yet sent in payment) of the initial transaction.

If the initial authorisation request is not valid anymore (period exceeded), then the transaction is duplicated with a new authorisation request (like a standard duplication), but this duplication is only possible within the limit of the amount still to be collected.

You can recycle a transaction several times as long as the unsettled initial amount is not reached. It is not possible to recycle a recycled transaction.

The below checks are carried out:

  • You have the right of recycling. If you do not, a responseCode 40 is returned.
  • The transaction exists in our database. If it does not, a responseCode 25 is returned.
  • The means of payment used is compatible and allows recycling. If it is/does not, a responseCode 24 is returned.
  • The transaction status on which the recycling is done is "CAPTURED". If it is not, a responseCode 24 is returned.
  • The authorisation request is accepted by the acquirer with a responseCode 00.
Note: you may find all the response codes in the Data Dictionary here.
Table 46. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: YES
  • Operations report: YES, RECYCLE
  • Sips Office Extranet: YES

If you have the card or token (see the Tokenisation paragraph) details of your customer's card, you can refund the customer without referring to a previous transaction via the creditHolder function of the Sips Office, Sips Office Batch and Sips Office Extranet connectors.

If you have subscribed to the OneClick option and the card is saved in the wallet, you can also do a cardholder credit from the wallet instead of the original card number (PCI compliant) via the walletCreditHolder function of the Sips Office and Sips Office Batch connectors.

Note: the cardholder credit process is a specific one; first it consists in an authorisation request of a small amount (called "imprint") or in a request for information (if supported by the acquirer) in order to check the card number. If the acquirer response is negative, WL Sips translates it into a refusal due to an invalid card or account and returns a responseCode 14. In the case of a positive response, WL Sips sends the authorisation request with the actual amount of the credit.
Table 47. Summary
Available connectors
  • creditHolder: Sips Office, Sips Office Batch, Sips Office Extranet
  • walletCreditHolder: Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking NO
Reporting

  

  • Transactions report: YES
  • Operations report: NO
  • Sips Office Extranet: YES (for creditHolder function only)

The diagnostics feature gives you a detailed status of a transaction specified in your request via the getTransactionData feature of the Sips Office interfaces.

Table 48. Summary
Available connectors Sips Office
WL Sips configuration YES Diagnostic not activated by default
Acquirer checking NO
Parameter in the diagnostics request YES transactionReference or s10TransactionId + s10TransactionIdDate

The manual response is sent when the customer is redirected to your website once online payment ( Sips Paypage connector) or wallet management (Sips Walletpage connector) is completed. However, you have no guarantee of retrieving the manual response as the customer can decide to close the browser or not to click the 'return to shop' button once payment or wallet management is complete.

The fields returned in the response vary depending on the transaction result (refused or successful).

Table 49. Summary
Available connectors Sips Paypage, Sips Walletpage
WL Sips configuration NO
Acquirer checking NO
Parameter in the payment request

YES normalReturnUrl: <url> URL address for manual response (mandatory)

To ensure the retrieval of the response to the payment request (Sips Paypage and Sips In-App connectors) or to the wallet management request (Sips Walletpage connector), you can request the sending of the so-called automatic response. The response is sent regardless of whether or not the customer returns to your webshop. The response fields vary depending on the result of the transaction (refused or successful).

The URL address of the automatic response can be provided in the request. If it is not provided, the URL address of the merchant configuration is used. If the latter is not provided and no configuration has been made, the automatic response is not sent.

The result of the delivery of the automatic response to the merchant is entered in the automaticResponseStatus field of a payment transaction. The values of this field (SENT, FAILED, TIMED_OUT) are conditioned by the returned http code.

In the case of a failure in the sending of the automatic response (status FAILED or TIMED_OUT), a return is carried out after 15 minutes. In all 5 attempts to send the automatic response are made in case of failure.

http 200 http 201 http 204 http 205 http 301 http 301 http 404 http 408 http 504 http 500 http 503 default
SENT X X X X X X
FAILED X X X X
TIMED

_OUT

X X
Table 50. Summary
Available connectors Sips Paypage, Sips In-App, Sips Walletpage,
WL Sips configuration YES Automatic response not activated by default
Acquirer checking NO
Parameter in the payment request YES automaticResponseUrl : <url> URL address for automatic response (optional)

This notification is received by the customer at the end of the transaction process. You can get a copy of it by e-mail on a configured address when activating this option. The content of the notification varies depending on the result of the transaction (refused or successful).

The notification to the customer can be sent by e-mail or text message. If both fields are filled in, the notification is sent by email.

Note: to implement this advanced feature (text message confirmation), please contact the technical support.
Table 51. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES Confirmation not activated by default
Acquirer checking NO
Parameter in the payment request

  

YES
  • customerContact.email: <customer email address> For notification by e-mail
  • customerContact.mobile: <customer phone number> For notification by text message

The following reports allow you to follow your shop activity:

  • Transactions report
  • Operations report
  • Reconciliations report
  • Chargebacks report
  • Expired cards report

The reports are sent by e-mail daily by default, except for the expired cards report, which is sent monthly. You can choose the reports you want to be sent.

Table 52. Summary
Available connectors Sips Paypage, Sips Office, Sips Office Batch, Sips In-App, Sips Walletpage
WL Sips configuration YES Not activated by default
Acquirer checking NO/YES Depends on the acquirer or financial establishment for reconciliations reports and chargebacks reports

By default, settlements operations are not listed in the operations report. If you want to include them in this report, you may subscribe to a specific option.

By default, transactions which have not been reconciled are not listed in the reconciliations report. If you want to include them in this report, you may subscribe to a specific option.

For more information, please read the Reports documentation.

The token is a number shared by the merchant and WL Sips which replaces the card number (PAN) and is not considered as a sensitive information.

The use of the token is a method which is PCI/DSS compliant.

Token characteristics:

  • Same length as the PAN to minimise merchant’s Information System changes.
  • PAN totally tokenised (no digit in clear).
  • Includes at least one letter to avoid confusion with the PAN.
  • Unique for a given card number.
  • Non-reversible (impossible to deduce the card number).
  • Usable without constraints in the merchant’s Information System.
  • PCI-DSS certified solution.
Note: to implement this advanced feature, please contact the technical support.

The card number can be converted into a token during the payment process and returned in the manual and automatic responses.

The token is also returned in response of check enrollment service in a 3DS kinematic via the Sips Office et Sips In-App connectors.

You can then use this token to submit recurrent payments via the Sips Office connectors.

Table 53. Summary
Available connectors Sips Paypage, Sips Office, Sips In-App
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

In the event that the tokenisation processing cannot be completed, an option is used to interrupt the payment process.

Table 54. Summary
Available connectors Sips Paypage, Sips Office
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

You may also continue the payment process and then choose to tokenise the transaction by using the “transaction tokenisation” feature described below.

This feature encrypts one or more card numbers into one or more tokens. The order of the tokens is not guaranteed, i.e. the first number entered in the connector is not necessarily the first token to appear in the response. The tokenPanId field is used to retrieve the token associated with the number of the sent card.

The output data in the response contains as many tokens as there are pairs of filled in tokenPanId and tokenPan fields.

Table 55. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES
  • panId: Token ID in the tokenisation process
  • pan: Card number

This feature encrypts one card number from an existing transaction into one token. You can use this feature with the transactionId or the transactionReference mode (see the transaction identification mode).

You have the possibility to send only one transaction per request.

Table 56. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES fromTransactionReference or s10FromTransactionId + s10From TransactionIdDate: Transaction ID

This feature decrypts one or several tokens into one or several card numbers. The order of the card numbers is not guaranteed, i.e. the first token entered in the connector is not necessarily the first card number to appear in the response. The panId field is used to retrieve the card number associated with the token sent.

The output data in the response contains as many card numbers as there are pairs of filled in panId and pan fields.

Table 57. Summary
Available connectors Sips Office
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES
  • tokenPanId: token ID in the tokenisation process
  • tokenPan: card number for conversion into token

You can send a payment request by specifying the token instead of the PAN via the cardOrder function of the Sips Office and Sips Office Batch connectors or via the orderInitialize function of the Sips In-App connector.

You must firstly retrieve the customer's token either in return of a payment or through the tokenisation feature.

Table 58. Summary
Available connectors Sips Office, Sips Office Batch, Sips In-App
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES Via Sips Office and Sips Office Batch connectors:
  • panType: TOKEN
  • cardNumber: <token> value of the token
  • cardExpiryDate: expiration date of the card
  • cardCSCValue: security code if non-recurrent payment
  • cardEffectiveDate
  • cardSequenceNumber
Via Sips In-App connector:
  • tokenPan: <token> value of the token
  • cardExpiryDate: expiration date of the card
  • cardCSCValue: security code if non-recurrent payment

You can refund a customer from their own token. This is the secure version of the cardholder credit feature as you do not need to know your customer's card number.

Via the CreditHolder feature of the Sips Office interfaces, you carry out a cardholder credit transaction using a token instead of a PAN.

First, you have to retrieve the customer's token either in return for a payment or through the tokenisation feature.

Table 59. Summary
Available connectors Sips Office, Sips Office Batch
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES
  • panType: TOKEN
  • cardNumber: <token> value of the token
  • cardExpiryDate: expiration date of the card
  • cardCSCValue: security code if non-recurrent payment
  • cardEffectiveDate
  • cardSequenceNumber

At the end of the payment process, one or two hashPan calculated from the card number can be returned in the automatic and/or manual responses.

The hashed (hashPan field) PAN (Primary Account Number or card number) is calculated based on an irreversible cryptographic function (unlike the token). ). It lets you check the frequency of use of a card in return for payment.

The automatic and/or manual response contains as many hashPan as there are hashSalt and hashAlgorithm fields entered in the payment request.

HashSalt is used to increase the complexity of the calculated hash and prevent finding the card number using a reverse hash dictionary function.

WL Sips offers to return two hashPan to enable you to change algorithm and so to avoid a break in the checks carried out in return of the payment.

Table 60. Summary
Available connectors Sips Paypage
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES
  • hashSalt1: salt for calculation of hashPan1
  • hashSalt2: salt for calculation of hashPan2
  • hashAlgorithm1: <SHA-1, SHA-256, SHA-512> Algorithm1 used for hashPan1
  • hashAlgorithm2: <SHA-1, SHA-256, SHA-512> Algorithm2 used for hashPan2

The Oppotota check before collecting (card cancellation management) lets you check whether the card used has been cancelled between the authorisation request and the transaction validation or payment collecting.

This check applies only to CB, VISA and MASTERCARD transactions and is relevant only if your transactions are processed by a French bank in the CB network.

The file containing blocked/cancelled cards is populated based on the list of blocked/cancelled cards of the CB network. This file is updated several times a day.

Table 61. Summary
Available connectors Sips Paypage, Sips Office,Sips Office Batch , Sips In-App
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

The CHALLENGE option allows you to put in hold transactions with an ORANGE score. It allows you to check the risk before proceeding with the other acceptance steps: validation, re-authorisation or capturing the transaction (settlement).

If you do not have the CHALLENGE option, the transaction is accepted.

You have X days to measure the fraud risk and to validate or refuse the transaction. X is the maximum value between the validity of the authorisation and the capture time (captureDay) you have set up in the payment request.

Once the check done, if you decide to accept the transaction, you will use the acceptChallenge operation.

Attention: no cash management operation should already be in progress on the transaction. Otherwise, a responseCode 24 is returned (responseCode chart).
Table 62. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet, MEX
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

Once the check done, if you decide to refuse the transaction, you will use the refuseChallenge operation.

Attention: no cash management operation should already be in progress on the transaction. Otherwise, a responseCode 24 is returned (responseCode chart).
Table 63. Summary
Available connectors Sips Office, Sips Office Batch, Sips Office Extranet, MEX
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

The diagnostic feature allows you to retrieve information about the fraud control of a transaction specified in your request through the getFraudData function of Sips Office

Table 64. Summary
Available connectors Sips Office
WL Sips configuration YES Diagnostic not activated by default
Acquirer checking NO
Parameter in the payment request YES transactionReference or s10TransactionId + s10 TransactionIdDate

The anti-fraud engine is aimed at all merchants who have subscribed to the "Fraud risk management – Business Score" offer and wish to benefit from an anti-fraud tool administered by themselves on the MEX.

The anti-fraud engine relies on anti-fraud profiles to evaluate transactions. These are composed of rules that you can configure.

For a functional description and how to implement fraud control online, please consult the Fraud risk management - Go-No-Go and Fraud risk management - Business Score documentation.

Note: to implement this advanced feature, please contact the technical support.

WL Sips supports 2 types of stakeholders to use the WL Sips connectors:

  • The merchant (default).
  • An entity also referred to as the Intermediate Service Provider (ISP).

ISP is an entity authorised to log into WL Sips and act on behalf of the merchants. An ISP may be a structure that manages a network of shops (common in large-scale retailing) or a host/reseller of the WL Sips solution.

To get connected as an ISP, you need to make a request to the technical support. If your request is accepted, you will be given an ISP ID with its own unique secret key for all the shops managed by the ISP.

This ID must be sent in the intermediateServiceProviderId field of the request, in addition to the usual merchantId. In terms of security, the signature for the request and response messages is provided with the secret key of the ISP and not with the shop's one.

Note: to implement this advanced feature, please contact the technical support.
Table 65. Summary
Available connectors Sips Paypage, Sips Office, Sips In-App, Sips Walletpage
WL Sips configuration YES
Acquirer checking NO
Parameter in the payment request YES intermediateServiceProviderId: ID of the entity acting as a merchant

For more information, please read the Functional presentation documentation.

The Honor All Cards functionality allows merchants to select the brands and usages they wish to accept and which involve the CB, Visa and Mastercard schemes.

By default, without the activation of this functionality and for a merchant with a CB/Visa/Mastercard contract, all brands and usages are accepted.

The selectable brands are:
  • CB
  • VISA
  • VPAY
  • ELECTRON
  • MASTERCARD
  • MAESTRO
The selectable usages are:
  • Credit
  • Debit
  • Prepaid
  • Commercial
Note: to implement this advanced feature, please contact the technical support.

As a payment acceptance solution, the WL Sips 2.0 solution is subject to the European MIF Regulation (OJ EU 2015/751 L123 of 19/05/2015). Among these rules, "Brand Selection" requires you to offer the customer with a co-branded card the choice of brand at the time of payment, which impacts the payment page.

A co-branded card is a card that supports at least two brands. Most cards issued in France are co-branded with CB (CB/VISA, CB/MASTERCARD, CB/MAESTRO, etc.).

To implement the brand selection, please read the 'Integration of National Bank Card' documentation

AVS is a feature used in certain countries such as the United Kingdom to fight fraud. AVS lets you request the cardholder's address (see the fields affected below), send it in the authorisation request, and let the card issuer compare this address with the one it has on record. AVS includes checks of street names and postcodes.

The response of an authorisation and the result of the AVS check are independent, i.e. it is possible for the acquirer to approve the authorisation request with false AVS checks.

In the request you must specify the AVS data check methods during online acceptance of the transaction. If you specify that the result of the AVS check should condition acceptance of the transaction, then an authorisation granted with a failed AVS check will be refused by WL Sips. In this case, an automatic reversal operation is sent to the acquirer by WL Sips to reset the card authorisation limit.

Parameters Values Note
checkAVS Y/N Specifies whether the AVS check must be carried out. Deactivated by default.
ignorePostcodeCheckResult Y/N Ignores the result of the postcode check (inactive by default).
ignoreAddressCheckResult Y/N Ignores the result of the street name check (inactive by default).
holderAddress.addressAdditional1 Address Contains information about the cardholder's street.
holderAddress.addressAdditional2 Address
holderAddress.addressAdditional3 Address
holderAddress.streetNumber Number
holderAddress.street Street
holderAddress.postbox Postbox
holderAddress.city City
holderAddress.state State
holderAddress.zipCode Postcode Contains information about the cardholder's postcode.

Transactions refused following a failed AVS return a response code 14 and an acquirer response code 00.

Two dedicated AVS response codes (avsPostcodeResponseCode and avsAddressResponseCode) are returned in the payment response (not currently available on Sips Paypage) and appear in the transactions report.

A surcharge is an additional fee added to a cheque or card payment (cash payments are not affected) with the objective of covering the cost of acceptance incurred by the merchant. The surcharge can be prohibited by the card issuers – completely (e.g. Visa and Mastercard in the US) – or when the merchant applies a prohibited rate. Regulations can authorise or prohibit the surcharge. "Without surcharge" means that the surcharge is included in the price (even in the case of cash payment).

On Sips Paypage, the surcharge is calculated by WL Sips during the payment. You need to enroll in the "Surcharge" option and configure the surcharge amount linked to the product code of the card. Two types of surcharge can be applied: a fixed amount or a percentage of the transaction. The authorisation amount sent to the acquirer equals the total amount of the transaction + the surcharge.

To configure the surcharge, you need to provide the card scheme, the product code of the card, the currency and the fixed amount or percentage.

On Sips Office, you are responsible for calculating the surcharge. The total amount in the payment request sent to WL Sips contains the surcharge.

The aim of the Account Updater & Stop Service, which was launched by the issuers and acquirers, is to address the following issue: physical cards are regularly being re-issued, making it easier for a merchant to lose track of the cardholders’ information.

This service:

  • Provides merchants with an automatic way of updating their customers' card details, which in turn enables them to improve both authorisations and settlements for their recurrent payments.
  • Helps minimise the risks of outstanding balances.
  • Enables cardholders to request a "stop payments" through the issuers.

To benefit from this service, you need to:

  • Subscribe to the service provided by WL Sips if your acquirer is compatible.
  • Set up a FTP connection with WL Sips for the file transfer.
  • Send appropriate requests to the schemes via WL Sips before carrying out recurrent transactions.
  • Carry out authorisation requests for all your recurrent transactions.
  • Carry out the initial transaction in a secure environment (i.e. with CVV2 or PIN code).

For more information, please read the 'Account updater service' documentation.

ARP is the name used in WL Sips for the MARP (Mastercard Advanced Registration Program) and MUPP (Mastercard Utility Payment Program) solutions by Mastercard.

The goal of this feature is to suggest automatically the bypassing of the 3-D Secure process if the card has already undergone the first 3-D security check (as part of the same contract with the acquirer). It therefore simplifies the payment process for trusted cardholders.

The 3-D Secure process is triggered upon the first payment with the card. The following payment with the same card (as part of the same contract) is identified as an ARP transaction and the 3-D Secure process is not displayed.

In the case of a payment where 3-D authentication is bypassed by ARP, the value in the HolderAuthentProgram field in the responses is ARP.

The conditions of use for ARP are the following:

  • You need to subscribe to the 3-D Secure programme.
  • The ARP option must be activated in WL Sips.
  • It must be a Mastercard or Maestro card.
  • Your acquirer must be ARP compliant.
Table 66. Summary
Available connectors Sips Paypage
WL Sips configuration YES Not activated by default
Acquirer checking NO
Parameter in the payment request NO

The WIP service applies to Bancontact cards and provides 2 new possibilities

  • Improve the user experience for OneClick payments by eliminating the 3-D Secure authentication phase
  • Allow recurring payments

The service is aimed to low-risk, high-volume e-commerce merchants who are able to keep their fraud rate below a certain threshold. Each merchant must be approved by the payment system manager before being authorized to access to the WIP service.

Sips Paypage Sips Office Sips Office Batch Sips In-App Sips Walletpage
Transactions identification
Identification at creation yes yes no no yes
Cash management identification no yes yes no no
Identification in reporting yes yes no no yes
Secure Paypages management
Page customisation yes no no no yes
Display of payment means yes no no no no
Ticket displayed by WL Sips yes no no no no
Number of payment attempts yes no no no yes
New payment attempt yes no no no no
Duration of time on payment pages yes no no no no
Display of webshop name yes no no no yes
Card number entry in separate blocks yes no no no yes
Entry of cardholder name yes no no no yes
Error page display yes no no no no
Hiding sensitive information on entry page yes no no no yes
Display of waiting message yes no no no no
iFrame tag yes no no no yes
Payment channel
Internet yes yes yes no no
MOTO yes yes yes no no
Mobile application no no no yes no
Payment collection methods
End-of-day payment yes yes yes yes no
Deferred payment yes yes yes yes no
Payment on dispatch yes yes yes yes no
Payment by instalments yes no no no no
Immediate payment yes yes yes yes no
Validity period for the authorisation yes yes yes yes no
Payment in different currencies
Multi-currency acceptance yes yes yes yes no
Settlement in different currencies yes yes yes yes no
Dynamic currency conversion yes no no no no
3-D Secure
3-D Secure yes yes no yes yes
Dynamic 3-D Secure Bypass (with the risk of "soft decline" refusal) yes no no no yes
Dynamic 3-D Secure Bypass for OneClick payments (with the risk of "soft decline" refusal) yes no no no no
Error 3D transaction refusal yes yes no yes no
Blocking non-guaranteed 3D transactions yes yes no yes no
Safekey security
Safekey security yes yes no no yes
OneClick Payment
OneClick enrollment with payment yes no no yes no
OneClick enrollment without payment no yes yes no yes
OneClick payment yes yes yes yes no
Subscription payment
Subscriber registration with 1st payment yes no no no no
Subscriber registration without payment no yes yes no yes
Subscription payment no yes yes no no
Cash management
Cancellation no yes yes no no
Validation no yes yes no no
Refund no yes yes no no
Uncapped refund no yes yes no no
Duplication no yes yes no no
Extended duplication no yes yes no no
Recycling no yes yes no no
Cardholder credit no yes yes no no
Online reporting
Diagnostic no yes no no no
Manual response yes no no no yes
Automatic response yes no no yes yes
End of transaction confirmation to customer yes yes yes yes no
Reporting file
Transactions report yes yes yes yes no
Operations report yes yes yes yes no
Reconciliations report yes yes yes yes no
Chargebacks report yes yes yes yes no
Wallet expiration report yes yes yes yes no
Tokenisation
Return of the token yes yes no no no
Card number tokenisation no yes yes no no
Transaction tokenisation no yes yes yes no
Card number detokenisation no yes no no no
Payment from a token no yes yes no no
Cardholder credit from a token no yes yes no no
Return of the hashPan yes yes no no no
Fraud
Fraud detection before collecting (Oppotota checks) yes yes yes yes no
acceptChallenge no yes yes no no
refuseChallenge no yes yes no no
Fraud diagnostic no yes no no no
Entity acting for a merchant
Intermediate Service Provider (ISP) yes yes no yes yes
Country-specific aspect
Brand selection (MIF) yes yes yes yes no
Address Verification Service (AVS) yes yes yes no no
Surcharge yes no no no no
ARP (Advance registration program) yes no no no no

Feature available (yes) / Feature unavailable (no)

Yes = feature available

No = feature unavailable

Conditional = feature available with specificity, please refer to the integration guide in question

L : List C : Cancel
V : Validation R : Refund
D : Duplication
Cards / Payment means Authorised features Validity of the authorisation request
L C V R D
CB Yes Yes Yes Yes Yes 6 days*
Visa Yes Yes Yes Yes Yes 6 days*
Mastercard Yes Yes Yes Yes Yes 6 days*
American Express Yes Yes Yes Yes Yes 6 days*
Vpay Yes Yes Yes Yes Yes 6 days*
Maestro Yes Yes Yes Yes Yes 6 days*
Visa Electron Yes Yes Yes Yes Yes 6 days*
AcceptGiro Yes No No No No Deferred payment
Apple Pay Yes Yes Yes Yes No 6 days
Bancontact Yes No No Yes Yes Immediate payment
Bancontact mobile Yes No No No No Immediate payment
Floa Bank CB 3X Yes No Yes Yes No Immediate payment
Floa Bank CB 4X Yes No Yes Yes No Immediate payment
CACF Yes Conditional Yes No Yes 21 days
CACF 3X Yes Yes Yes Yes No Deferred payment
CACF 4X Yes Yes Yes Yes No Deferred payment
Cadhoc Yes No No Conditional No Immediate payment
Cadocarte Yes No No Conditional No Immediate payment
CUP card by Floa Bank Yes Yes Yes Yes Yes 20 days
Oney card Yes Yes Yes Yes Yes Deferred payment
Oney gift card Yes No No Yes Yes Immediate payment
Cetelem CPay (formerly Cetelem Aurore) Yes Yes Yes Conditional Yes 60 days
Cetelem 3X 4X CB Yes No No Yes No Immediate payment
Cetelem Presto Yes Conditional No No No Immediate payment
Chèque-Vacances Connect Yes No No Conditional No Immediate payment
Cofidis 1euro.com Yes Yes Yes Yes No 99 days
Cofidis 3xCB Yes Yes Yes Yes No 8 days
Cofidis 4xCB Yes Yes Yes Yes No 8 days
Cofinoga Yes Yes Yes Yes Yes 15 days
Cofinoga 3xCB Yes No No Yes No Immediate payment
Titres Restaurants Dématérialisés - Conecs Yes Yes Yes Conditional No Deferred payment
China Union Pay Yes No No Yes No Immediate payment
Diners Yes No No Yes No Immediate payment
e-Chèques Vacances Yes No No Conditional No Immediate payment
Facily Pay Yes Yes Conditional Conditional No 30 days
Franfinance 3xWEB Yes Yes Yes Yes No 99 days
Franfinance 4xWEB Yes Yes Yes Yes No 99 days
Giropay Yes No No No No Immediate payment
iDeal Yes No No Yes No Immediate payment
Illicado Yes No No Conditional No Immediate payment
Incasso Yes No No No No Deferred payment
Japan Credit Bureau Yes No No Yes No Immediate payment
Lepotcommun Yes No No Conditional No Immediate payment
Lydia Yes No No Yes No Immediate payment
Lyf Pay Yes Yes Yes Yes No 30 days
Masterpass Yes Yes Yes Yes Yes 6 days
Oney 3x 4x Yes Yes Yes Yes No 30 days
Paybutton ING Yes No No No No Immediate payment
Paybutton KBC/CBC Online Yes No No No No Immediate payment
Paylib Yes Yes Yes Yes Conditional 6 days
Paypal Yes Yes Yes Yes Yes 29 days
Paytrail Yes No No No No Immediate payment
Rembours Yes No No No No Deferred payment
SEPA Direct Debit (SDD) Yes Yes Yes Conditional Yes Deferred payment
Sofortüberweisung Yes No No Conditional No Immediate payment
Spiritofcadeau Yes No No Conditional No Immediate payment
Visa Checkout Yes Yes Yes Yes Yes 6 days*

*by default the authorization request is 6, but it is also configurable.

Below is a table showing the current hourly programming of remittance batches per acquirer / owner.

Acquirer Settlement start time*
AMEX 22h00
Armoney 22h00
Banksys 22h00
Barclays 22h00
Bancontact 05h00
BNP Paribas 22h00
Crédit Agricole Consumer Finance 19h00
Caisse Centrale Banques Populaires 22h00
Crédit Commercial de France 22h00
Crédit Du Nord 22h00
Cedicam 22h00
Cetelem Crédit 22h00
Cetelem Débit 17h00
CIC 22h00
Crédit Lyonnais 22h00
Crédit Mutuel Centre Est Europe 22h00
Crédit Mutuel de Bretagne 22h00
Caisse Nationale des Caisses d'Epargne 22h00
Cofidis 05h00
Cofinoga 22h00
Diners 22h00
Franfinance 22h00
La Banque Postale 22h00
Natwest 22h00
Paypal 17h00
Société Générale 22h00
SPS 22h00
* Indicated time is CET (Central European Time)

This site uses cookies 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 cookies on your device.

Configuration