Introduction

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.

Who does this document target?

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

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

Contacting the support

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).

Migration steps

Timing

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:

Step Stakeholders Description
1 Customer Customer request
2 Worldline Situational analysis of the merchant profile, cartography, presentation of migration and toolkit remittance
3 Customer Migration selection
4 Customer/ Worldline Validation Design + planning + technical choice
5 Customer Customer developments to connect to 2.0 and adapt to pages customisation
6 Worldline Shop registration in receipt
7 Customer Functional recipe 2.0
8 Worldline Shop registration, production and data migration
9 Customer Recipe VP. Migration date
10 Worldline Tracking flows after startup
11 Customer/ Worldline Removing references to WL Sips 1.0 on the merchant site/access removing

The specific migration schedule is defined in step 4, once the technical choice is made by the customer with the assistance of Worldline .

Migration process

This migration process describes the necessary steps that you must follow in order to successfully migrate to WL Sips 2.0.

Initial status

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 benefit from consolidated reports and a visualisation of all your transactions on the extranet ( Sips Office Extranet ) with all payment methods combined.

Flow migration to 2.0

You are piloting the migration. After issuing your recipe VP, the decision of the date and time of migration is made 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.

Return procedure

In case where you detect an anomaly (unidentified problem during the recipe phase of your internal developments), it is possible to migrate the flows on WL Sips 1.0 via the APIs.

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

Support

A support device makes the migration easier for you and guarantees the success of:

  • the presentation
  • the advise
  • the support

The Worldline sales team is in charge of presenting the WL Sips 2.0 solution. They could explain to you the technical and functional inputs of our solution evolution.

Worldline Account Support Managers (ASMs) who are in daily contact with you, have a good knowledge of your overall operation and the usage of our product. They are responsible for performing a cartography (usage profile) to cover the entire functional and technical scope.

Following this examination, the sales team presents the migration process and their support toolkit (general presentation, correlation guides, implementation guides).

When you (technical team or subcontractor) have read the documentation placed at your disposal and have defined your solution, a technical appointment with Worldline validates the design of the solution.

The creation stage of the recipe shop is supported by the technical sales team.

You (or your service provider) can then start the development stage and (possibly) the payment pages personalisation. The Worldline technical and functional teams are there to support and provide all the details necessary for the proper implementation.

When customer developments are made, the functional recipe 2.0 can start and a special assistance is set up by Worldline to make it easier (help setting up the fraud, new response code, etc.).

Once the tests are finalised, the shop is registered in production, the data is migrated by Worldline and a particular monitoring is made during the startup and the following weeks in order to verify the good progress of the migration to WL Sips 2.0.

Migration principles to WL Sips 2.0

What is available in 2.0?

Features

Features interface (mode) Payment 1.0 Sips Paypage 2.0 Sips Office 1.0 Sips Office 2.0 Sips Office Batch 2.0 Sips In-App Subscription Sips Walletpage 2.0
Secure paypages management
Pages customisation V V X X X X V V
Payment methods selection display V V X X X X V V
Ticket display by WL Sips V V X X X X V X
Payment attempts number V V X X X X V V
New payment attempt X V X X X X X X
Presence duration on the payment pages V V X X X X V X
Captcha test X V X X X X X V
Shop name display V V X X X X X V
Card number entry in separate blocks X V X X X X X V
Virtual keyboard X V X X X X X V
Cardholder name entry X V X X X X X V
Error page optional display X V X X X X X X
Sensitive information entry hiding X V X X X X X V
Waiting message display X V X X X X X X
Iframe tag V V X X X X V V
Payment channel
INTERNET V V V V V X V V
MOTO V V V V V X V X
In App mobile X X X X X V X X
Payment remittance terms
End-of-day payment V V V V V V V X
Deferred payment V V V V V V V X
Payment on despatch V V V V V V V X
Payment in instalments V V X X X X X X
Immediate payment V V V V V V X X
Authorisation period of validity V V V V V V V X
Payment in currency
Multi-currency acceptance V V V V V V V X
Currency settlement V V V V V V V X
Dynamic currency conversion V V X X X X X X
3-D Secure
3-D Secure (VISA/MC/AMEX) V V V V X V X V
3-D Secure dynamic bypass V V X X X X X X
3-D Secure bypass for OneClick payments V V X X X X X X
Transactions refusal, 3-D error V V V V X V X V
OneClick - merchant wallet management
Registration and payment V V X X X V X X
Payment V V V V V V X X
Wallet creation outside of payment X X V V V X X V
Wallet data reading X X V V V X X V
Payment methods data reading X X V V V V X V
Adding a payment method outside of payment process V X V V V X X V
Payment method updating outside of payment process V X V V V X X V
A payment method removal V V V V V X X V
Wallet removal X X V V V X X V
Recurring payment
1st recurring payment V V V V V V V X
Payment in instalments X X V V V V X X
Bill payment
Standard payment X V X X X X X X
OneClick payment X V X X X X X X
Cash management
Cancellation X X V V V X X X
Validation X X V V V X X X
Refund X X V V V X X X
Uncapped refund X X X V V X X X
Duplication X X V V V X X X
Extended duplication X X V V V X X X
Forcing (stopped in 2.0 to meet PCI regulatory requirements) X X V X X X X X
Recycling X X X V V X X X
Cardholder credit X X V V V X X X
Online reporting
Diagnostic X X V X X X X X
Automatic response V V X X V V V V
Manual response V V X X X V V V
Confirmation to customer at the end of the transaction V V X V X X X X
Reporting file
Transactions report V V V V V V V X
Operations report V V V V V V V X
Reconciliations report V V V V V V V X
Chargebacks report V V V V V V V X
Expired cards report V V V V V V X X
Tokenisation
Token return X V X V X X X X
Hashed PAN return X V X X X X X X
Card numbers tokenisation X X X V V X X X
Card numbers detokenisation X X X V X X X X
Transaction tokenisation X X X V V X X X
Payment via a token X X X V V X X X
Cardholder credit via a token X X X V V X X X
Entity acting for a customer
Intermediate Service Provider (ISP) X V X V X V X V
Country specificity
Brand selection (MIF) X V X V V V X X
Address Verification Service (AVS) X V X V V X X X
Costs overload X V X X X X X X
ARP (Advance registration program) X V X X X X X X

Payment means

Interface (mode) Moyens de payement Payment 1.0 Sips Paypage Sips Office 1.0 Sips Office Sips Office Batch Sips In-App Sips Walletpage
CB V V V V V V V
Visa V V V V V V V
MasterCard V V V V V V V
American Express V V V V V V V
VPay X V X V V V V
Maestro V V V V V V V
Visa Electron V V V V V V V
AcceptGiro X V X X X X X
Airplus SNCF X X V X X X X
Bancontact V V V V X V V
Buybox V X V V X X X
Carte Casino BCACUP X X V V X X X
Carte Oney V V X V X X V
Carte Oney Cadeau V V X V X X X
Cetelem Aurore V V V V X X X
Cetelem Aurore Visa (CVA) V V V V X X X
Cetelem Full CB X V X X X X V
Cetelem NXCB V V X X X X X
Cetelem Presto V V X X X X X
Cofidis 1euro.com V V X X X X X
Cofidis 3X V V V X X X X
Cofidis 4 étoiles V X V X X X X
Cofidis 4xCB X V X X X X X
Cofinoga V X V X X X X
Cofinoga 3XCB V V V X X X X
Delta V use visa V use visa use visa use visa use visa
Diners V X V X X X X
e-Chèques Vacances X V X V X X X
ELV V V V V X X X
Facilypay (Accord 3X4) [replaced by Oney 3X 4X] V V X X X X X
Finaref privatives V X V X X X X
Lyf Pay X V X X X X X
Franfinance 3XWEB V V X X X X X
Franfinance 4XWEB X V X X X X X
Franfinance privatives V X V X X X X
Franfinance Solution Sprint Secure V X X X X X X
Giropay X V X X X X X
iDEAL V V X V X X X
Incasso X V X X X X X
JCB V X V X X X X
Masterpass V V V V X X X
NetBanking X V X X X X X
PayButton ING X V X X X X X
PayButton KBC/CBC X V X X X X X
Paylib V V X V X X X
PayPal V V V V X X V
Paytrail X V X X X X X
PostFinance X V X X X X X
Rembours X V X X X X X
S2P CBPASS V X X X X X X
S2P PASS V X X X X X X
S2P PASS2 V X X X X X X
S2P Visa PASS Belgique V X X X X X X
SEPA Direct Debit V V V V V X X
Sofortüber weisung V V X V X X X
Switch V use MC V use MC use MC use MC use MC

What changes in 2.0?

Connectors

  • New non-intrusive connectors to replace APIs,
  • New secret key per shop that replaces the WL Sips 1.0 certificate.

Please refer to the documentation:

  • Payment Migration Guide 1.0
  • Sips Office Migration Guide 1.0 .

Payment means

  • New international payment methods,
  • Existing payment methods 1.0 not yet reported.

Please refer to the documentation:

  • List of available payment methods and the launch schedule (§ 3.1.2),
  • Implementation guides for different payment methods.

Transactions identification

Recall to existing 1.0

On WL Sips 1.0, the transaction identification system is ensured 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 the merchant or attributed by WL Sips in the merchant's delegation at the time of the payment request (that is to say before the authorisation request). This value must be unique for the combination of the 3 previous fields.

Operations associated with a transaction are identified by a fivefold increase, the previous 4 fields populated with an operation_sequence .

Transactions identification generation

As on WL Sips 1.0, the default mode for generating the identifier of the transaction is the generation made by you. 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 generation 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-generation, this control cannot be performed.
  • The absence of TransactionId or TtransactionReference 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 case of malfunction (example: Response not received by the merchant, etc.).

The TransactionReference

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

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

  • to keep this unique identifier unlimited (over the period of transaction existence in WL Sips : 15 months) instead of one day for TransactionId ,
  • to use alphanumeric characters in the reference with an open format enabling the generation by you,
  • to be independent of time zones (internationalisation).

The compatibility

In order to minimise the impact for 1.0 merchants who want it, the use of transactionId is hold in WL Sips 2.0.

On WL Sips 2.0, you must be in one of two modes:

  • TransactionReference mode (default mode)
  • TransactionId mode

If you wish to remain in TtransactionId mode you must make a request to WL Sips when registering your merchant ID to the WL Sips 2.0 offer.

All transactions on WL Sips 2.0 are both TransactionId + TransactionIdDate and TransactionReference related.

TransactionId , TransactionIdDate and TransactionReference are stored, restored and displayed for all transactions.

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

In summary:

  • 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 couple s10TransactionId + s10TransactionIdDate ensures the uniqueness of the transaction.

The use cases

Transactions creation

During a transaction creation, and according to the chosen mode, WL Sips accepts or rejects the creation and generates additional identifiers. The table below summarises the different 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 Transaction Reference generated by you. Transaction Reference 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 .

s10Transaction Id

s10TransactionId Date

s10Transaction Id

s10Transaction Id Date

s10Transaction Id

s10Transaction IdDate

Content response

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

You connect to WL Sips without Transaction Reference (Tref auto) Transaction Reference 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
Transaction Reference provided by you.

Reject

Code = 12

N/A
Additional reference generated by WL Sips .

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Content response

s10Transaction Id

s10Transaction IdDate

Transaction Reference

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

Transaction Reference provided by you.

Reject

Code = 12

Reject

Code = 12

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

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

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
Transaction Reference provided by you.

Reject

Code = 12

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

s10Transaction Id

s10Transaction IdDate

Transaction Reference

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Content response

s10Transaction Id

s10Transaction IdDate

Transaction Reference

Cash operations

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

The table below shows the different opportunities.

Use cases Data Cash management
Boutique en mode TransactionReference
Original transaction generated with a TransactionReference . TransactionId provided by the merchant. OK
TransactionReference provided by you. OK
Consistent TransactionReference and TransactionId provided by the merchant OK
TransactionReference and TransactionId not referencing the same transaction provided by the merchant.

Reject

Code = 12

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

Reject

Code = 12

New transaction (duplication, recycling and cardholder credit). See the transaction creation table above.
Payment in instalments (via paypages)
  • TransactionId mode

To make a payment in TransactionId mode, you must send a TransactionId and a TransactionIdDate list to the payment request. WL Sips generates automatically 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 instalment via the TransactionReference mode, the merchant must send a TransactionReference list and the date of each due date in the payment request. WL Sips generates automatically a TransactionId for each transaction.

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

The payment in instalment is not compatible with the mode of automatic generation of the transaction reference by WL Sips .

Reporting
  • Reports

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

For duplicate and recycling operations, the original transaction is identifiable via the transaction report s10FromTransactionId , s10FromTransactionIdDate and TransactionTransferReference fields.

  • 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 , the two columns will always be present in Sips Office Extranet in the following screens:

  • list of transactions following a research
  • detail of a transaction.
The fraud – Populating the lists

The addition of PAN to gray lists via the transaction reference is possible via the use of TransactionId or TransactionReference .

Data and formats

  • Opportunity for you to keep the TransactionId and keep the reports in 1.0 format.
  • New format for automatic and manual requests and responses.

Please refer to the documentation:

  • Migration Guide Payment 1.0 ,
  • Migration Guide Sips Office 1.0 .

New format of your reports.

Please refer to the documentation:

  • 1.0 / 2.0 Reports correlation guide
  • Reports description

URLs

  • New URL for the payment part,
  • New URL for the Office part.

Please refer to the documentation:

  • Migration Guide Payment 1.0 ,
  • Migration Guide Sips Office 1.0 .

Fraud

In 1.0 the controls are made on the fraud control tool 1.0.

In 2.0, merchants use the new 2.0 fraud engine.

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

The bypass key words correspondence is described in the 1.0 / 2.0 Data correlation guide document.

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

  • The migration of gray lists 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
  • Anti-fraud controls 1.0 (Go-No-Go)
  • Anti-fraud controls 2.0 (Go-No-Go +)
  • Profiles by default
  • GUI RMS (Risk Management system): viewing / updating the configuration

Paypages

  • New payment pages
  • Web responsiveness

Please refer to the documentation:

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

What the merchant must do?

The different steps refer to the part Timing .

  • Choosing migration modalities (Step 3)
    • Choice of connectors according to the merchant operation mode.
    • Decision to remain in TransactionId or to move to TransactionReference .
  • Installing connectors (Step 5)

    • Transposition of 1.0 / 2.0 data (reports, fraud, etc.).
  • Customising payment pages if the chosen mode is paypage (Step 5)

    • Local test with a tool provided by Worldline .
    • CSS sending to WL Sips .
  • Using the customer recipe environment to test Sips Paypage and Sips Office applications with the available recipe shop (Step 7)

    • Recovery of recipe identifiers.
    • Recipe tests.
    • Verification of the performed tests.
    • Recipe VP sending to Worldline (Step 9).
  • Starting in production (Steps 9 & 10)

    • Checking the configuration of the shop in production.
    • Sending the start request to production.
    • Integration of the identifiers of the production shop.
    • Activation of the switch from the shop to WL Sips 2.0.
    • Startup monitoring of the migration.
  • Deleting references to WL Sips 1.0 on the merchant site: certificate, settings files, executable files etc. (Step 11).

Description of merchants uses cases

UC1 – Merchant in 1.0 who opens a new shop in 2.0

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

This scenario may be suitable in case you want to be able to quickly implement a new payment method for a shop without having to migrate all his flows, or to a merchant who uses payment methods not yet available in 2.0.

The merchant will have two shops, a WL Sips 1.0 for his current payment methods, and a second WL Sips 2.0 for one or more new payment methods.

The 2 shops are attached to the same customer, but the merchant will have 2 merchantId .

Merchant registration

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

Cash management

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

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 must include in your payment request the identifiers of the original shop and the original transaction:

  • fromMerchantId ,
  • fromMerchantId ,
  • s10FromTransactionIdDate .

The details of the payment method are recovered from the initial transaction by WL Sips . However, the merchant can modify the business data (order number, delivery method, etc.).

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

The performed controls are as follows:

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

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

Reporting

Reports : The merchant receives his reports by shop, reports 1.0 and 2.0 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.

Warning : if you want to keep reports in 1.0 format, you do not get purely 2.0 data. The impacts are to be measured according to the functionalities and payment methods that you have selected.

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

However, you don't 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.

Fraud

In 1.0 the controls are made on the fraud control tool 1.0.

In 2.0, merchants use the 2.0 fraud engine.

The controls not related to the payment method (ex. customer outstanding payments, gray list, etc.) are not shared between 1.0 and 2.0.

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

Billing

There is a coexistence of billing items 1.0 and 2.0.

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

Limits

  • Fraud-proofing between 1.0 and 2.0.
  • Do not use the same method of payment in 1.0 and 2.0 with one and the same distance selling contract because the reconciliation does not work properly when several shops of the same merchant have the same acquisition contract.

UC2 – Merchant using subscription

If you use the Subscription API, you have wallet functions in 2.0 through the Sips Walletpage connector.

You can also make offline payments without handling sensitive data by using Sips Office Batch with the office service and the walletOrder function of this service, and manage your wallet with the service wallet and all the functions of this service. The Sips Office Batch Integration guide document describes this opportunity.

There are some functional differences between Sips Walletpage and Subscription:

  • The Sips Walletpage offer does not store the cardholder personal data:

    • No name, first name, address,
    • No password.
  • The Sips Walletpage interface does not allow payment at enrolment:

    • the enrolment payment is already available via Sips Paypage .
    • If you wish to offer a payment at enrolment you will have to use Sips Paypage .
  • In the case where there are several payment methods in the wallet, you cannot use only the walletID to make a recurring payment. In this case, you must specify the walletID and the paymentMeanID . This obligation does not exist if the wallet is a single payment method.
  • There is no automatic response during a Wallet payment process management because the payment process allows the customer to perform several actions.

WL Sips Payment / Sips Office comparison

The following comparative table allows you to compare the advantages of different interfaces:

Criterion Sips Paypage interface Sips Office interface
Functional scope

Creating transactions only

Transaction creation and cash management.

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

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

You don't know the customer's PAN

In transaction creation, the management of the payment pages is done by you, it is therefore subject to the PCI-DSS certification.
Note:
you can limit your scope by not storing any PAN information in your information system (for example by replacing PAN with a token or a Wallet identifier or a hashPan). The tokenisation solution is part of the features table (§ 3.1.1) and can be presented to you by Worldline teams.
3-D Secure 3-D Secure process performed by WL Sips and transparent for you.
You control the 3-D Secure authentication process.
Note: you have the option to use the MPI WL Sips to manage the exchanges with the Visa / MC directory servers.
Integration effort Plug & Play solution easy to integrate Solution requiring more development: onboard payment on merchant side with the payment pages management.
Adding a payment method

Without development effort for you in most cases.

Note: you must sometimes populate specific fields in the payment request to benefit from the payment methods options (PayPal example).
Development effort on the merchant side to integrate the payment method (payment process management, pages management, etc.).
Customer experience Limited break between your website and the payment server due to the payment pages customisation that you can make (CSS, URL). No break between your website and the payment server.
Integration into your IS Interfaces with your shop Interfaces with your shop or back office.
Reporting Uniform reporting

Appendix 1 - Migration FAQ 122

Why migrate to 2.0?

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

  • simplify WL Sips integration and standardise connection methods: new state of the art WL Sips connectors.
  • optimise the customer experience: new features and new ergonomics of the customer interfaces (InApp application, webresponsive, etc.).
  • have more autonomy in the management of his transactions and merchant settings: new Extranet interface.
  • facilitate the deployment on the international market: new payment methods.
  • benefit from advanced features: effectively fight against fraud, dashboard, etc.

Can I keep the same MerchantID 1.0 in 2.0?

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

Can I view in 2.0 the transactions created in 1.0?

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

Can I validate a 1.0 transaction in 2.0?

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

Can I cancel a 1.0 transaction in 2.0?

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

Can I refund a 1.0 transaction in 2.0?

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

Can I duplicate a 1.0 transaction in 2.0?

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

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.

Can I continue to receive reports in 1.0 format?

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 benefit from the new 2.0 reports format at your convenience.

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

Can I view TransactionId on 2.0 format reports?

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

What is the TransactionReference contribution related to TransactionId?

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

  • to keep this unique identifier unlimited (over the period of transaction existence in WL Sips : 15 months) instead of one day for TransactionId.
  • to use alphanumeric characters in the reference with an open format enabling the generation by you.
  • to be independent of time zones (internationalisation).

Can I switch from TransactionId mode to TransactionReference mode?

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 to benefit from the advantages of this new format.

Can I switch from TransactionReference mode to TransactionId mode?

If you have opted for the TtransactionReference 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.

Can I migrate to 2.0 without customising my payment pages?

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

Can I keep the same personalisation of payment pages?

There is no migration tool that reproduces the customisation of 1.0 payment pages. We don't recommend attempts to reproduce exactly the visuals of the 1.0 payment pages on the 2.0 payment pages. Indeed, it is a pity to deprive oneself of the new opportunities offered by the 2.0 payment pages, especially on the aspect of adaptability to the screens size.

Can I change the personalisation of the payment pages?

It is recommended to change the payment pages personalisation in order to benefit from the advantages of the 2.0 payment pages.

A customisation guide for the pages is made available to you.

Can I use the existing 1.0 wallet base?

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

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

What are the payment methods available in 2.0?

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

What are the fraud controls available in 2.0?

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

Which currencies are accepted in 2.0?

Accepted currencies depend on the acquirer’s contract. The currencies planned 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.

What are the French acquirers available in 2.0?

  • 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

How to validate that my migration is OK?

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

When you have finished your recipe, you provide a recipe VP and determine in agreement with Worldline the date and time of your migration.

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