logo Mercanet

Release 24.2

go directly to content

Search by keywords

3-D Secure

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

  • Mercanet

Mercanet 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 Mercanet 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 (with 3-D Secure V1, the authenticated amount was set to the first instalment only).
  • payment to set up a subscription must be authenticated with an amount equals to the average recurring payments.
Note: WL Sips allows you to specify a different amount than the one to authorise, through the use of the authenticationData.authentAmount field.

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 Mercanet with the 3-D Secure option activated by default.

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

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

Mercanet sends back a manual response and a standard automatic paypage response.

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

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

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 Mercanet via the cardCheckEnrollment method. 2) Mercanet 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 Mercanet via the cardValidateAuthenticationAndOrder method. 6) Mercanet 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 Mercanet 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 Mercanet 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 Mercanet 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 Mercanet 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 Mercanet server will query the CB DS
  • if you set to VISA, the Mercanet 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 BNP Paribas'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)
Mercanet server temporarily unavailable responseCode = 99 You can submit the request a second time. If the error persists, notify BNP Paribas 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 Office (M2M) 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 Office (M2M) 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,Mercanet 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 Office (M2M) 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

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 Mercanet 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 Mercanet 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.
Mercanet server temporarily unavailable redirectionStatusCode = 99 Resubmit the request. If the issue lasts, please alert BNP Paribas'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 Mercanet server will query the CB DS.
  • if you set to VISA, the Mercanet 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 BNP Paribas'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 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 Office (M2M) 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,Mercanet 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 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 Mercanet, the client is authenticated (in this case Mercanet force with a "basic" exemption request : fraudData.challengeMode3DS = NO_CHALLENGE) see next chapter Please contact Mercanet 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 Mercanet 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 Paypage, Office (M2M) and In-App connectors.

In case of a Soft Decline (A1) on 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, Mercanet will automatically chain these MITs with the CIT DTA..

If your shop does not have 3-D Secure authentication, please contact the Mercanet 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 Office (M2M) or 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 Office (M2M) or 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

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)

Mercanet 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, Mercanet applies the following rules:


image too complex to be described, please contact the support

For card payments (CB, Visa, Mastercard) via French acquirers, Mercanet 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, Mercanet 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 Mercanet connectors implementation, you can perform tests to validate your Mercanet 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-web-mercanet.test.sips-services.com/paymentInit
Paypage JSON https://payment-web-mercanet.test.sips-services.com/rs-services/v2/paymentInit
Paypage SOAP https://payment-web-mercanet.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-mercanet.test.sips-services.com/

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

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

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

3DSv1 ACS simulation page obsolete

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

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

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.