3D Secure

Advanced Optionsanchor

PSD2 Strong Customer Authentication (SCA) exemptionsanchor

Merchants can request an exemption from the SCA requirement for certain transactions. Exemptions are granted completely at the discretion of the issuer, and are never guaranteed. If an exemption is requested, and then granted by the issuer, authentication will not be required. However, in this case, the liability remains with the merchant and is not shifted to the issuer.

Please note that issuers are currently upgrading their systems to support 3D Secure 2 as well as PSD2 SCA exemptions; many issuers may not support some or all exemptions at this time.

For more information on exemptions, please read our blog on PSD2 SCA exemptions.

Requesting an exemption during Transaction.saleanchor

If you do not perform a 3D Secure authentication, but wish to request a SCA exemption on your transaction, you can do so by supplying the scaExemption field via the Transaction.sale() call.

Requesting an exemption during 3D Secureanchor

To request a specific SCA exemption when performing a 3D Secure authentication, use the requestedExemptionType option in the verifyCard() call. The requested exemption will be applied only if the exemptions conditions are met. If the exemption applies, we will request that no challenges be issued during 3D Secure authentication. In this case no exemption information is required in the Transaction.sale() call.

To request a Low Value exemption, set requestedExemptionType to "low_value" To request a Transaction Risk Analysis exemption, set requestedExemptionType to "transaction_risk_analysis"

If the exemptions conditions have not been met, then a standard 3D Secure authentication will be attempted.

Using your own 3D Secure MPI provideranchor

If you perform a 3D Secure authentication with your own MPI provider and receive an SCA exemption from the issuer via 3D Secure, you'll need to specify which exemption was obtained in the Transaction.sale() call.

Specifying exemptions using your own 3D Secure MPI provider is in limited release. Contact us to request access to the release of this feature.

Using Data-Only 3D Secureanchor

A data-only 3D Secure call is a new variant of 3D Secure 2. Data-only 3D Secure is entirely friction-less, but no liability shift is granted. This version of 3D Secure 2 is a way to leverage the additional data elements of 3D Secure 2 to seek an improvement in authorization rates from issuing banks, without increasing the risk to issuers on a given transaction via the fraud liability shift. Presently, Data-Only 3D Secure is only supported on Mastercard (the Mastercard protocol name is "Identity Check Insights"), and in select regions/processors. To find out if your merchant account supports data-only, please look at the Merchant Account section in the control panel and then confirm that the 3D Secure Data-Only Card Types section is present and the relevant card brand logo is displayed.

To use data-only 3D Secure calls, add the dataOnlyRequested boolean to your verifyCard() call. If the card brand and merchant account support data-only, then you should receive a response with the dataOnlySuccessful status in the onLookupComplete() callback. If the card brand does not support data-only, a standard 2.0 lookup will occur. However, if your merchant account does not support data-only, you will receive a 915126 validation error.

Visa Digital Authentication Frameworkanchor

Visa Digital Authentication Framework (DAF) is a feature that allows an authentication payment credential to be established using an issuer step up. With this payment credential all subsequent transactions for the same payment instrument on the same merchant should be frictionless (with a full liability shift). A payment credential is valid for up to 2 years.

If the transaction is subject to PSD2, then Visa DAF has to be used together with an acquirer TRA exemption. For the other regions which support Visa DAF no exemption is required. The regions that currently support Visa DAF are North America (cross border only, not domestic), Latin America/Caribbean, Europe, Asia Pacific (except Japan/India/Bangladesh), Central Europe/Middle East/Africa (except Russia).

Visa DAF is requested by adding requestVisaDAF to your verifyCard() call. To confirm your eligibility to use Visa DAF please contact your acquiring bank.

Authentication Insightanchor

Authentication Insight provides you with more details about the regulatory environment and applicable customer authentication regulation for a potential transaction. This empowers you to make an informed decision whether to perform 3D Secure authentication.

You can use the regulation environment information contained in the Authentication Insight to make a decision about whether to perform a 3D Secure verification, or continue without a verification. If you choose to perform a 3D Secure verification, proceed as usual using the payment method nonce.

The regulation environment field currently has three possible values:

Regulation Environment Description
psd2 The impending transaction (when using the provided payment method nonce and merchant account) is believed to be within scope of PSD2 SCA regulations, and requires 3D Secure authentication.
unregulated The impending transaction is not believed to be within scope of any SCA regulations, PSD2 or otherwise.
unavailable The impending transaction's SCA regulation environment could not be determined.

As global regulations evolve, these values will continue to be updated.

To request Authentication Insight, include authenticationInsight.merchantAccountId in the options object you pass to Hosted Fields:

  1. Callback
  2. Promise
  authenticationInsight: {
    merchantAccountId: 'merchant-account-id'
}, function (tokenizeErr, payload) {
  if (tokenizeErr) {
    // Handle error
  } else {
    // access regulation environment
    var regulationEnvironment = payload.authenticationInsight.regulationEnvironment);

To request Authentication Insight for a vaulted payment method, use the Server SDKs.

Vaulting with CVV verifications and 3DSanchor

If you are using the Drop-In UI to tokenize cards, you have CVV rules enabled and you run 3D Secure verifications, the default setting to vault cards on your client will result in a processor error.

Instead, you should disable vaulting via the Drop-In UI and vault the card on your server. You can do so by setting vaultCard to false when initializing the Drop-In UI and include the vault_on_success=true parameter when creating a transaction using transaction:sale or a GraphQL mutation from your server.

  1. Callback
  2. Promise
      authorization: 'CLIENT_AUTHORIZATION',
      container: '#dropin-container',
      threeDSecure: true,
      card: {
        vault: {
          vaultCard: false
  }, function (err, dropinInstance) {
    // Finish Drop-in setup


Currently, we have test cards available that can return the various regulation environment values when authentication insight is requested on tokenization, depending on the merchant account that is specified:

Test Value Card Information Regulation Environment Value
4012000033330620 country of issuance = "USA" unregulated
4023490000000008 country of issuance = "IRL"
  • psd2 if using a merchant account acquired in the European Economic Area (EEA)
  • unregulated if using a merchant account acquired outside the EEA
  • unavailable if using a merchant account where acquirer country is unknown or has not been specified