Introduction
Sherlock's 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 Sherlock's.
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 Sherlock's solution, we advise you to consult the following documents:
- Functional presentation
- Functionality set-up guide
Understanding Lydia payments with Sherlock's
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.
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 a Sherlock's contract.
Making a payment
Sherlock's offers you two solutions to integrate Lydia:
- Sherlock’s Paypage which directly acts as the payment interface with customers via their browser.
- Sherlock’s 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:
Making a payment with Sherlock’s Paypage
The payment process for Sherlock’s Paypage is described below:
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 Sherlock's 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 |
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 =
LYDIApaymentMeanType =
PROVIDERresponseCode =
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 Sherlock’s Office
The payment process for Sherlock’s Office is described below:
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 Sherlock's and Lydia pages. |
paymentPattern | Forced to ONE_SHOT |
orderId | Mandatory |
customerContact.email | Conditional |
customerContact.mobile | Conditional |
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 =
00redirectionData = 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.
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 =
LYDIAresponseCode =
00transactionStatus = (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:
Viewing your transactions
Reports
The reports provided by Sherlock's 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 |
Sherlock's Gestion
You can view your Lydia transactions and perform various cash management operations with Sherlock's Gestion.
Here are the details of a Lydia transaction: