WL SIPS DOCS

Release 24.6

go directly to content

Search by keywords

3-D Secure

To search in the page use Ctrl+F on your keyboard

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.

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:

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.

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

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

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.

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.

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.
Note: Worldline Sips allows you to specify a different amount than the one to authorise, through the use of the authenticationData.authentAmount field.

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:

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.

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)

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


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

  1. You redirect the customer to Sips Paypage by transmitting the transaction data (amount, currency, etc.) in the request.
  2. Worldline Sips displays the payment page, the customer enters the card number, the security code and then validates.
  3. Worldline Sips performs the 3-D Secure check.
  4. Worldline Sips sends an authorisation request to the acquirer.
  5. Worldline Sips saves the transaction into the back office.
  6. Worldline Sips displays the payment receipt page.
  7. Worldline Sips returns the manual and automatic responses that contain transaction details including the result of the 3-D Secure authentication.
  8. 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.

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

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.

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_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 V2 process
holderAuthentMethod =
  • connector version equal to or higher than 2.24 = cf. Data dictionary.
  • connector version lower than 2.24 = NOT_SPECIFIED
holderAuthentRelegationCode = N
holderAuthentStatus = ATTEMPT or SUCCESS
holderAuthentType = cf. Data dictionary.
Card not enrolled guaranteeIndicator = cf. Data dictionary
holderAuthentProgram = NO_AUTHENT
holderAuthentMethod =
  • connector version equal to or higher than 2.24 = NO_AUTHENT
  • connector version lower than 2.24 = NOT_SPECIFIED
holderAuthentRelegationCode = N
holderAuthentStatus = NOT_ENROLLED
holderAuthentType = 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_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 V2 process
holderAuthentMethod =
  • connector version equal to or higher than 2.24 = cf. Data dictionary.
  • connector version lower than 2.24 = NOT_SPECIFIED
holderAuthentRelegationCode = N
holderAuthentStatus = FAILURE
holderAuthentType = 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_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 V2 process
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
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

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

1) You collect the card information on your payment page hosted on your website and transmit this information to Worldline Sips via the cardCheckEnrollment method. 2) Worldline Sips sends you the url of the ACS. 3) You redirect your customer to the ACS. 4) Your customer authenticates and is redirected to your site. 5) You collect the authentication information and send an authorisation request to Worldline Sips via the cardValidateAuthenticationAndOrder method. 6) Worldline Sips sends you the payment response and you display the payment result to your customer on your site.

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.

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

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

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»

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.

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.

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.

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.

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

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

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.

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

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.

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.

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

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

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.

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

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

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

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

image too complex to be described, please contact the support

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.

You can initialise the payment using the orderInitialize method.

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

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

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

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

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.

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.

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.

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.

Please refer to the Sips In-App documentation.

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:

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

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

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

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

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

holderAuthentType = FRICTIONLESS

holderAuthentStatus = SUCCESS or ATTEMPT

authentExemptionreasonList = refer to Data Dictionary

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

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.

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

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

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

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

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


image too complex to be described, please contact the support

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.

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

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.

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

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

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

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

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.


image too complex to be described, please contact the support

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.

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.

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

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

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

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

image too complex to be described, please contact the support

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.

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

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

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.

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

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

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

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

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.

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_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 V2 process
holderAuthentMethod =
  • connector version equal to or higher than 2.24 = cf. Data dictionary.
  • connector version lower than 2.24 = NOT_SPECIFIED
holderAuthentStatus = ATTEMPT or SUCCESS
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_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 V2 process
holderAuthentMethod =
  • connector version equal to or higher than 2.24 = cf. Data dictionary.
  • connector version lower than 2.24 = NOT_SPECIFIED
holderAuthentStatus = FAILURE
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_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 V2 process
holderAuthentMethod = NOT_SPECIFIED
holderAuthentStatus = ERROR
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

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.


image too complex to be described, please contact the support

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

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


image too complex to be described, please contact the support

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


image too complex to be described, please contact the support

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


image too complex to be described, please contact the support

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

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

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

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)

3DSv2 ACS simulation page

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

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.

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration