WL SIPS DOCS

Release 24.2

go directly to content

Search by keywords

  1. Means of payment
  2. Payment facility
  3. CACF_3X CACF_4X

CACF_3X CACF_4X

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 CACF_3X and CACF_4X mean of payment integration integration into Worldline Sips.

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 Worldline Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Understanding CACF_3X and CACF_4X payments with Worldline Sips

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:


Screenshot showing the fields for entering personal data

Screenshot showing the fields for entering personal data such as date of birth or mobile number as well as a payment summary with the details of the chosen deadlines. This page contains a Validate button to go to the next step.


Screenshot showing the input fields for the payment data

Screenshot showing the input fields for the payment data containing the card number, the validity date and the visual cryptogram.this page contains a Validate button to go to the next step and a Cancel button to stop the payment.

The payment ticket is displayed, then the customer returns to your website:


Screenshot of the validation page of the pre-contractual conditions

Screenshot of the validation page of the pre-contractual conditions. The payment summary is also displayed there.

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

Worldline Sips offers you two solutions to integrate the CACF_3X and CACF_4X means of payment:

  • Sips Paypage which directly acts as the payment interface with clients 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 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:


Diagram of the payment process.

The transaction is switched to Validation mode with a capture_mode Validation or to Cancel mode with a capture_mode Author_capture. With a response_code 00, a status To Validate in Validation mode or a status To capture in Cancellation mode is retrieved. With a response_code 17, the status is Aborted. For all other codes, the status is Refused.

Making a CACF_3X and CACF_4X payment with Sips Paypage

The payment process for Sips Paypage is described below:


Payment kinematics with Paypage

1- The customer proceeds to the payment (finalization of the order) 2- Customer is redirected to the payment page 3- Redirection to the payment page 4- Customer is redirected to Sips (payment finalization) 5- The customer is redirected to the merchant site (manual response) 6- The Sips engine sends an automatic response to the merchant site
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 Worldline Sips 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_4X
paymentMeanType = ONELINE_CREDIT
responseCode = 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 Sips Office

The payment process for Sips Office is described below:


Payment kinematics with Office

1- The customer makes the payment (order finalization) 2- The merchant initializes the payment (PaymentProviderInitialize) 3- The merchant redirects the customer (redirectionUrl) 4- The customer is redirected to the merchant's website (merchantReturnUrl) 5- The merchant finalizes the payment (PaymentProviderFinalize) 6- The merchant displays the payment result.
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 Worldline Sips 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 = 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 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.

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

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
Credit X

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


Diagram describing the possible cash operations on the transactions.

For a transaction in To Validate status, either it expires or it is validated and passes to To Capture. When the transaction is in To Capture, you can make a partial cancellation and the remaining amount to be debited remains in To Capture status. You can also cancel it completely and the transaction will go to the status Cancelled. If no action is taken on the transaction, it goes to the status Captured. Once it is in Captured status, you can make a partial refund and the transaction remains in Captured status; you can also make a total refund and the transaction changes to Credited status.

Viewing your CACF_3X and CACF_4X 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 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
Note: for CACF_3X and CACF_4X transactions, the paymentMeanBrand field is populated with values CACF_3X or CACF_4X. 

Sips Office Extranet

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

Here are the details of a CACF_3X and CACF_4X transaction:


detail of the transaction

Capture of the detail of the transaction indicating that in the field Payment method CACF 3X or CACF 4X is recovered
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