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.
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.
- payment to set up a subscription must be authenticated with an amount equals to the average recurring payments.
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
- 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
=
holderAuthentMethod
=
holderAuthentRelegationCode
= N holderAuthentStatus
= ATTEMPT or SUCCESS holderAuthentType
= cf. Data
dictionary. |
Card not enrolled | guaranteeIndicator = cf. Data
dictionary holderAuthentProgram
= NO_AUTHENT holderAuthentMethod
=
holderAuthentRelegationCode
= N holderAuthentStatus
= NOT_ENROLLED holderAuthentType
= NONE |
The cardholder was not able to authenticate themselves, payment is inevitably refused. | guaranteeIndicator
= N holderAuthentProgram
=
holderAuthentMethod
=
holderAuthentRelegationCode
= N holderAuthentStatus
= FAILURE holderAuthentType
= CHALLENGE |
Technical issue that prevented the successful completion of the 3-D Secure authentication. | guaranteeIndicator = cf. Data
dictionary holderAuthentProgram
=
holderAuthentMethod
= NOT_SPECIFIED holderAuthentRelegationCode
= N holderAuthentStatus
= ERROR holderAuthentType
= 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 |
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 |
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
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:
|
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. |
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. |
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 = 40redirectionStatusCode =
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. |
Secret key or key version is not valid |
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:
|
holderAuthentResponseCode
= 95guaranteeIndicator
= NholderAuthentProgram
= 3DSholderAuthentMethod
= NOT_SPECIFIED holderAuthentRelegationCode
= NholderAuthentStatus
= 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
= 89guaranteeIndicator
= NholderAuthentProgram
= 3DSholderAuthentMethod
= NOT_SPECIFIEDholderAuthentRelegationCode
= NholderAuthentStatus
= 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
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).
responseCode
= 12. It's up to you to
retry the payment with asking beforehand the customer his card security
codeFor 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:
|
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. |
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. |
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. |
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. |
redirectionStatusCode =
12 |
One or more data in the query is not correct. Check the
errorFieldName , field and fix
the wrong value. |
Token is unknown. |
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 |
redirectionStatusCode =
34 |
Check the secret key used (field secretKey ) and the key
version (field keyVersion ) |
Detokenisation is down | redirectionStatusCode =
99responseCode =
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:
|
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:
|
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 = 40redirectionStatusCode =
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 |
|
|
Exemption request rejected by issuer, the client is strongly authenticated |
|
|
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 |
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 |
|
|
Exemption request rejected by issuer, the client is strongly authenticated |
|
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 |
|
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 |
|
|
Transaction declined in SoftDecline (A1) |
|
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 |
|
|
Transaction declined in SoftDecline (A1) |
|
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:
|
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. 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. |
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 = 00acquirerResponseCode =
00guaranteeIndicator 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 <>
00acquirerResponseCode <>
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:
|
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
holderAuthentProgram
=
holderAuthentMethod =
holderAuthentStatus =
ATTEMPT or SUCCESSthreeDv2.holderAuthentType
= cf. data dictionnary |
The cardholder was not able to authenticate themselves, or has cancelled on the ACS page |
holderAuthentProgram =
holderAuthentMethod =
holderAuthentStatus =
FAILUREthreeDv2.holderAuthentType
= CHALLENGE |
Technical issue that prevented the successful completion of the 3-D Secure authentication. |
holderAuthentProgram =
holderAuthentMethod =
NOT_SPECIFIEDholderAuthentStatus =
ERRORthreeDv2.holderAuthentType
= CHALLENGE |
paResMessage not correct.
This case may occur:
|
holderAuthentResponseCode =
95holderAuthentProgram =
3DSholderAuthentMethod =
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 =
89holderAuthentProgram =
3DSholderAuthentMethod =
NOT_SPECIFIEDholderAuthentStatus =
ERROR |
Secret key or key version is not valid | responseCode = 34 |
Usage of the cardValidateAuhtentication
not allowed on this webshopContact 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:
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 v2 ACS simulator.
On the 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.