WL SIPS DOCS

Release 22.4

go directly to content

Search by keywords

  1. Means of payment
  2. Wallets
  3. Paylib integration

Paylib integration

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

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

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

Who does this document target?

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

It includes:

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

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

  • Functional presentation
  • Functionality set-up guide

Understanding Paylib payments with WL Sips

General principles

Paylib is a wallet carried by French banks allowing to make secure and guaranteed card payments.

To qualify for Paylib, customers must sign up for the electronic wallet via their online banking.

On the web payment process, the customer is redirected to the Paylib website to authenticate and choose their credit card.

Acceptance rules

Available functionalities
Payment channels
Internet V Default payment channel
MOTO X
Fax X
IVS X
INAPP V Mandatory payment channel for mobile app payment by (available only on Sips Office).
Means of payment
Immediate payment X
End-of-day payment V Default method
Deferred payment V Limited by default to 6 days to benefit from the Paylib payment guarantee. You must subscribe to a specific option to get Paylib payments over 6 days.
Payment upon shipping V Limited by default to 6 days to benefit from the Paylib payment guarantee. You must subscribe to a specific option to get Paylib payments over 6 days.
Payment in instalments X
Subscription payment X
Batch payment X
OneClick payment V
Currency management
Multicurrency acceptance X EUR only
Currency settlement X EUR only
Authorisation request

The Paylib payment guarantee is linked to the result of the authorisation request made on the card chosen by the customer.

For this reason, the maximum time allowed for a Paylib payment is 6 days (except in the special case of the "Paylib payment beyond 6 days" option described below).

If you fill in a longer capture delay, it will be automatically forced by the payment platform.

Payment remittance in the bank

Payments are remitted to a bank according to the payment terms you set. As standard, the remittance in bank is triggered at night as from 10 pm CET (Central European Time) via a file exchange with the acquirer.

Specific case: payments beyond 6 days

By default, the Paylib means of payment limits the transaction capture delay to a maximum of 6 days in order to guarantee the payment.

However, it is possible to create Paylib transactions with a capture delay beyond 6 days.

For this, you will have to subscribe to a "Paylib payment beyond 6 days" option.

If you have subscribed to the "Paylib payment beyond 6 days" option, you will be able to create transactions with a capture delay of up to 20 days.

If you specify a longer delay, it will be automatically forced by the platform.

During a Paylib payment beyond 6 days, the authorisation request to the acquirer will not be made online. The payment platform will make a card number control in lost and stolen card list to verify that the card has not been declared lost or stolen.

The authorisation request will be made:

  • either during the payment validation if the transaction was carried out in "Validation" mode.
  • or before remittance if the transaction was carried out in "Cancellation" mode.

Since the payment guarantee is supported by the authorisation request, it is important to note that, even if the transaction was indicated as accepted when it was created, it will only be guaranteed when this authorisation request is accepted.

It is therefore advisable, in this operating mode, to send the package to the customer only once the result of this authorisation request is known.

Anti-fraud controls

If you have a fraud profile applied to CB/VISA/MASTERCARD cards, it is also applied to payments made via Paylib.

Signing your Paylib acceptance contract

In order to offer Paylib payment, you must hold a distance selling contract with your French banking institution and with your Paylib reseller (usually your banking institution). In order to activate Paylib on WL Sips, you must provide us with your Paylib reseller name, and specify if the "Paylib payment beyond 6 days" option activation is authorised by your reseller.

Activating the payment Paylib OneClick (optional)

If you wish, WL Sips allows you to accept OneClick payments with Paylib.

You have to be subscribed to the WL Sips OneClick service (contact the support).

You have to be subscribed to the WL Sips OneClick service (contact Worldline).

You will then have to provide a unique wallet ID (the merchantWalletId field) per customer during your payment requests.

Making a Paylib payment

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

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

The remittance modes available for a Paylib transaction are:

  • Cancellation mode: default mode allowing transaction remittance on a predefined date, called capture delay. When this capture delay is reached, the remittance is sent automatically. This delay is set via the captureDay field with its 0 default value (end-of-day payment).
  • Validation mode: you must validate the transaction to trigger the remittance. A capture delay must also be defined. When this capture delay is reached or exceeded, you will not be able to validate the transaction, which will therefore expire automatically.

The diagram below explains the different transaction statuses according to the chosen capture mode:


possible status for a paylib transaction

In validation mode, four statuses are possible. If the transaction is aborted, the status becomes ABORTED (responseCode 17). If the transaction is rejected, the status becomes REFUSED (responseCode different from 00). When the transaction is accepted (responseCode 00), if the captureDay is less than or equal to 6, the transaction must be validated and the status becomes TO_VALIDATE. If the captureDay is greater than 6, the status of the transaction becomes TO_REPLAY. In cancel mode, the status ABORTED and REFUSED also exists. On the other hand, when the transaction is accepted, if the captureDay is less than or equal to 6, the status becomes TO_CAPTURE. If the captureDay is greater than 6, the status becomes TO_AUTHORIZE.

Making a Paylib Payment with Sips Paypage

The payment process for Sips Paypage is described below:


steps of a paylib payment via paypage

1) The customer makes the payment. 2) He is redirected to the payment pages hosted by WL Sips and chooses to pay with Paylib. 3) He is redirected to the Paylib pages where he identifies himself and pays. 4) He is redirected to the WL Sips. 5) If the customer has clicked on the "back to the store", WL Sips sends the manual response. 6) WL Sips sends the automatic response.
Setting the payment request

The following field has a particular behaviour:

Field name Remarks/rules
captureDay
If you have the "Paylib payment beyond 6 days" option, the capture delay will be forced to 20 days if a longer delay is indicated in the request.
If you do not have this option, the capture delay will be forced to 6 days if a longer delay is indicated in the request.
Analysing the response

In order to qualify for Paylib, you need to upgrade to version 2.6 (or higher) of automatic and manual responses.

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

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

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

OneClick payment

You have the option to accept OneClick payments with Paylib on Sips Paypage. You must have subscribed to the OneClick service of WL Sips (see the Activating the payment Paylib OneClick paragraph).

You have then to transmit in each payment request the merchantWalletId field associated with your customer .

The following page is displayed when enrolling a Paylib account in the wallet WL Sips:



If a Paylib account has already been added to the wallet WL Sips, the following selection page will be displayed:



Two separate pages should be displayed depending on your client's authentication method:

  • an OTP authentication page, including an one-time code entry field


  • an authentication page on Smartphone without entry field


Making a Paylib payment with Sips Office

The payment process for Sips Office is described below:


steps for a Paylib payment with office

1) The customer proceeds with payment. 2) You initialize the payment by sending a paymentProviderInitialize request to WL Sips which returns the redirectUrl for the payment to proceed. 3) Thanks to the redirectUrl, you redirect your customer to the Paylib page page where he identifies himself and pays. 4) The customer comes back to your site. 5) You finalize the payment by sending a paymentProviderFinalize request to WL Sips which returns you the payment result. 6) You display the payment result to your customer on your website.
Initialising a payment (PaymentProviderInitialize)

The Paylib payment initialisation is done by calling the paymentProviderInitialize method.

Payment initialisation request

You must populate the following specific fields in the initialisation request for a Paylib payment:

Field name Remarks/rules
paymentMeanBrand Must be populated with PAYLIB.
captureDay If you don't benefit from the "Paylib payment beyond 6 days" option, the capture delay will be forced to 6 days if a longer delay is indicated in the request. If you benefits from this option, the capture delay will be forced to 20 days if a longer delay is indicated in the request.
orderChannel If you wish to make an In-App payment, the keyword to send is "INAPP". The default value is "INTERNET" and will trigger a web payment.
Payment initialisation response

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

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

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

Redirecting the client to the Paylib website

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

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

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

This last step allows you to obtain the payment status. The settings obtained during the redirection after the payment process on the Paylib website are to be transmitted during this call. The method used to finalise a payment is paymentProviderFinalize.

Tip: you can obtain a code 24 "Operation impossible" in response to your paymentProviderFinalize request. This code means that this request has already been sent and processed for the transaction in question. If you are unable to identify this processing, please use the GetTransactionData function of the diagnostic service: this operation allows you to retrieve information relating to a transaction previously created using the WL Sips.
Payment finalisation request

You have to populate the following specific fields in the finalisation request for a Paylib payment.

Field name Remarks/rules
redirectionData Redirection data retrieved after the customer returns to your website (cf. Redirecting the client to the Paylib website).
messageVersion Message version retrieved after the customer returns to your website (cf. Redirecting the client to the Paylib website).
Payment finalisation response

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

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

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

Managing your Paylib transactions

Available cash operations

The following operations are available on Paylib transactions:

Cash management
Cancellation V
Validation V
Refund V
Duplication V The transaction resulting from a duplication is not a Paylib transaction but a classic card transaction without a payment guarantee.
Recycling X
Credit X

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


Scheme too complex to describe. Please contact the support sips@worldline.com

Viewing your Paylib transactions

Reports

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

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

Reports availability
Transactions report V
Operations report V
Operations report V
Chargebacks report X
Note: for Paylib transactions, the paymentMeanBrand field is populated with the value PAYLIB.
Sips Office Extranet

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

From a back office point of view, Paylib transactions are likened to CB, VISA or MASTERCARD card transactions. You can identify payments made via Paylib by:

  • the payment data typing mode, set to "WALLET";
  • the electronic wallet, set to "PAYLIB".


Back to top Need help?

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