WL SIPS DOCS

Release 24.2

go directly to content

Search by keywords

  1. Means of payment
  2. Wallets and mobile payment
  3. Lydia

Lydia

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

Introduction

Worldline 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 Lydia means of payment integration into Worldline Sips.

Who does this document target?

This document is intended to help you implement the Lydia 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 Worldline Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Understanding Lydia payments with Worldline Sips

General principles

Lydia is a French company offering a mobile application that allows customers to register their card or bank account to process proximity and online payments. Lydia is an e-Wallet solution.

When doing an online payment with Lydia, Lydia sends a payment notification to the customer's mobile phone for them to validate their transaction through the dedicated mobile application.

In case the customer doesn't have a Lydia account, they are still able to finalise their payment by filling their card details.

Acceptance rules

Available functionalities
Payment channels
Internet V Default payment channel
MOTO X
Fax X
IVS X
Means of payment
Immediate payment V Default method
End-of-day payment X
Deferred payment X
Payment upon shipping X
Payment in instalments X
Subscription payment X
Batch payment X
OneClick payment X
Currency management
Multicurrency acceptance V EUR and GBP only
Currency settlement X
Payment pages
Shopping with mobile application

By choosing to pay with Lydia, the customer is redirected to a "waiting validation" page (see capture hereunder) and receives a notification on their mobile phone for them to accept the payment with the dedicated mobile application.


open the lydia application or click on "I prefer to type my credit card numbers".

Once the payment is validated, the customer is redirected to the receipt page.

Shopping with card

In case the customer doesn't have a Lydia account once they choose to pay with Lydia, the payment can still be fulfilled.

The customer can click on "I prefer to enter my card data" on the "waiting validation" page. They are then invited to enter their card details to finalise the transaction.



Once the payment is done, the customer is redirected to the receipt page.

Signing your Lydia acceptance contract

In order to offer the Lydia means of payment on your website, you have to sign an acceptance contract with Lydia. Thereafter, you transmit us the contract number for recording in our information system.

Making a payment

Worldline Sips offers you two solutions to integrate Lydia:

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

The remittance mode available for a transaction is the following:

  • Immediate mode: the authorisation and the remittance are performed online simultaneously.

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



If response code is equal to 17, the transaction goes to ABORTED. If capture mode is equal to "IMMEDIATE" the transaction goes to immediate mode, then if response code is equal to 00 then the transaction goes to CAPTURED otherwise REFUSED

Making a payment with Sips Paypage

The payment process for Sips Paypage is described below:



The customer proceeds to the payment (finalization of the order). Customer is redirected to the payment pages. The customer selects the Lydia payment method. This redirects him to the Lydia pages. Two possible choices: triggering the Lydia client mobile application or choosing to pay by credit card. Then the customer returns to SIPS. On return the ticket with the payment result is displayed. Finally the customer is redirected to the merchant site
Setting the payment request

The following fields have a particular behaviour:

Field name Remarks/rules
captureMode Tհe value sent in the request is ignored.
The capture mode is forced to IMMEDIATE.
captureDay Tհe value sent in the request is ignored.
The capture delay is forced to 0.
customerLanguage Allows to choose the language used on Worldline Sips and Lydia pages.
paymentPattern Tհe value sent in the request is ignored.
The payment type is forced to ONE_SHOT.
orderId Mandatory
CustomerContact.email Conditional
CustomerContact.mobile Conditional
Attention: it is mandatory to fill the customer's e-mail address or their mobile phone number in the payment request to identify the customer with Lydia.
Analysing the 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).
paymentMeanBrand = LYDIA
paymentMeanType = PROVIDER
responseCode = 00
 You can deliver the order.
Pending transaction acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 60
 The transaction is still being processed.
You will receive a new response with a final status in 30 minutes.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 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.

Making a payment with Sips Office

The payment process for Sips Office is described below:



The customer makes the payment (order finalization). The merchant initializes the payment (PaymentProviderInitialize). The merchant redirects the customer to the Lydia pages (redirectionUrl). Two possible choices: triggering the Lydia mobile client application or choosing to pay by credit card. The customer is redirected to the merchant site (merchantReturnUrl). The merchant finalizes the payment (PaymentProvideFinalize). The merchant displays the payment result.
Initialising a payment (PaymentProviderInitialize)

The payment initialisation is done by calling the method paymentProviderInitialize.

Payment initialisation request

The following generic fields are defined in the case of a payment initialisation:

Field name Remarks/rules
merchantReturnUrl Merchant return URL.
paymentMeanBrand Must be populated with LYDIA.

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

Field name Remarks/rules
captureMode Forced to IMMEDIATE
captureDay Tհe value sent in the request is ignored.
The capture delay is forced to 0.
customerLanguage Allows to choose the language used on Worldline Sips and Lydia pages.
paymentPattern Forced to ONE_SHOT
orderId Mandatory
customerContact.email Conditional
customerContact.mobile Conditional
Attention: it is mandatory to fill the customer's e-mail address or their mobile phone number in the payment request to identify the customer with Lydia.
Payment initialisation response

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

Status Response fields Action to take
Payment initialisation accepted acquirernativeResponseCode = 00
messageVersion = message version retrieved in response to the payment initialisation.
responseCode = 00
redirectionData = redirection data retrieved in response to the payment initialisation.
redirectionUrl = redirection URL to the mean of payment website.
 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).
responseCode = 05
 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 customer to the means of payment website

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

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

Field name Remarks/rules
responseCode Redirection processing 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 Lydia 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 Worldline Sips.
Payment finalisation request

You must provide the following specific fields in the finalisation request for a payment Lydia.

Field name Remarks/rules
redirectionData Redirection data retrieved after the customer returns to your website (cf. Redirecting the customer to the means of payment website).
messageVersion Message version retrieved after the customer returns to your website (cf. Redirecting the customer to the means of payment 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).
paymentMeanBrand = LYDIA
responseCode = 00
transactionStatus = (cf. the Data Dictionary).
 You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 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 Lydia transactions

Available cash operations

The following operations are available on transactions:

Cash management
Cancellation X
Validation X
Refund V
Refund allowed on the full amount or on a partial amount of the transaction.
Duplication X

The diagram below explains which cash management operation is available when a transaction is in a given state:



Partial repayment is possible in "CAPTURED" status and will keep the "CAPTURED" status. A total refund will change the status from "CAPTURED" to "CREDITED".

Viewing your transactions

Reports

The reports provided by Worldline 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 transactions for each type of report is summarised in the table below:

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

Sips Office Extranet

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

Here are the details of a Lydia transaction:


reference, identifier, date, amount, status, server response and some others information

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