3-D Secure

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

This document aims to explain how to implement 3-D Secure for the CB, VISA, MASTERCARD, Bancontact and AMEX means of payment up to the production start.

Who does this document target?

This document is intended for merchants and their technical teams wishing to implement 3-D Secure on their e-commerce website, for the CB, VISA, MASTERCARD, Bancontact and AMEX payment methods.

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

General points

Principle

3-D Secure is an authentication protocol designed to reduce the risk of fraud associated with online payments. Its purpose is to ensure that the card is used by its true holder.

When making a 3-D Secure payment, there is an additional step of authenticating the cardholder.

Attention: The DSP2 regulation makes strong authentication mandatory for online payments, deadline from which the first issuer refusals will be applied to transactions not 3-D Secure authenticated (acquirerResponseCode field = A1).

Attention: The 3-D Secure v1 protocol ends in October 2022 (see our announcement on the subject). Our documentation will then be updated.

Liability shift

In addition to enhanced security, 3-D Secure allows you to benefit from the liability shift to the card issuing bank. In the event of fraudulent payment, you are guaranteed to receive the funds, it is the cardholder's bank that bears this responsibility. In rare cases, the cardholder's bank may accept a request for authorisation but refuse this liability shift, in this case the payment is no longer guaranteed, and the holderAuthentRelegationCode field is set to Y.

These liability shift rules are issued by the CB, VISA, MASTERCARD and Bancontact schemes. If the payment is guaranteed, the guaranteeIndicator field is set to Y.

For more details on cases of eligibility for liability shift, please refer to paragraph Liability shift's calculation

Fields of application

3-D Secure applies in the following cases:

Single payment (described in this documentation)
Payment in instalments
Multiple payment uppon shipping
Subscription payment
- via wallet
- via duplication

New 3-D Secure 2.0 version

Despite obvious security benefits, 3-D Secure 1.0 (stopped since October 2022), deployed in France since 2007, does not provide an optimal user experience, and therefore has an impact on the conversion rate of online purchases.

To improve the user experience, the CB, VISA, MASTERCARD and AMEX networks now offer 3-D Secure 2.0 which provides a more optimal authentication system based on risk assessment and more suitable for smartphones.

Depending on the level of risk, issuing banks will decide whether or not to perform strong authentication of the client, this is an operating mode called "frictionless". The lower the risk, the higher the probability of obtaining a frictionless transaction.

Improvements made

To improve the user experience, the CB, VISA, MASTERCARD and AMEX schemes now offer 3-D Secure 2.0 that provides a more optimal authentication system based on risk assessment and more suitable for smartphones.

Depending on the risk level, issuing banks will decide whether or not to perform strong client authentication: this is an operating mode called "frictionless". The lower the risk, the higher the probability of a "frictionless" transaction.

Authentication amount

With 3-D Secure V2 and to be compliant with PSD2 :

payment in instalments must be set up with an authentication of an amount equals to the global order amount (with 3-D Secure V1, the authenticated amount was set to the first instalment only).
payment to set up a subscription must be authenticated with an amount equals to the average recurring payments.

Note: WL Sips allows you to specify a different amount than the one to authorise, through the use of the authenticationData.authentAmount field.

Activating the 3-D Secure option

The Revised Payment Services Directive (PSD2), making it mandatory to carry out strong authentication for payments initiated by the customer on the Internet or via a mobile application. 3-D Secure allows you to be in compliance for card payments with this new regulation. Without activating 3-D Secure, you are exposed to authorization denials due to un-authenticated transactions.

Therefore, unless you advise otherwise, any new webshop is registered on Worldline Sips with the 3-D Secure option activated by default.

If the 3-D Secure option is not activated on your webshop, please contact the Worldline Sips technical support to activate this option.

The activation of the 3-D Secure option is done in 2 steps:

step 1 = enrolment of your shop on the concerned directory servers (CB, VISA, MASTERCARD, AMEX, Bancontact)
- For the CB, Visa and Bancontact schemes, the enrolment is almost immediate.
- For MASTERCARD, the enrolment is completed in 7 days
- For AMEX, the enrolment is completed in 3 weeks
step 2 = activation of 3-D Secure when enrollment on DS is completed:

Additional options

Refusing transactions with a 3-D Secure error

In order to reduce the risk of chargebacks, you have the option to refuse all transactions for which a technical error has prevented the 3-D Secure authentication process from proceeding properly because those transactions do not benefit from the liability shift.

If you enable this option and a 3-D Secure error occurs during the 3-D Secure authentication, the transaction is rejected, with a response code 05 (responseCode field = 05) and the holderAuthentStatus field set to ERROR.

Accepting only guaranteed transactions

In order to ensure that you collect all the funds from your sales and avoid chargebacks, you have the option to refuse all 3-D Secure transactions for which the transfer of responsibility does not apply, even if the transaction has been authorised.

If you enable this option, non-guaranteed transactions (GuaranteeIndicator field = N, U or empty) are rejected with a complmentaryCode 17.

This option applies only to the transactions initiated by the cardholder and peformed with a CB, VISA and MASTERCARD card (registered or not in Worldline Sips or an external wallet).

This option doesn't apply :

to merchant initiated transactions (MIT)
to CITs non eligible to liability shift (PayPal transactions for example)
to CITs on which the 3-D Secure authentication has not been performed (cardOrder without 3-D Secure data for example)

Sips Paypage connector

Card payments

This chapter describes how to implement 3-D Secure for one-time payments.

Flows description

3-D Secure payment process with Paypage. Text description of this diagram just below

You redirect the customer to Sips Paypage by transmitting the transaction data (amount, currency, etc.) in the request.
Worldline Sips displays the payment page, the customer enters the card number, the security code and then validates.
Worldline Sips performs the 3-D Secure check.
Worldline Sips sends an authorisation request to the acquirer.
Worldline Sips saves the transaction into the back office.
Worldline Sips displays the payment receipt page.
Worldline Sips returns the manual and automatic responses that contain transaction details including the result of the 3-D Secure authentication.
Worldline Sips The software sends, or not, the transaction as a remittance according to the conditions you have set in the payment request.

The sequence described above is transposed to the CB, Visa, Mastercard and Amex means of payment.

Implementation

If your webshop is not a 3-D Secure one, please get in touch with the Worldline Sips technical support to activate the service.

Setting the payment request

You do not have any specific 3-D fields to fill in to offer 3-D Secure payments via Sips Paypage.

Please read one of the Sips Paypage guides to find out how to populate the request depending on your business need.

Analysing the response

Worldline Sips sends back a manual response and a standard automatic paypage response.

The fields pertaining to 3-D Secure payments are as follows:

Use case	Response fields
Authenticated holder	guaranteeIndicator = cf. Data dictionary holderAuthentProgram = connector version equal to or higher than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 process 3DS_V2: the holder authenticated themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process holderAuthentMethod = connector version equal to or higher than 2.24 if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: cf. Data dictionary. connector version lower than 2.24 NOT_SPECIFIED: whatever the process holderAuthentRelegationCode = N holderAuthentStatus = ATTEMPT or SUCCESS holderAuthentType = if process is 3-D Secure V1: not filled in if process is 3-D Secure V2: cf. Data dictionary.
Card not enrolled	guaranteeIndicator = cf. Data dictionary holderAuthentProgram = NO_AUTHENT holderAuthentMethod = connector version equal to or higher than 2.24 if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: NO_AUTHENT connector version lower than 2.24 NOT_SPECIFIED: whatever the process holderAuthentRelegationCode = N holderAuthentStatus = NOT_ENROLLED holderAuthentType = if process is 3-D Secure V1: not filled in; if process is 3-D Secure V2: NONE
The cardholder was not able to authenticate themselves, payment is inevitably refused.	guaranteeIndicator = N holderAuthentProgram = connector version equal to or higher than 2.24 3DS: the holder attempted to authenticate themselves using a 3-D Secure V1 process 3DS_V2: the holder attempted to authenticate themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process holderAuthentMethod = connector version equal to or higher than 2.24 if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: cf. Data dictionary. connector version lower than 2.24 NOT_SPECIFIED: whatever the process holderAuthentRelegationCode = N holderAuthentStatus = FAILURE holderAuthentType = if process is 3-D Secure V1: not filled in if process is 3-D Secure V2: CHALLENGE
Technical issue that prevented the successful completion of the 3-D Secure authentication.	guaranteeIndicator = cf. Data dictionary holderAuthentProgram = connector version equal to or higher than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 process 3DS_V2: the holder authenticated themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process holderAuthentMethod = if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: NOT_SPECIFIED holderAuthentRelegationCode = N holderAuthentStatus = ERROR holderAuthentType = if process is 3-D Secure V1: not filled in if process is 3-D Secure V2: NONE or CHALLENGE
Your webshop is not 3-D Secure enrolled.	guaranteeIndicator = not filled in holderAuthentProgram = NO_AUTHENT holderAuthentMethod = NO_AUTHENT_METHOD holderAuthentRelegationCode = N holderAuthentStatus = NO_AUTHENT holderAuthentType = not filled in
The holder cancels the authentication process.	guaranteeIndicator = N holderAuthentProgram = 3DS holderAuthentMethod = NOT_SPECIFIED holderAuthentRelegationCode = N holderAuthentStatus = FAILURE holderAuthentType = not filled in
The holder quits on the ACS page and closes their browser. You do not receive any manual response, but only an automatic response with the responseCode field set to 97.	guaranteeIndicator = not filled in holderAuthentProgram = not filled in holderAuthentMethod = not filled in holderAuthentRelegationCode = not filled in holderAuthentStatus = not filled in holderAuthentType = not filled in

Sips Office connector

Payment from a card number

Flows description

A 3-D Secure payment is made in 3 steps:

checking the customer's card enrollment
redirecting the customer to their bank's ACS
the 3-D Secure authorisation request

diagram showing the kinematics of payment via office

Implementation

If your webshop is not a 3-D Secure one, please get in touch with the Worldline Sips technical support to activate the service.

To implement a 3-D Secure card payment, you must implement the messages received and sent by the "E-commerce server" entity in the above chart.

Step 1: collecting payment data

You collect the cardholder's card data (card number, validity date, security code). You must comply with the PCI DSS recommendations.

Step 2: checking the selected card enrollment

You use the 3-D Secure enrollment of the card using the cardCheckEnrollment function.

Setting the payment request

In a 3-D Secure context, apart from the mandatory method data, here are the request's data you should pay attention to.

Field name	Population rule
amount	Payment amount. The amount is displayed on the holder authentication page.
captureDay	Must be 6 or less. If the value is greater than 6, the Worldline Sips server forces it to 6.
cardCSCValue	Value retrieved in the previous step.
cardExpiryDate	Value retrieved in the previous step.
cardNumber	Value retrieved in the previous step.
merchantName	Shop name of your website that will be displayed on the authentication page of the holder's bank. If not filled in, the name of your shop specified when your shop was registered on Worldline Sips will be displayed.
merchantReturnUrl	Do not populate, this field is deprecated.
merchantUrl	URL of your website that will be displayed on the authentication page of the holder's bank. If not filled in, the URL of your shop specified when your shop when registered on Worldline Sips will be displayed.
orderChannel	For payments made through the Internet, please set to INTERNET
panType	PAN if you use the standard Office connector CSE if you use the Office connector in CSE mode
paymentMeanBrand	For co-branded cards (CB+VISA or CB+MASTERCARD), the indicated value determines the choice of the DS in a 3-D Secure v2 process. For example, for a CB+VISA co-branded card: if you set to CB, the Worldline Sips server will query the CB DS if you set to VISA, the Worldline Sips server will query the VISA DS.
`fraudData.challengeMode3DS`	In a 3-D Secure context V2, if you want ask an exemption please refer to to corresponding chapter If a card addition is planned in a wallet, then this field must be valued to «CHALLENGE_MANDATE»

Analysing the response

Status	Field name	What to do
Card is 3-D Secure enrolled.	`responseCode` = 00 `redirectionStatusCode` = 00	You must redirect the cardholder to their bank's ACS via the URL indicated in the `redirectionUrl` field (see next step).
Card is not 3-D Secure enrolled.	`responseCode` = 00 `redirectionStatusCode` = 01	Proceed to step 5: authorisation request. The data redirectionData contains all the information for the authorisation request even if the card is not enrolled.
Technical error preventing the 3-D Secure process from running smoothly.	`redirectionStatusCode` = 10, 80, 89, 99	Proceed to step 5: authorisation request.
Webshop is not enrolled in the 3-D Secure programme.	`responseCode` = 40 `redirectionStatusCode` = 40	Please contact Worldline's technical support.
Transaction is not valid.	`responseCode` = 00 `redirectionStatusCode` = 12	One or more data in the request is not correct. Check the `errorFieldName` field and fix the incorrect value.
Card is not valid.	`redirectionStatusCode` = 14	The details of the means of payment are not correct, go back to step 1 and ask the cardholder to enter their payment information again.
Secret key or key version is not valid	`responseCode` = 34 `redirectionStatusCode` = 34	Check the secret key used (field `secretKey`) and the key version (field `keyVersion`)
Worldline Sips server temporarily unavailable	`responseCode` = 99	You can submit the request a second time. If the error persists, notify Worldline Technical Support.

Step 3: redirecting the customer to their bank's ACS

If the card is enrolled, you must redirect the customer to their bank's ACS URL that was retrieved in the previous step, in the RedirectionUrl. field. In the case of passive authentication, you must also perform this step, even if the client will not really be redirected to their bank's ACS.

Please refer to the POST form to the ACS section in the Sips Office JSON documentation to know how to implement this message.

Step 4: retrieving customer's authentication data

At the end of the authentication process, the customer is redirected to your website using an HTTP redirection. The authentication result is retrieved through the PARes field.

Please refer to the POST form to the ACS section in the Sips Office JSON documentation to know how to implement this message.

If the customer cancels the authentication process (closes their browser and is never redirected to your website), do not submit the authorisation request, do not ship the order.

Step 5: 3-D Secure authorisation request

Upon the customer's return to your e-commerce website after they have been authenticated (including for passive authentication), submit the 3-D Secure authorisation request via the cardValidateAuthenticationAndOrder method.

If the authentication of the client is failed,Worldline Sips does not send an authorisation request to your acquirer, the payment is necessarily refused.

Setting the request

In a 3-D Secure context, apart from the mandatory method data, here are the request's data you should pay attention to.

Field name	Population rule
`redirectionData`	Contains the payment transaction data. Please populate this field using the `redirectionData` field received as a response to the `cardCheckEnrollment` function.
`transactionReference` or `s10TransactionReference`	Must be identical to the `transactionReference` or `s10TransactionReference` field submitted when calling the `cardCheckEnrollment` function.
`paResMessage`	If you have redirected the cardholder to their bank's ACS, because their card is enrolled: please populate this field using the data from the PARes field, previously URL encoded, received from the ACS. If you have not redirected the cardholder to their bank's ACS, because their card is not enrolled, do not populate this field.
`messageVersion`	Please populate this field using the `messageVersion` received as a response to the `cardCheckEnrollment` function

Analysing the response

When you receive the answer, before analysing it and following the advice in the table below, check the seal. The recalculated seal must be identical to the received seal.

The information below is for authentication only. For payment information, please refer to the Sips Office connectors documentation.

Status	Field name
Authenticated holder	Cf. Analysing the response. `holderAuthentResponseCode` = 00
The cardholder was not able to authenticate themselves, or has cancelled on the ACS page, payment is univetably refused.	Cf. Analysing the response. `holderAuthentResponseCode` = 01
Technical issue tht prevented the successful completion of the 3-D Secure authentication.	Cf. Analysing the response. `holderAuthentResponseCode` = 02
`paResMessage` not correct. This case may occur: if the PARES message you submit is not strictly identical to the PARES received from the ACS (message is truncated for example) if the carrier modified the PARES message on purpose before coming back to your site. This may amount to a fraud attempt. In that case, stop the purchasing process.	`holderAuthentResponseCode` = 95 `guaranteeIndicator` = N `holderAuthentProgram` = 3DS `holderAuthentMethod` = NOT_SPECIFIED `holderAuthentRelegationCode` = N `holderAuthentStatus` = FAILURE
3D session expired. This case may occur if you submit the `cardValidateAuthenticationAndOrder` request more than 15 minutes after the `cardCheckEnrollment` request was processed.	`holderAuthentResponseCode` = 89 `guaranteeIndicator` = N `holderAuthentProgram` = 3DS `holderAuthentMethod` = NOT_SPECIFIED `holderAuthentRelegationCode` = N `holderAuthentStatus` = ERROR
Secret key or key version is not valid	`responseCode` = 34
Operation already performed on this transaction.	`responseCode` = 24

Payment from a token

In this section, we do not outline the card processing phase into a token, we assume the customer has already made a first payment and you have stored the token corresponding to their card number, as well as the card validity date.

Flows description

A 3-D Secure payment from a token is made in 4 steps:

retrieving the token and collecting the card secure code
checking the customer's card enrollment
redirecting the customer to their bank's ACS
the 3-D Secure authorisation request

image too complex to be described, please contact the support

Implementation

If your webshop is not a 3-D Secure one, please get in touch with the Worldline Sips technical support to activate the service.

To implement a 3-D Secure token payment, you must implement the messages received and sent by the "e-commerce server" entity in the above chart.

Step 1: authenticating your customer, retrieving their card token and collecting their secure code

You authenticate your customer to find the token and the validity date of their card, token and validity date that you previously stored when your customer made his first payment.

On an kinematic using a card token, you are not obliged to ask your customer's card security code in case of a strong authentication. The following step "Step 2: checking the selected card enrollment" details how to make sure that the selected card is eligible for strong authentication. We assume that your acquirer supports this feature (feel free to contact the support teams for more information).

Note: Payments processed without strong authentication and without CSC will end with a refusal status and an associated responseCode = 12. It's up to you to retry the payment with asking beforehand the customer his card security code

For all other payment means, and the payments not processed into a 3D secure context, you must collect the customer's card security code.

Step 2: checking the selected card enrollment

You check the 3-D Secure enrollment of the card with the use of the cardCheckEnrollment function.

Setting the request

In a 3-D Secure context, apart from the mandatory method data, here are the request's data you should pay attention to.

Field name	Population rule
amount	Payment amount. The amount is displayed on the holder authentication page.
captureDay	Must be 6 or less. If the value is greater than 6, the Worldline Sips server forces it to 6.
cardCSCValue	Value retrieved in the previous step, entered by the customer.
cardExpiryDate	Value retrieved in the previous step, stored in your information system beforehand.
cardNumber	Card token.
merchantName	Shop name of your website that will be displayed on the authentication page of the holder's bank. If not filled in, the name of your shop specified when your shop was registered on Worldline Sips will be displayed.
merchantReturnUrl	Do not populate, this field is deprecated.
merchantUrl	URL of your website that will be displayed on the authentication page of the holder's bank. If not filled in, the URL of your shop specified when your shop when registered on Worldline Sips will be displayed.
orderChannel	For payments made through the Internet, please set to INTERNET.
panType	TOKEN_PAN
paymentMeanBrand	For co-branded cards (CB+VISA or CB+MASTERCARD), the value indicated determines which DS is chosen. For example, for a CB+VISA co-branded card: if you set to CB, the Worldline Sips server will query the CB DS if you set to VISA, the Worldline Sips server will query the VISA DS

Analysing the response

When you receive the response, before analyzing it and following the advice in the table below, check the seal. The recalculated seal must be identical to the seal received.

Use case	Response fields	What to do
Card is 3-D Secure enrolled.	`responseCode` = 00 `redirectionStatusCode` = 00	You must redirect the customer to their bank's ACS via the URL indicated in the `redirectionUrl` field (see next step).
Card is not 3-D Secure enrolled.	`responseCode` = 00 `redirectionStatusCode` = 01	Proceed to step 5: authorisation request. The data redirectionData contains all the information for the authorisation request even if the card is not enrolled.
Webshop is not enrolled in the 3-D Secure programme.	`responseCode` = 40 `redirectionStatusCode` = 40	Please contact Worldline's technical support.
Technical error preventing the 3-D Secure process from running smoothly.	`redirectionStatusCode` = 10, 80, 89	Proceed to step 5: authorisation request.
Transaction is not valid.	`responseCode` = 12 `redirectionStatusCode` = 12	One or more data in the query is not correct. Check the `errorFieldName`, field and fix the wrong value.
Token is unknown.	`responseCode` = 14 `redirectionStatusCode` = 12	Check the `cardNumber` field.
Card has expired.	`redirectionStatusCode` = 14	Ask again to your customer to select another means of payment or to enter a new means of payment.
Secret key or key version is not valid	`responseCode` = 34 `redirectionStatusCode` = 34	Check the secret key used (field `secretKey`) and the key version (field `keyVersion`)
Detokenisation is down	`redirectionStatusCode` = 99 `responseCode` = 99	This is possibly a one-time issue, please submit the request again. In the event of a further error, please stop the process. Then tell Worldline's technical support about the incident.

Step 3: redirecting the customer to their bank's ACS

Please refer to the same step of the Sips Office connector section.

Step 4: retrieving customer authentication data

Please refer to the same step of the Sips Office connector section.

Step 5: 3-D Secure authorisation request

Please refer to the very same step of the Sips Office connector section.

Sips In-App connector

Payment from a card number

Flow description

A 3-D Secure payment is a 3-step process:

checking the 3-D Secure enrollment of the customer's card
redirecting the customer to their bank's ACS
sending the 3-D Secure authorisation request

Implementation

If your shop does not have 3-D Secure authentication, please contact the Worldline Sips technical support to activate the service.

In order to accept a 3-D Secure card payment, you have to implement the messages received and transmitted by the entities named "E-Commerce Server" and "Mobile App" in the diagram above.

Step 1: payment initialisation

You can initialise the payment using the orderInitialize method.

Setting the request

In a 3-D Secure context, apart from the mandatory method data, here are the request's data you should pay attention to.

Field name	Sample field population
`amount`	Amount of payment. The amount is displayed on the customer authentication page.
`captureDay`	Must be less than or equal to 6. If the value is larger than 6, the Worldline Sips server forces it to 6.
`sdkOperationName`	THREEDSECUREANDORDER

Analysing the response

Use case	Response fields	Action to take
Successful initialisation of the payment	`redirectionStatusCode` = 00	You display the payment data collection screen in your mobile application. You transmit the data necessary for the payment to be processed to the mobile application: `redirectionData` `redirectionUrl`
Invalid initialisation request	`redirectionStatusCode` = 12, 30	One or more data in the request are not correct. Check the `redirectionStatusMessage` field and fix the incorrect value.
Worldline Sips server temporarily unavailable	`redirectionStatusCode` = 99	Resubmit the request. If the issue lasts, please alert Worldline's technical support.
Duplicated transaction	`redirectionStatusCode` = 94	The `transactionReference` or the `transactionId` is already used by another request from your shop. Resubmit the request with another transaction reference.

Step 2: collecting payment data

You can collect the cardholder's card data (card number, validity date, security code) via your mobile application.

Step 3: checking the card enrollment

You can check the 3-D Secure enrollment of the card using the SDK cardCheckEnrollment function.

Setting the request

In a 3-D Secure context, besides the mandatory method data, here are the request data you need to pay attention to.

Field name	Sample field population
`cardCSCValue`	Value retrieved in the previous step.
`cardExpiryDate`	Value retrieved in the previous step.
`cardNumber`	Value retrieved in the previous step.
`paymentMeanBrand`	For co-branded cards (CB+VISA or CB+MASTERCARD), the indicated value determines the choice of the DS in a 3-D Secure v2 process. For example, for a CB+VISA co-branded card: if you set to CB, the Worldline Sips server will query the CB DS. if you set to VISA, the Worldline Sips server will query the VISA DS.

Analysing the response

Use case	Response fields	What to do
Card is 3-D Secure enrolled.	`redirectionStatusCode` = 00	You must redirect the holder to their bank's ACS via the URL indicated in the `redirectionUrl` field (see next step).
Card is not 3-D Secure enrolled.	`redirectionStatusCode` = 01	Proceed to step 6: authorisation request.
Technical error preventing the 3-D Secure process from running smoothly.	`redirectionStatusCode` = 10, 80, 89, 99	Proceed to step 6: authorisation request.
Webshop is not enrolled in the 3-D Secure programme.	`responseCode` = 40 `redirectionStatusCode` = 40	Please contact Worldline's technical support.
Transaction is not valid.	`redirectionStatusCode` = 12	One or more data in the request is not correct. Check the `errorFieldName` field and fix the incorrect value.
Card is not valid.	`redirectionStatusCode` = 14	The details of the means of payment are not correct, go back to step 1 and ask the cardholder to enter their payment information again.

Step 4: redirecting the customer to their bank's ACS

If the card is enrolled, you must redirect the customer to their bank's ACS URL that was retrieved in the previous step, in the authentRedirectionUrl field. In the case of passive authentication, you must also perform this step, even if the customer will not really be redirected to their bank's ACS.

Please refer to the paragraph relating to the redirection to the ACS of the Sips In-App documentation to know how to implement this message.

Step 5: retrieving customer authentication data

At the end of the authentication process, the customer is redirected to your application using an HTTP redirection. The authentication result is retrieved through the PARes field.

Please refer to the paragraph back from the ACS of the Sips Office JSON documentation to know how to implement this message.

If the customer cancels the authentication process (closes their browser and is never redirected to your website), do not submit the authorisation request, do not ship the order.

Step 6: 3-D Secure authorisation request

Upon the customer's return to your e-commerce website after they have been authenticated (including for passive authentication), submit the 3-D Secure authorisation request via the cardValidateAuthenticationAndOrder method.

If the authentication of the customer has failed,Worldline Sips does not send an authorisation request to your acquirer, the payment is necessarily refused.

Setting the payment request

In a 3-D Secure context, besides the mandatory method data, here are the request data you need to pay attention to.

Field name	Population rule
`paResMessage`	If you have redirected the cardholder to their bank's ACS, because their card is enrolled: please populate this field using the data from the `paResMessage` field, previously URL encoded, received from the ACS. If you have not redirected the cardholder to their bank's ACS, because their card is not enrolled, do not populate this field.

Analysing the response

Please refer to the Sips In-App documentation.

Strong authentication exemptions

Frictionless authentication description

The 3DSv2 protocol allows passive customer authentication, when the risk of fraud is low enough. This authentication type is also known as ‘frictionless’ authentication. When making a ‘frictionless’ payment, the transaction is authenticated indeed, but the customer is not solicited. In a frictionless case, an authentication cryptogram is provided by the issuer and transmitted in the authorisation request. The DSP2 differentiates between several exemption cases:

Exemptions for small amounts (<€30)
Exemptions following an acquirer transaction risk analysis (acquirer TRA)
Exemptions following an issuer transaction risk analysis (issuer TRA)
Exemptions in the context of a payment to a trusted recipient
Exemptions on the use of unnamed cards (cards granted to legal entities)

Frictionless payment operates in 2 ways:

Merchant frictionless authentication, which you explicitely ask for in the payment request, using the fraudData.challengeMode3DS field. Even if you ask for frictionless authentication, the final decision on whether or not to grant this frictionless authentication remains with the card issuer. It is worth noting that in the case of the issuer granting frictionless authentication, you loose the payment guarantee and assume the risk of chargeback (the card issuer does not assume this risk any longer). If the issuer doesn't grant frictionless authentication, they assume the risk of chargeback.
Issuer frictionless authentication decided by the card issuer depending on the transaction context data you populated in the request. Even if the issuer grants frictionless authentication, you keep the payment guarantee, which means the card issuer is the one assuming the risk of chargeback.

Exemptions implementation

Acquirer TRA Exemption

You can request an exemption if your risk analysis shows that the risk of fraud is low enough to request a frictionless authentication. This case of derogation is called the Transaction Risk Analysis (TRA) acquirer. To take advantage of this functionality, you must request authorization from your acquirer, who will tell you how to use this exemption (maximum amount, rules to be applied in the event of changes over time, etc.), and ask your usual contact to activate the "TRA acquirer" option.

Setting the request

Field	Value setting
`fraudData.challengeMode3DS`	NO_CHALLENGE_TRA_ACQ

Analysing the response

Use case Response fields Action to take

Exemption request granted by issuer, the client is passively authenticated

Use case	Response fields	Action to take
Exemption request granted by issuer, the client is passively authenticated	`holderAuthentType` = FRICTIONLESS `holderAuthentStatus` = SUCCESS or ATTEMPT `authentExemptionReasonList`= refer to Data Dictionary
Exemption request rejected by issuer, the client is strongly authenticated	`holderAuthentType` = CHALLENGE `holderAuthentStatus` = SUCCESS or ATTEMPT `authentExemptionReasonList` = not filed
Exemption request not authorized because right not allowed on Worldline Sips, the client is authenticated (in this case Worldline Sips force with a "basic" exemption request : `fraudData.challengeMode3DS` = NO_CHALLENGE)	see next chapter	Please contact Worldline Sips to add the right to use this feature

holderAuthentType = FRICTIONLESS

holderAuthentStatus = SUCCESS or ATTEMPT

authentExemptionReasonList= refer to Data Dictionary

Exemption request rejected by issuer, the client is strongly authenticated

holderAuthentType = CHALLENGE

holderAuthentStatus = SUCCESS or ATTEMPT

authentExemptionReasonList = not filed

Exemption request not authorized because right not allowed on Worldline Sips, the client is authenticated (in this case Worldline Sips force with a "basic" exemption request : fraudData.challengeMode3DS = NO_CHALLENGE) see next chapter Please contact Worldline Sips to add the right to use this feature

IMPORTANT:

The value of fraudData.challengeMode3DS field can be overloaded with the value NO_CHALLENGE if:

you have not requested authorization from your acquirer and therefore do not have the “acquirer TRA” option activated on your webshop
if the issuer is still in EMVCo 2.1.0 (instead of EMVCo 2.2) and that the transaction is processed on the Visa or Mastercard network

Exemption without cause

If you do not have the right to use the acquirer TRA exemption, you can also request a basic exemption.

Setting the request

Champ	Valorisation
`fraudData.challengeMode3DS`	NO_CHALLENGE

Analysing the response

Use case Response fields Action to take

Exemption request granted by the issuer, the client is passively authenticated

Use case	Response fields	Action to take
Exemption request granted by the issuer, the client is passively authenticated	`holderAuthentType` = FRICTIONLESS `holderAuthentStatus` = SUCCESS or ATTEMPT `AuthentExemptionReasonList` = refer to Data Dictionary
Exemption request rejected by issuer, the client is strongly authenticated	`holderAuthentType` = CHALLENGE `holderAuthentStatus` = SUCCESS or ATTEMPT `authentExemptionreasonList` = not filled

holderAuthentType = FRICTIONLESS

holderAuthentStatus = SUCCESS or ATTEMPT

AuthentExemptionReasonList = refer to Data Dictionary

Exemption request rejected by issuer, the client is strongly authenticated

holderAuthentType = CHALLENGE

holderAuthentStatus = SUCCESS or ATTEMPT

authentExemptionreasonList = not filled

Small amount exemption and issuer TRA exemption

Even if you do not explicitly request an exemption, the card issuer can grant an exemption in 2 other cases:

small amount payment, less than 30 €.
the risk analysis carried out by the issuer shows that the risk of fraud is sufficiently low

Setting the request

There is no specific data to send, however, in order to encourage obtaining an exemption, it is preferable to highlight the fields recommended by the scheme. Please refer to the next chapter.

Analysing the response

Use case Response fields Action to take

Exemption request granted by the issuer, the client is passively authenticated

Use case	Response fields	Action to take
Exemption request granted by the issuer, the client is passively authenticated	`holderAuthentType` = FRICTIONLESS `holderAuthentStatus` = SUCCESS or ATTEMPT `authentExemptionreasonList` = refer to Data Dictionary

holderAuthentType = FRICTIONLESS

holderAuthentStatus = SUCCESS or ATTEMPT

authentExemptionreasonList = refer to Data Dictionary

Fields to foster frictionless authentication

So as to foster frictionless authentication and consequently optimise your conversion rate, you must populate some request fields that are recommended by the CB, VISA and MASTERCARD schemes. These optional fields are submitted to the scheme's Directory Server and to the card issuer who decides whether or not to grant frictionless authentication.

This section lists the Worldline Sips connector fields which, in case they are populated, are submitted to the card scheme and to the issuer within the authentication request. This data, as defined by the EMVco standard, is used to fight fraud and to obtain frictionless authentication.

In the next table, the DS listed are only the ones that have explicitly given information about fields having an impact regarding frictionless authentication granting.

Among these fields we can identify:

R - Fields recommended by the scheme indicated: these fields have been identified by the scheme as major for the transaction scoring. The scheme recommends they be populated by the merchant if the information is available.
Rx - Fields recommended by the CB network and having major relevance for the DS CB scoring: these optional fields have been identified by the CB network as being very important for the scoring of the transaction. Thus the CB network recommends their supply by the merchant when the information is available. The order of importance is shown by the number behind the letter R. The most important fields are classified in R1 and so on.
O - Optional fields: these fields are strictly optional, the scheme did not make any recommendation on how they should be populated.
N - Fields not included: these fields are not submitted to the scheme.

Field name	CB	Visa	Mastercard
billingAddress.city	R1	R	R
billingAddress.country	R1	R	R
billingAddress.addressAdditional1	R1	R	R
billingAddress.addressAdditional2	R1	O	R
billingAddress.addressAdditional3	R1	O	R
billingAddress.zipcode	R1	R	R
billingAddress.state	R1	R	R
holderContact.lastName	R3	R	R
holderContact.email	R1	R	R
holderContact.phone	R3	R	R
holderContact.mobile	R1	R	R
holderContact.workPhone	R3	R	O
deliveryAddress.city	R1	R	R
deliveryAddress.country	R1	R	R
deliveryAddress.addressAdditional1	R1	R	R
deliveryAddress.addressAdditional2	R1	O	R
deliveryAddress.addressAdditional3	R1	O	R
deliveryAddress.zipcode	R1	R	R
deliveryAddress.state	R1	R	R
deliveryContact.email	R3	O	O
fraudData.addressDeliveryBillingMatchIndicator	R3	R	O
fraudData.nameDeliveryCustomerMatchIndicator	R3	O	O
fraudData.productAvailabilityIndicator	R2	O	O
fraudData.reorderProductIndicator	R3	O	O
fraudData.merchantCustomerAuthentMethod	R2	R	O
fraudData.merchantCustomerAuthentDateTime	O	R	O
fraudData.merchantCustomerAuthentData	O (futur use)	R (futur use)	O (futur use)
fraudData.challengeMode3DS	R1	R	O
fraudData.productAvailabilityDate	O	R	O
shoppingCartDetail.giftCardAmount	O	R	O
shoppingCartDetail.giftCardCurrencyCode	O	R	O
shoppingCartDetail.giftCardCount	O	R	O
fraudData.merchantAuthentScoreValue	O	N	N
customerAccountHistoric.customerAccountId	R2	R	O
customerAccountHistoric.numberOfPurchase180Days	O	O	O
customerAccountHistoric.numberOfTransactionYear	O	R	O
customerAccountHistoric.customerAccountCreationDate	R2	R	O
customerAccountHistoric.numberOfAttemptsAddCard24Hours	O	R	O
customerAccountHistoric.suspiciousActivityIndicator	O	R	O
customerAccountHistoric.numberOfTransaction24Hours	O	R	O
customerAccountHistoric.customerAccountChangeDate	O	R	O
customerAccountHistoric.passwordChangeDate	R3	R	O
customerAccountHistoric.addPaymentMeanDate	R2	R	O
deliveryData.deliveryAddressCreationDate	R3	R	O
deliveryData.electronicDeliveryIndicator	R2	R	O
deliveryData.estimatedDeliveryDelay	R2	R	O
deliveryData.deliveryMode	R1	R	O
shoppingCartDetail.shoppingCartTotalQuantity	R3	N	N

Direct to Authorize

Description

A merchant can request the processing of an authorization transaction with an exemption (SCA exemption type) without having to go through an authentication request from the cardholder: this is the "Direct To Authorization (DTA)".

By default, this option applies to Visa and Mastercard. You can change this setting by contacting your usual Worldline Sips contact.

2 reasons for exemption are supported by the DTA:

exemptions for low value (below 30 €)
exemptions following an acquirer risk analysis

Only the cases of one-off payment (ONE_SHOT) and 1st payment for an order delivered in several instalments (MULTIPLE_1) can use DTA.

The DTA is available on the Sips Paypage, Sips Office and Sips In-App connectors.

In case of a Soft Decline (A1) on Sips Paypage, we will automatically make a new payment attempt in 3-D Secure mode (retrySofDecline) according to the following rules:

If a NO_CHALLENGE_DTA exemption was requested, then a new 3-D Secure payment attempt using NO_CHALLENGE will be made
If an exemption of type NO_CHALLENGE_TRA_ACQ_DTA was requested, then a new payment attempt in 3-D Secure using NO_CHALLENGE_TRA_ACQ will be made if you have the TRA_ACQ option, otherwise a new payment attempt in 3-D Secure using NO_CHALLENGE will be made

In case of possible MITs made via the duplicate method, Worldline Sips will automatically chain these MITs with the CIT DTA..

Implementation

If your shop does not have 3-D Secure authentication, please contact the Worldline Sips technical support to activate the service.

In order to accept a 3-D Secure card payment, you have to implement the messages received and transmitted by the entities named "E-Commerce Server" and "Mobile App" in the diagram above.

Low value Exemption

You can apply for DTA with a low value exemption for payments of a small amount, less than 30 €. To take advantage of this functionality, you must ask your usual WL Sips contact to activate the "DTA" option.

Setting the request

Field	Value
`fraudData.challengeMode3DS`	NO_CHALLENGE_DTA

Analysing the response

Use case Response Fields Action to take

Transaction accepted

Use case	Response Fields	Action to take
Transaction accepted	`responseCode` = 00 `acquirerResponseCode` = 00 `holderAuthentStatus` = NO_AUTHENT_DTA
Transaction declined in SoftDecline (A1)	`responseCode` = 05 `acquirerResponseCode` = A1 `holderAuthentStatus` = NO_AUTHENT_DTA	If you use the Sips Office or Sips In-App connector, you can make a new payment attempt in 3-D Secure using NO_CHALLENGE

responseCode = 00

acquirerResponseCode = 00

holderAuthentStatus = NO_AUTHENT_DTA

Transaction declined in SoftDecline (A1)

responseCode = 05

acquirerResponseCode = A1

holderAuthentStatus = NO_AUTHENT_DTA

If you use the Sips Office or Sips In-App connector, you can make a new payment attempt in 3-D Secure using NO_CHALLENGE

Acquirer TRA Exemption

You can request DTA with an acquirer Transaction Risk Analysis (TRA) exemption if your risk analysis shows that the risk of fraud is sufficiently low. To take advantage of this functionality, you must ask for authorization from your acquirer, who will tell you how to use this exemption (maximum amount, rules to be applied in case of evolution over time, ...), and ask your usual WL Sips contact to activate the "Acquirer TRA" option and the "DTA" option

Setting the request

Field	Value
`fraudData.challengeMode3DS`	NO_CHALLENGE_TRA_ACQ_DTA

Analysing the response

Use case Response Fields Action to take

Transaction accepted

Use case	Response Fields	Action to take
Transaction accepted	`responseCode` = 00 `acquirerResponseCode` = 00 `holderAuthentStatus` = NO_AUTHENT_DTA
Transaction declined in SoftDecline (A1)	`responseCode` = 05 `acquirerResponseCode` = A1 `holderAuthentStatus` = NO_AUTHENT_DTA	If you use the Sips Office or Sips In-App connector, you can make a new payment attempt in 3-D Secure using NO_CHALLENGE_TRA_ACQ if you have the TRA_ACQ option, otherwise using NO_CHALLENGE

responseCode = 00

acquirerResponseCode = 00

holderAuthentStatus = NO_AUTHENT_DTA

Transaction declined in SoftDecline (A1)

responseCode = 05

acquirerResponseCode = A1

holderAuthentStatus = NO_AUTHENT_DTA

If you use the Sips Office or Sips In-App connector, you can make a new payment attempt in 3-D Secure using NO_CHALLENGE_TRA_ACQ if you have the TRA_ACQ option, otherwise using NO_CHALLENGE

Customer authentication uncoupled from payment (also called Authentication-only)

This paragraph describes how to implement 3-D Secure use cases requiring the authentication flow to be uncoupled from the payment flow.

Authentication processed by Worldline Sips and payment processed by another PSP

Flows description

Implementation

If your webshop is not a 3-D Secure one, please get in touch with the Worldline Sips technical support to activate the service.

To implement a 3-D Secure card payment in "authentication-only" mode, you must implement the messages received and sent by the "e-commerce server" entity in the above chart.

Step 1: collecting payment data

You collect the customer's card data (card number, validity date, security code). You must comply with the PCI DSS recommendations.

Step 2: checking the card enrollment via Worldline Sips

Setting the payment request

In a 3-D Secure context, apart from the mandatory method data, here is the request data you should pay attention to.

Field name	Population rule
cardCSCValue	Value retrieved in the previous step.
cardExpiryDate	Value retrieved in the previous step.
cardNumber	Value retrieved in the previous step.
merchantName	Shop name of your website that will be displayed on the authentication page of the customer's bank. If not filled in, the name of your shop specified when your shop was registered on Worldline Sips will be displayed.
merchantReturnUrl	Do not populate, this field is deprecated.
merchantUrl	URL of your website that will be displayed on the authentication page of the customer's bank. If not filled in, the URL of your shop specified when your shop was registered on Worldline Sips will be displayed.
panType	Please set to PAN.
paymentMeanBrand	For co-branded cards (CB+VISA or CB+MASTERCARD), the value indicated determines which DS is chosen. For example, for a CB+VISA co-branded card: if you set to CB, the Worldline Sips server will query the CB DS. if you set to VISA, the Worldline Sips server will query the VISA DS.

Analysing the response

Please refer to the Analysing the response part of the Sips Office connector section.

Step 3: redirecting the customer to their bank's ACS

Please refer to the same step of the Sips Office connector section.

Step 4: retrieving customer authentication data

Please refer to the same step of the Sips Office connector section.

Step 5: checking the authentication result

Please refer to the same step of the "Enrolling a card without making a payment" section.

Step 6: authorisation request to the other PSP

The 3-D Secure data are included in the response of the cardValidateAuthentication function called in the previous step:

If authentication was carried out using 3-D Secure v1, please refer to the authenticationResult.threeD container.
If authentication was carried out using 3-D Secure v2, please refer to the authenticationResult.threeDV2 container.

Authentication processed by another PSP and payment processed by Worldline Sips

Flows description

Specific aspects of this integration mode

When using this integration mode, Worldline Sips does not process cardholder authentication and therefore, cannot decide if 3-D Secure Liability Shift is applicable. Field guaranteeIndicator will be empty regardless of the authentication and authorization results.

When processing the authorization, Worldline Sips considers that you checked authentication result and that you wish to proceed further with the payment. Specific rules (such as 3D_ERROR automatic refusal, refusal of transaction without liability shift) that could be enabled on Worldline Sips to block payments depending on authentication result are ignored on this integration mode.

Implementation

To implement a 3-D Secure card payment in "authentication-only" mode, you must implement the messages received and sent by the "E-commerce server" entity in the above chart.

Step 1: collecting payment data

You collect the customer's card data (card number, validity date, security code). You must comply with the PCI DSS recommendations.

Step 2: authentication request to another PSP

Step 3: 3-D Secure authorisation request to Worldline Sips

When the customer is back on your e-commerce website following their authentication, forward the 3-D Secure authorisation request using the cardOrder function.

Setting the payment request

In a 3-D Secure context, apart from the mandatory method data, here is the request data you should pay attention to.

Field name	Population rule
`authenticationResult.holderAuthentProvider`	Must be set to 2 (other PSP)
`amount`	Amount to authorize.
`captureDay`	Must be 6 or less. If the value is greater than 6, the Worldline Sips server forces it to 6.
`cardCSCValue`	Filled in using the value retrieved in step 1. Must necessarily be filled in in the context of a 3-D Secure payment.
`cardExpiryDate`	Filled in using the value retrieved in step 1.
`cardNumber`	Filled in using the value retrieved in step 1.
`orderChannel`	For payments made through the Internet, please set to INTERNET.
`paymentPattern`	ONE_SHOT or RECURRING_1
`panType`	PAN if you use the standard Sips Office connector. CSE if you use the Sips Office connector in CSE mode.
`paymentMeanBrand`	Filled in using the value retrieved in step 1.
If authentication was carried out with 3-D Secure v1.
`authenticationResult.threeD.cavv`	To be populated with value of protocol field "cavv" received in step 2.
`authenticationResult.threeD.cavvAlgorithm`	To be populated with value of protocol field "cavvAlgorithm" received in step 2.
`authenticationResult.threeD.eci`	To be populated with value of protocol field "eci" received in step 2.
`authenticationResult.threeD.txStatus`	To be populated with value of protocol field "status" received in step 2. Specific case for cards not enrolled to 3-D Secure 1.0 : in this case only, value can be set to "9" (card not enrolled).
`authenticationResult.threeD.xid`	To be populated with value of protocol field "xid" received in step 2.
If authentication was carried out with 3-D Secure v2.
`authenticationResult.threeDV2.cavv`	To be populated with value of protocol field "authenticationValue" received in step 2.
`authenticationResult.threeDV2.cavvAlgorithm`	To be populated with value of message extension "CB-AVALGO" received in step 2 (required only when authentication was processed using FAST'R by CB).
`authenticationResult.threeDV2.eci`	To be populated with value of protocol field "eci" received in step 2.
`authenticationResult.threeDV2.txStatus`	To be populated with value of protocol field "transStatus" received in step 2.
`authenticationResult.threeDV2.authentTransStatusReason`	To be populated with value of protocol field "transStatusReason" received in step 2.
`authenticationResult.threeDV2.authentAcsTransId`	To be populated with value of protocol field "acsTransID" received in step 2.
`authenticationResult.threeDV2.authentDsTransId`	To be populated with value of protocol field "dsTransID" received in step 2.
`authenticationResult.threeDV2.authentThreedsServerTransId`	To be populated with value of protocol field "threeDSServerTransID" received in step 2.
`authenticationResult.threeDV2.authentAmount`	To be populated with value of protocol field "purchaseAmount" set by PAT in charge of processing the authentication at step 2.
`authenticationResult.threeDV2.authentDateTime`	To be populated with value of protocol field "purchaseDate" set by PAT in charge of processing the authentication at step 2.
`authenticationResult.threeDV2.holderAuthentType`	To be set accordingly to the authentication mode during step 2 (Challenge or Frictionless).
`authenticationResult.threeDV2.authentScoreValue`	To be populated with value of message extension "CB-SCORE" received in step 2 (required only when authentication was processed using FAST'R by CB).
`authenticationResult.threeDV2.challengeMode3DS`	To be populated depending on procotol field "threeDSRequestorChallengeInd" (merchant requested challenge mode) set by PAT in charge of processing the authentication at step 2.
`authenticationResult.threeDV2.authentCancelReason`	To be populated with value of protocol field "challengeCancel" received in step 2.
`authenticationResult.threeDV2.authentDSMerchantName`	To be populated with your commercial name. It should be the same that was used during authentication at step 2 (only required for CB payments).
`authenticationResult.threeDV2.authentExemptionReasonList`	To be populated with respective value received in step 2 (only required if authentication mode is frictionless).
`authenticationResult.threeDV2.authentMessageVersion`	To be populated with the version of the EMV 3-D Secure protocol used in step 2 (example 2.1.0).
`authenticationResult.threeDV2.authentACSMethod`	To be populated with value of protocol field "authenticationMethod" received in step 2.

Analysing the response

Use case	Response fields
Payment is accepted	`responseCode` = 00 `acquirerResponseCode` = 00 `guaranteeIndicator` Not provided. `authentRelegationCode` Set to Y if issuer rejects liability shift, N otherwise.
Secret key or key version is not valid	`responseCode` = 34
Payment is declined	`responseCode` <> 00 `acquirerResponseCode` <> 00

Enrolling a card without making a payment

Flows description

Checking a card using the 3-D Secure process prior to this card being enrolled in the Worldline Sips wallet is a 4-step process:

checking the card enrollment
redirecting the customer to their bank's ACS to authenticate them
checking the 3-D Secure authentication
enrolling the card in the wallet if the authentication has suscceded

Implementation

If your webshop is not a 3-D Secure one, please get in touch with the Worldline Sips technical support to activate the service.

To implement a card 3-D Secure checking prior to the card being enrolled in a wallet, you must implement the messages received and sent by the "E-commerce server" entity in the above chart.

Step 1: collecting payment data

Please refer to the same step of the Sips Office connector section.

Step 2: checking the selected card enrollment

You check the 3-D Secure enrollment of the card with the use of the cardCheckEnrollment function.

Setting the request

In a 3-D Secure context, apart from the mandatory method data, here is the request data you should pay attention to.

Field name	Population rule
amount	Since there is no payment, you can set to 0.
cardCSCValue	Value retrieved in the previous step.
cardExpiryDate	Value retrieved in the previsous step.
cardNumber	Value retrieved in the previous step.
merchantName	Shop name of your website that will be displayed on the authentication page of the customer's bank. If not filled in, the name of your shop specified when your shop was registered on Worldline Sips will be displayed.
merchantReturnUrl	Do not populate, this field is deprecated.
merchantUrl	URL of your website that will be displayed on the authentication page of the customer's bank. If not filled in, the URL of your shop specified when your shop was registered on Worldline Sips will be displayed.
panType	Please set to PAN.
challengeMode3DS	Value the field with CHALLENGE_MANDATE (default value for payment methods CB, VISA, MC, AMEX).
paymentMeanBrand	For co-branded cards (CB+VISA or CB+MASTERCARD), the value indicated determines which DS is chosen. For example, for a CB+VISA co-branded card: if you set to CB, the Worldline Sips server will query the CB DS. if you set to VISA, the Worldline Sips server will query the VISA DS.

Analysing the response

Please refer to the Analysing the response part of the Sips Office connector section.

Step 3: redirecting the customer to their bank's ACS

Please refer to the same step of the Sips Office connector section.

Step 4: retrieving customer authentication data

Please refer to the same step of the Sips Office connector section.

Step 5: checking the authentication result

When the customer is back on your e-commerce website following their authentication, check their authentication result using the cardValidateAuthentication function.

Setting the request

In a 3-D Secure context, apart from the mandatory method data, here is the request data you should pay attention to.

Field name	Population rule
redirectionData	Contains the payment transaction data. Please populate this field using the redirectionData field received as a response to the cardCheckEnrollment function.
transactionReference ou s10TransactionReference	Must be identical to the transactionReference or s10TransactionReference field submitted when calling the cardCheckEnrollment function.
paResMessage	If you have redirected the holder to their bank's ACS, because their card is enrolled: please populate this field using the data from the PARes field, previously URL encoded, received from the ACS. If you have not redirected the holder to their bank's ACS, because their card is not enrolled, do not populate this field.

Analysing the response

Please refer to the Analysing the response part of the Sips Office connector section.

Use case	Champs de la réponse
Authenticated holder	`responseCode` = 00 `holderAuthentResponseCode` = 00 `holderAuthentProgram` = connector version equal to or higher than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 process 3DS_V2: the holder authenticated themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process `holderAuthentMethod` = connector version equal to or higher than 2.24 if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: cf. Data dictionary. connector version lower than 2.24 NOT_SPECIFIED: whatever the process `holderAuthentStatus` = ATTEMPT or SUCCESS if process is 3-D Secure V2 `threeDv2.holderAuthentType` = cf. data dictionnary
The cardholder was not able to authenticate themselves, or has cancelled on the ACS page	`responseCode` = 00 `holderAuthentResponseCode` = 01 `holderAuthentProgram` = connector version equal to or higher than 2.24 3DS: the holder attempted to authenticate themselves using a 3-D Secure V1 process 3DS_V2: the holder attempted to authenticate themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process `holderAuthentMethod` = connector version equal to or higher than 2.24 if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: cf. Data dictionary. connector version lower than 2.24 NOT_SPECIFIED: whatever the process `holderAuthentStatus` = FAILURE if process is 3-D Secure V2 `threeDv2.holderAuthentType` = CHALLENGE
Technical issue that prevented the successful completion of the 3-D Secure authentication.	`responseCode` = 00 `holderAuthentResponseCode` = 02 `holderAuthentProgram` = connector version equal to or higher than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 process 3DS_V2: the holder authenticated themselves using a 3-D Secure V2 process connector version lower than 2.24 3DS: the holder authenticated themselves using a 3-D Secure V1 or 3-D Secure V2 process `holderAuthentMethod` = if process is 3-D Secure V1: NOT_SPECIFIED if process is 3-D Secure V2: NOT_SPECIFIED `holderAuthentStatus` = ERROR if process is 3-D Secure V2 `threeDv2.holderAuthentType` = CHALLENGE
`paResMessage` not correct. This case may occur: if the PARES message you submit is not strictly identical to the PARES received from the ACS (message is truncated for example) if the carrier modified the PARES message on purpose before coming back to your site. This may amount to a fraud attempt. In that case, stop the purchasing process.	`holderAuthentResponseCode` = 95 `holderAuthentProgram` = 3DS `holderAuthentMethod` = NOT_SPECIFIED `holderAuthentStatus` = FAILURE
3D session expired. This case may occur if you submit the `cardValidateAuthenticationAndOrder` request more than 15 minutes after the `cardCheckEnrollment` request was processed.	`holderAuthentResponseCode` = 89 `holderAuthentProgram` = 3DS `holderAuthentMethod` = NOT_SPECIFIED `holderAuthentStatus` = ERROR
Secret key or key version is not valid	`responseCode` = 34
Usage of the `cardValidateAuhtentication` not allowed on this webshop Contact the technical support	`responseCode` = 40

Step 6: adding the card to the wallet

If the customer is indeed authenticated, you can enroll their card in their wallet with the use of the addCard function. Please refer to the Sips Office documentation to know the implementation details for this function.

Summary of 3-D Secure decision rules

General 3-D Secure rules

In the following 3 cases:

Technical problem
Ineligible card BIN (BIN missing from DS Pres message)
Card not enrolled 3DSv2 (in DS's Ares message)

Worldline Sips continues with a CB2A 160 2019 Authorisation Request with unavailability flag with the following fields :

Field 59 type 0407 = 09 (VAD)
Field 56 type 0033 = Byte1 bit '5' set «technical unavailability to implement authentication»

The fields concerned are valued as follows:

image trop complexe pour être décrite, merci de prendre contact avec le support

Worldline Sips additional rules

Depending on the additional options you have subscribed to, Worldline Sips applies the following rules:

Liability shift's calculation for CIT

For card payments (CB, Visa, Mastercard) via French acquirers, Worldline Sips calculates the guarantee transfer indicator and populates the guaranteeIndicator field as described below:

Liability shift's calculation for MIT

For card payments (CB, Visa, Mastercard) via French acquirers, Worldline Sips calculates the guarantee transfer indicator and populates the guaranteeIndicator field as described below:

Starting 3-D Secure in 4 steps

Step 1 - implementing the service

Depending on your use case, please follow the integration recommendations described in one of the previous chapters.

Step 2 - testing the service on the test environment

Once you have completed the Worldline Sips connectors implementation, you can perform tests to validate your Worldline Sips integration.

Sips Paypage connector

Test data
merchantId	201000076690001
Secret key	p64ifeYBVIaRcjaWoahCiw9L8wokNLqG2_YOj_POD4g
Key version	1
Test cards	Cf. the "Test cards" page

Server	test URL
Paypage POST	https://payment-webinit.test.sips-services.com/paymentInit
Paypage JSON	https://payment-webinit.test.sips-services.com/rs-services/v2/paymentInit
Paypage SOAP	https://payment-webinit.test.sips-services.com/services/v2/paymentInit

Sips Office connector

Test data
merchantId	201040040170001
Secret key	rxSP61eeP_oNi5TxCD7Ngy9YcwC8MLw6OlmFGGcsY54
Key version	1
Test cards	Cf. the "Test cards" page

Server	test URL
Office	https://office-server.test.sips-services.com

Simulation ACS

During your tests and depending on the card used, you are redirected to our 3-D Secure v1 ACS simulator or our 3-D Secure v2 ACS simulator.

On the 3-D Secure v1 ACS simulation pages, you can simulate:

a successful authentication (holderAuthentStatus = SUCCESS)
a failed authentication (holderAuthentStatus = FAILURE)
a technical error during the authentication phase (holderAuthentStatus = ERROR)
a case where the holder did not have to authenticate themselves (holderAuthentStatus = ATTEMPT)

On the 3-D Secure v2 ACS simulation pages, you can simulate:

a successful authentication (holderAuthentStatus = SUCCESS)
a failed authentication (holderAuthentStatus = FAILURE)
a technical error during the authentication phase (holderAuthentStatus = ERROR)
a case where the holder did not have to authenticate themselves (holderAuthentStatus = ATTEMPT)

Step 3 - subscribing to the production service

If your webshop has not yet been registered with the 3-D Secure service, you must make a request to your usual contact, indicating the means of payment the 3-D Secure service should be activated for (CB/VISA/MASTERCARD and/or AMEX).

Step 4 – starting and validating the production service

The 3-D Secure service activation is now up and running in production.

To make sure there is no regression, check the evolution of your conversion rate. The conversion rate is expected to decrease slightly, but if you notice a significant reduction in your conversion rate, quickly notify your usual contact so that they can diagnose the issue with you.