WL SIPS DOCS

Release 21.6

go directly to content
Search by keywords

Full migration to WL Sips 2.0

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 on despatch, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the migration to WL Sips 2.0.

This document is intended for merchants having the WL Sips 1.0 offer.

Its purpose is to facilitate the migration to WL Sips 2.0.

For any technical question or request for assistance, our services are available:

  • by telephone at: +33 (0) 811 10 70 33
  • by e-mail: sips@worldline.com

In order to facilitate the processing of your requests, please provide your merchantId (15-digit number).

The following comparative table introduces the benefits of the various interfaces:

Criteria Sips Paypage interface Sips Office interface
Functional scope

Transaction creation only

Transaction creation and cash management.

Tip: you can use Sips Paypage for payment and Sips Office for cash management.
PCI/DSS

Benefits from PCI certification because the payment process is outsourced to the WL Sips servers.

You do not know the customer's PAN.

In transaction creation, the handling of payment pages is done by you, so it is subject to the PCI-DSS certification.
Tip: you can limit your scope by not storing any PAN information in your information system (for example, replacing PAN with a token or a Wallet ID or a hashPan).
The tokeniser solution is part of the feature table (§ 3.1.1) and may be introduced to you by the Worldline teams.
3-D Secure 3-D Secure process handled by WL Sips and transparent to you.
You drive the 3-D Secure authentication process.
Tip: you can use the WL Sips MPI to handle exchanges with the Visa/MC directory servers.
Integration effort Plug & Play solution easy to integrate Solution requiring more development: on-board payment on the merchant side with handling of payment pages…
Adding a means of payment

No development effort for you in most cases.

Note: you may need to populate specific fields in the payment request to take advantage of the means of payment options (PayPal example).
Development effort on the merchant side to integrate the means of payment (handling of processes, of pages, etc.).
Customer path Limited disruption between your website and the payment server thanks to the available customisation (CSS, URL) of the payment pages. No disruption between your website and the payment server.
Integration into your IS Interfaces with your shop. Interfaces with your shop or Back Office.
Reporting Consistent reporting

On WL Sips 1.0, the transaction identification system is made possible by the assembly of the following 4 fields:

  • merchantId (N15): fixed value provided by WL Sips
  • merchantCountry (A2): fixed value provided by WL Sips
  • transactionDate (YYYYMMDD): variable value given by WL Sips (in French local time zone) at the moment of the payment acceptance
  • transactionId (N6): variable value given by you or by WL Sips in your delegation at the time of the payment request (i.e. before the authorisation request). This value must be unique for the combination of the 3 above fields.

Operations associated with a transaction are identified by five-part element, the above 4 fields supplemented with an operation_sequence.

As on WL Sips 1.0, the default mode for generating the transaction identifier is the generating you make. This mode is recommended because it allows you to store the context and prepare the reconciliation of your transaction before sending the request.

The automatic generating mode is an easy integration that is not recommended if you generate significant flows because it has some disadvantages:

  • The duplicate transaction check is performed by WL Sips on this identifier sent by you. So, in the case of the identifier self-generating, this check cannot be performed.
  • The absence of transactionId or transactionReference in the request requires you to use other data (customer, orderId, amount) to reconcile the response and the request.
  • It is not possible to send a request to WL Sips with the Diag method in the event of a fault (example: you did not receive the response, etc.).

On WL Sips 2.0, the standard identification of the transaction is done through a new identifier: transactionReference.

This new identifier has the advantage of being in ANS35 format which allows:

  • to keep this unique identifier in an unlimited way (over the period during which the transaction exists in WL Sips: 15 months) instead of one day for transactionId.
  • to use alphanumeric characters in the reference with an open format enabling the generating by yourself
  • to be independent on time zones (internationalisation)

In order to minimise any impact, the use of transactionId is maintained in WL Sips 2.0.

On WL Sips 2.0, you need to be in one of these two modes:

  • transactionReference mode (default mode)
  • transactionId mode

If you would like to remain in transactionId mode you need to make a request to WL Sips when registering your merchant ID with the WL Sips 2.0 offer.

All transactions on WL Sips 2.0 are linked both to a transactionId + transactionIdDate and to a transactionReference.

transactionId, transactionIdDate and transactionReference are stored, returned and displayed for all transactions.

In the 2.0 interfaces, the transactionId and transactionIdDate fields have been named s10TransactionId and s10TransactionIdDate so that you can directly and easily identify the reference to WL Sips 1.0.

In a nutshell:

  • the transactionReference is the default way to identify a transaction.
  • the s10TransactionId allows you to identify a transaction while remaining compatible with WL Sips 1.0.
  • the s10TransactionId + s10TransactionIdDate pair ensures the uniqueness of the transaction.

During a transaction creation, and depending on the chosen mode, WL Sips accepts or rejects the creation and generates additional identifiers. The table below summarises the various possible cases.

Transaction creation via
Use case Data Sips Paypage Sips Office Sips Office Extranet
Shop in transactionReference mode
You connect to WL Sips with a transactionReference generated by you. transactionReference provided by you. Use case Use case Offered by WL Sips, editable and displayed in red.
transactionId provided by you.

Reject

Reject Code = 12

Reject

Code = 12

N/A
Absent transactionId OK OK N/A
Absent transactionReference

Reject

Code = 12

Reject

Code = 12

Reject

Code = 12

Additional reference generated by WL Sips.

s10TransactionId

s10TransactionIdDate

s10TransactionId

s10TransactionIdDate

s10TransactionId

s10TransactionIdDate

Content response

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

You connect to WL Sips without transactionReference (Tref auto) transactionReference generated by WL Sips Use case N/A Generated by WL Sips and displayed in red.
transactionId provided by you.

Reject

Code = 12

N/A
Absent transactionId OK N/A
transactionReference provided by you.

Reject

Code = 12

N/A
Additional reference generated by WL Sips.

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

Content response

s10TransactionId

s10TransactionIdDate

transactionReference

Shop in transactionId mode
You connect to WL Sips with a transactionId generated by you. transactionId provided by you. Use case cas d'usage Offered by WL Sips, editable and displayed in red
Absent transactionId

Reject

Code = 12

Reject

Code = 12

Reject

Code = 12

transactionReference provided by you.

Reject

Code = 12

Reject

Code = 12

N/A
Absent transactionReference OK OK N/A
Additional reference generated by WL Sips. transactionReference transactionReference transactionReference
Content response

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

You connect to WL Sips without transactionId (Auto Tid). transactionId generated by WL Sips. Use case N/A Generated by WL Sips and displayed in red.
transactionId provided by you.

Reject

Code = 12

N/A
transactionReference provided by you.

Reject

Code = 12

N/A
Absent transactionReference OK N/A
Additional reference generated by WL Sips.

s10TransactionId

s10TransactionIdDate

transactionReference

s10TransactionId

s10TransactionIdDate

transactionReference

Content response

s10Transaction Id

s10TransactionIdDate

transactionReference

For cash operations, the identification of a transaction is not limited to the chosen mode.

The table below shows the various options available.

Use case Data Cash management
Shop in transactionReference mode
Original transaction generated with a transactionReference. transactionId provided by you. OK
transactionReference provided by you. OK
Consistent transactionReference and transactionId provided by you. OK
transactionReference and transactionId (not referencing the same transaction) provided by you.

Reject

Code = 12

New transaction (duplication, recycling and cardholder credit) See the transactions creation table above.
Shop in transactionId mode
Original transaction generated with a transactionId. transactionId provided by you. OK
transactionReference provided by you. OK
Consistent transactionReference and transactionId provided by you. OK
transactionReference and transactionId (not referencing the same transaction) provided by you.

Reject

Code = 12

New transaction (duplication, recycling and cardholder credit). See the transactions creation table above.
  • transactionId mode

To make a payment in instalments in transactionId mode, you need to send a transactionId list and a transactionIdDate list in the payment request. WL Sips automatically generates a transactionReference for each transaction.

If the transactionId list is not sent, the transaction is rejected with a responseCode = 12.

  • transactionReference mode

To make a payment in instalments via the transactionReference mode, you need to send a transactionReference list and the date of each due date in the payment request. WL Sips automatically generates a transactionId for each transaction.

If the transactionReference list is not sent, the transaction is rejected with a responseCode = 12.

Payment in instalments is not compatible with the above mode in which the transaction reference is automatically generated by WL Sips.

  • Reports

The s10TransactionId, s10TransactionIdDate and transactionReference fields are included in the 2.0 Transactions, Operations, Reconciliation and Chargebacks reports, regardless of the enabled transaction identification mode.

For duplicate and recycling operations, the original transaction can be identified via the s10FromTransactionId, s10FromTransactionIdDate and transactionTransferReference fields in the Transactions report.

  • Sips Office Extranet

Searching for a transaction in Sips Office Extranet can be done with either a transactionId or a transactionReference.

If you have opted for the transactionReference, both columns will always be present in Sips Office Extranet in the following screens:

  • list of transactions following a searching
  • detail of a transaction.

Adding a PAN to gray lists via the transaction reference is possible via the use of transactionId or transactionReference.

In 1.0 checks are made on the 1.0 fraud check tool.

In 2.0, you use the new 2.0 fraud engine.

On WL Sips 1.0, in order to bypass one or more additional checks, you need to notify the keyword corresponding to the checking in the DATA field of the API. On WL Sips 2.0, you need to enter the values of the bypassCtrlList and bypassInfoList fields.

The bypass keywords correlation is described in the 1.0 / 2.0 Data correlation guide.

The checkings not linked to the means of payment (ex. customer outstanding payments, gray list, etc.) are not shared between 1.0 and 2.0.

  • The migration of gray lists from 1.0 to 2.0 is supported by the migration process.

The main features of 2.0 fraud management are:

  • Go-No-Go mode (corresponds to WL Sips 1.0)
  • Go-No-Go+ mode

Fraud-management-MG

  • 1.0 anti-fraud checks (Go-No-Go)
  • 2.0 anti-fraud checks (Go-No-Go +)
  • Profiles by default
  • RMS (Risk Management system) GUI: viewing / updating of the configuration

RMS-MG1


RMS-MG2

  • New payment pages
  • Web responsiveness

Please refer to the following documentation:

  • Payment 1.0 migration guide
  • Sips Office 1.0 migration guide
  • Migration guide for the customisation of payment pages

We have identified a list of steps that are essential for a successful migration from WL Sips 1.0 to WL Sips 2.0. These steps can be schematised as follows:


Timing-MG

The successive steps below refer to the 'Timing' part. You will need to follow these to successfully complete your migration to WL Sips 2.0:

  • Choose migration modalities
    • Choice of connectors depending on your operation mode
    • Decision to remain in transactionId or to switch to transactionReference
  • Install the connectors

    • Transposition of 1.0 / 2.0 data (reports, fraud, etc.)
  • Customise payment pages if you choose the paypage mode

    • Make local tests with a tool provided by Worldline
    • Send CSS to WL Sips
  • Use the customer test environment to test the Sips Paypage and Sips Office applications using the available test shop

    • Retrieve test identifiers
    • Make tests on the test environment
    • Check the tests performed
    • Send a migration report to Worldline
  • Start in production

    • Check the shop configuration in configuration
    • Send the request to start in production
    • Integrate the production shop IDs
    • Activate the switch to WL Sips 2.0
    • Monitor the post-switch data
  • Remove references to WL Sips 1.0 on your site: certificate, setting files, executable files, etc.

You have a shop in 1.0, so you have a merchantId which allows to log in. All your transactions are made with this merchantId and you enjoy consolidated reports and a visualisation of all your transactions on Sips Office Extranet with all means of payment combined.

You pilot the migration. After issuing your migration report, the decision of the date and time of migration is taken jointly between you and Worldline. A close monitoring of the first flows is done by you and Worldline to ensure the smooth running of the 2.0 migration.

In case you detect an anomaly (unidentified issue during the test phase of your internal developments), flows can be migrated back to WL Sips 1.0 via the APIs.

This solution remains possible as long as you and WL Sips keep valid 1.0 login credentials. The 1.0 accesses removing is done during the last step.

Worldline has developed a new WL Sips platform, allowing you to:

  • simplify WL Sips integration and standardise connection methods thank to new state of the art WL Sips connectors.
  • optimise the customer experience thanks to new features and new ergonomics of the customer interfaces (InApp application, webresponsive, etc.).
  • have greater autonomy in the management of transactions and settings thanks to a new Extranet interface.
  • facilitate the deployment on the international market thanks to new means of payment.
  • enjoy advanced features such as an effective anti-fraud tool, dashboard, etc.

If you have created a new shop in 2.0 you will have two separate merchantId.

From the 2.0 interfaces you cannot access and manage transactions created in WL Sips 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in WL Sips 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in WL Sips 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in WL Sips 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

From the 2.0 interfaces you cannot access and manage transactions created in WL Sips 1.0 (validation, cancellation, refund, duplication) since you keep your existing identifier for your 1.0 shop, and use a new identifier for your new 2.0 shop.

However, you can can use the extended duplication feature that allows from a 2.0 shop to duplicate a transaction from another shop, even if the transaction is in 1.0.

In the case where you keep the identification by TransactionId, you have the option to keep your reports in the old 1.0 format or to enjoy the new 2.0 reports format at your convenience.

However, only 2.0 reports evolve and enjoy new added fields. If you keep the 1.0 format, you will not enjoy the updates (ex. adding a means of payment related additional data in the reports).

The s10TransactionId and s10TransactionIdDate fields have been added to the Transactions, Operations, Reconciliations and Chargebacks 2.0 reports.

You can opt for transactionReference mode at any time. For example, you have the opportunity to migrate to WL Sips 2.0 by keeping the transactionId mode to facilitate the migration and then opt for the transactionReference in order enjoy the advantages of this new format.

If you have opted for the transactionReference mode you can no longer switch to the transactionId mode, because if you are in transactionId mode, the extranet display is not changed, and the transactionReference is not visible. This would prevent manipulating transactions generated with the transactionReference mode.

Customising payment pages is an optional step to start in 2.0. WL Sips offers customisation by default.

There is no migration tool that reproduces the customisation of 1.0 payment pages. We do not recommend attempts to reproduce exactly the visuals of the 1.0 payment pages on the 2.0 payment pages. Indeed, it would be a shame to be deprived of the new opportunities offered by the 2.0 payment pages, especially from the responsiveness point of view.

It is recommended to change the payment pages customisation in order to enjoy the advantages of the 2.0 payment pages.

A page customisation guide is available.

The wallet database is shared between WL Sips 1.0 and 2.0.

The SUBSCRIPTION subscribers data base is already migrated to the wallet database.

The list of means of payment available in 2.0 is provided in § 3.1.2 of this guide.

Fraud checks available in 2.0 are detailed in the "Anti-fraud management" guide.

Accepted currencies depend on the acquirer’s contract. The currencies available for the Visa/MC, Amex scheme are as follows:

EUR,USD,CHF,GBP,CAD,JPY,MXN,TRY,AUD,NZD,NOK,BRL,ARS,KHR,TWD,SEK,DKK,KRW,SGD,XPF,XOF.

  • La Banque Postale
  • Banque Populaire
  • BNP Paribas
  • Caisse d’Epargne
  • Crédit Agricole
  • Crédit Du Nord
  • Crédit Mutuel Centre Est Europe
  • CIC
  • Crédit Mutuel of Brittany
  • HSBC
  • Crédit Lyonnais
  • Société Générale

Worldline provides you with a test shop that allows you to validate your internal developments.

When you have finished your test phase, you provide a migration report and determine jointly with Worldline the date and time of your migration.

Following this migration, a careful monitoring of the first flows is performed.

The first scenario described here is to open a new shop in 2.0.

This scenario may be suitable in case you would like to quickly implement a new means of payment for a shop without having to migrate all your flows, or you use some means of payment not yet available in 2.0.

You will have two shops, a WL Sips 1.0 one for your current means of payment, and a WL Sips 2.0 shop for one or more new means of payment.

Both shops are attached to the same customer, but you will have 2 merchantId.

The standard procedure for registering a new 2.0 shop should be used.

You access and manage the transactions in the 1.0 or 2.0 environments/interfaces in which you created those transactions.

The extended duplication allows you to create a transaction from an existing transaction initiated by another shop. You can use this feature to duplicate a transaction of your 1.0 shop from your new 2.0 shop.

To do this, both shops must share the same clientId.

You need to include in your payment request the identifiers of the original shop and of the original transaction:

  • fromMerchantId
  • fromMerchantId
  • s10FromTransactionIdDate

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

The duplicated transactions are processed as a new transaction in recurring mode (the paymentPattern field is set to RECURRING_N).

The performed checks are as follows:

  • You do not have the extended duplication right (refusal code 03).
  • The original shop is not attached to you (refusal code 40).
  • The transaction to be duplicated does not exist (refusal code 25).
  • The initial transaction cannot be duplicated because the means of payment does not allow this (refusal code 24).
  • The means of payment expiry date has been exceeded (refusal code 24).
  • Authorisation request refused by the acquirer.

The transaction created by duplication is included in the Transactions report and displayed in the Extranet.

Reports: you receive your reports by shop, 1.0 and 2.0 reports are not consolidated. The 2.0 reports isolate flows related to WL Sips 2.0 transactions.

This scenario allows you to benefit from the new 2.0 report format for your second shop. However, this option is not mandatory, you can keep the 1.0 format if you want to keep the existing reporting processing in your Back Office. This is valid for Transactions report, Operations report, Reconciliation report and Chargebacks reports types.

IMPORTANT: if you would like to keep reports in 1.0 format, you will not get strictly 2.0 data. The impacts are to be measured depending on the features and means of payment you have selected.

Extranet: you can keep the same URL and your existing login/password by using the super-user feature.

However, you do not have access to a consolidated history of your 1.0 and 2.0 transactions since you keep your existing login for your 1.0 shop and use a new login for your new 2.0 shop.

In 1.0 checks are made on the 1.0 fraud check tool.

In 2.0, you use the 2.0 fraud engine.

Checks not related to the means of payment (ex. customer outstanding payments, gray list, etc.) are not shared between 1.0 and 2.0.

The creation of lists in 2.0 is handled by the migration process.

There is a coexistence of 1.0 and 2.0 billing items.

Both shops are linked to the same charged customer with the same billing model.

  • Compartmentatlisation of fraud 1.0 and fraud 2.0.
  • Do not use the same means of payment in 1.0 AND in 2.0 with a single distance selling contract because the reconciliation does not work properly when several shops of the same merchant have the same acquisition contract.

Please find in this appendix a summary table of the reference documents available to accompany your migration:

Need Reference documentation
Connectors Sips Paypage documentation
Sips Office documentation
Sips Office Batch documentation
Pages customisation Pages customisation
Reports 1.0 2.0 reports correlation guide
Fields 1.0 2.0 data correlation guide
Data dictionary Data dictionary
Online documentation https://documentation.sips.worldline.com/en/
Sips Office Extranet Sips Office Extranet
Sips Download Sips Download
CustomPages CustomPages

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