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 CACF_3X and CACF_4X mean of payment integration integration into Sherlock's.
Who does this document target?
This document is intended to help you implement the CACF_3X and CACF_4X mean of payment integration 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 CACF_3X and CACF_4X payments with Sherlock's
General principles
The CACF is a private mean of payment offered by major retailers, with the exclusive acquirer Crédit Agricole.
The CACF_3X and CACF_4X are credit means of payment in instalments with or without fees.
At the end of this type of payment, you are credited with the amount in one time and the cardholder will be debited in 3 or 4 times (depending on the chosen mean of payment).
Acceptance rules
Available functionalities
Payment channels | ||
---|---|---|
Internet | V | Default payment channel |
MOTO | X | |
Fax | X | |
IVR | X |
Means of payment | ||
---|---|---|
Immediate payment | X | |
End-of-day payment | V | |
Deferred payment | V | |
Payment upon shipping | V | |
Payment in instalments | X | |
Subscription payments | X | |
Batch payment | X | |
OneClick payment | X |
Currency management | ||
---|---|---|
Multicurrency acceptance | X | |
Currency settlement | X | |
Dynamic currency conversion | X |
Payment pages
The customer selects between CACF_3X, CACF_4X, CACF_3XSANSFRAIS or CACF_4XSANSFRAIS means of payment.
They are then redirected to the required information entry page:
The payment ticket is displayed, then the customer returns to your website:
Signing your CACF acceptance contract
In order to offer the CACF_3X and CACF_4X means of payment on your website, you have to sign an acceptance contract with Crédit Agricole Consumer Finance. Thereafter, you transmit us the contract number for recording in our information system.
Making a CACF_3X and CACF_4X payment
Sherlock's offers you two solutions to integrate the CACF_3X and CACF_4X means of payment:
- Sherlock’s Paypage which directly acts as the payment interface with clients via their web browser.
- Sherlock’s 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 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:
Making a CACF_3X and CACF_4X 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 |
AUTHOR_CAPTURE or VALIDATION |
captureDay |
The value sent in the request must be 8 at a maximum. A
larger value will be forced to 8. |
customerLanguage | Allows to choose the language used on Sherlock's and CACF pages. |
orderId |
Mandatory |
customerId |
Mandatory |
amount |
Mandatory |
deliveryData.deliveryMethod |
Optional (Check with Thunes to ontain an exhaustive list of value) |
customerContact |
For more details, cf. the tables below. |
billingContact |
For more details, cf. the tables below. |
billingAddress |
For more details, cf. the tables below. |
deliveryAddress |
For more details, cf. the tables below. |
shoppingCartDetail |
For more details, cf. the tables below. |
CustomerAccountHistoric |
For more details, cf. the tables below. |
CustomerData |
For more details, cf. the tables below. |
Field Name | Remarks/rules |
---|---|
customerContact.email |
Mandatory |
customerContact.title |
Optional |
customerContact.firstname | Mandatory |
customerContact.firstname |
Mandatory |
customerContact.mobile |
Optional |
customerContact.phone |
Optional |
Field Name | Remarks/rules |
---|---|
billingContact.title |
Mandatory {0,4} ANS (example : MR / MME / MLLE …) |
billingContact.firstname |
Mandatory |
billingContact.lastname |
Mandatory |
billingContact.mobile |
Mandatory |
billingContact.phone |
Mandatory |
Field Name | Remarks/rules |
---|---|
billingAddress.street |
Mandatory |
billingAddress.streetNumber |
Mandatory |
billingAddress.zipCode |
Mandatory |
billingAddress.city |
Mandatory |
billingAddress.country |
Mandatory |
billingAddress.addressAdditional1 |
Mandatory |
Field Name | Remarks/rules |
---|---|
deliveryAddress.street |
Optional |
deliveryAddress.addressAdditional1 |
Optional |
deliveryAddress.city |
Optional |
deliveryAddress.zipCode |
Optional |
Field Name | Remarks/rules |
---|---|
shoppingCartDetails.shoppingCartItemList.itemX.productCategory |
Optional |
shoppingCartDetails.shoppingCartItemList.itemX.productName |
Optional |
shoppingCartDetails.shoppingCartItemList.itemX.productQuantity |
Optional |
shoppingCartDetails.shoppingCartItemList.itemX.productUnitAmount |
Optional |
Field Name | Remarks/rules |
---|---|
customerAccountHistoric.numberOfPurchase |
Optional |
customerAccountHistoric.creationDate |
Optional |
customerAccountHistoric.lastPurchaseDate |
Optional |
customerAccountHistoric.numberOfUncancelledPurchase |
Optional |
customerAccountHistoric.numberOfScoringCancelledPurchase |
Optional |
Field Name | Remarks/rules |
---|---|
customerData.loyaltyIndicator |
Optional |
Analysing the response
The following table summarises the different response cases to be handled:
Status | Response fields | Action to take |
---|---|---|
Payment accepted | acquirerResponseCode = 00
authorisationId = (cf. the
Data Dictionary).paymentMeanBrand = CACF_3X or
CACF_4XpaymentMeanType =
ONELINE_CREDITresponseCode =
00 |
You can deliver the order. |
Pending transaction | acquirerResponseCode = (cf.
the Data Dictionary).responseCode =
60 |
You must wait until you receive the second automatic response for this transaction to know its final status and whether you can ship the goods. If you do not receive the automatic response, you will need to check the transactions report regularly. |
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 CACF_3X and CACF_4X payment with Sherlock’s Office
The payment process for Sherlock’s Office is described below:
Initialising a payment (PaymentProviderInitialize)
The CACF_3X and CACF_4X payments initialisation is made by calling the PaymentProviderInitialize method.
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 CACF_3X or CACF_4X. |
You must populate the following specific fields in the initialisation request for a CACF_3X or CACF_4X payment:
Field name | Remarks/rules |
---|---|
orderId | Mandatory |
customerId | Mandatory |
customerContact.email | Mandatory |
customerLanguage | Allows to choose the language used on Sherlock's and CACF pages. |
billingContact.title | Mandatory {0,4} ANS (example: MR / MME / MISS…) |
billingContact.firstname | Mandatory |
billingContact.lastname | Mandatory |
billingContact.mobile | Mandatory |
billingContact.phone | Mandatory |
billingAddress.street | Mandatory |
billingAddress.streetNumber | Mandatory |
billingAddress.zipCode | Mandatory |
billingAddress.city | Mandatory |
billingAddress.country | Mandatory |
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 of the paymentProviderInitialize method. This redirection consists in making a POST call on the redirectionUrl URL received in the 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 to POST and must be retrieved to finalise the payment.
Field name | Remarks/rules |
---|---|
responseCode | Redirection 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 means of payment 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 CACF_3X or CACF_4X.
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 = CACF_3X or
CACF_4XresponseCode =
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.
Analysing the response
Please refer to the paragraph Analysing the response.
Managing your CACF_3X and CACF_4X transactions
Available cash operations
The following operations are available on CACF_3X and CACF_4X transactions:
Cash management | ||
---|---|---|
Cancellation | V | |
Validation | V | |
Refund | V | |
Duplication | X |
The diagram below explains which cash management operation is available when a transaction is in a given state:
Viewing your CACF_3X and CACF_4X 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 the CACF_3X and CACF_4X 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 CACF_3X and CACF_4X transactions and perform various cash management operations with Sherlock's Gestion.
Here are the details of a CACF_3X and CACF_4X transaction: