Skip to main content
The Three-Domain Secure (3D Secure) security protocol, created and branded by Visa and Mastercard as Visa Secure and Mastercard Identity Check respectively, further protects online payments by enabling cardholders to authenticate their purchases. The “3D” name refers to the three domains involved in providing this added security:
  • The acquirer domain (e.g., the merchant)
  • The issuer domain (e.g., Marqeta)
  • The interoperability domain (e.g., the card network)
At the end of this guide, you should understand:
  • What 3D Secure is and how it is used.
  • The 3D Secure process for authentication.
For more about using 3D Secure with Marqeta, contact your Marqeta representative. For reference information, see the 3D Secure API reference.

3D Secure authentication

3D Secure adds a layer of security, prior to authorization, to help authenticate online transactions by requiring cardholders to complete an additional verification step with the card issuer. For example, when the merchant initiates 3D Secure at checkout, the cardholder must then enter a one-time passcode (OTP) received via email or SMS to continue with their purchase.

About 3D Secure

Visa released the initial version of the 3D Secure protocol (3D Secure 1.0) in 1999 under the brand name “Verified by Visa” (now known as Visa Secure). In 2001, Mastercard implemented the 3D Secure 1 protocol under its own brand name, “Mastercard SecureCode” (now known as Mastercard Identity Check). 3D Secure 2 was released in 2016, and banks began to phase in support for 3D Secure 2 in 2019. 3D Secure 2 included several notable enhancements to the original 3D Secure 1 protocol, improving the cardholder experience and adding support for smartphone payments. 3D Secure 2 also introduced frictionless authentication, which minimizes the inconveniences cardholders can experience when making a card purchase, while also reducing the risk of fraud and providing added security to online transactions. Additionally, 3D Secure 2 improved the authentication flow by embedding the challenge within the checkout flow, without redirecting the cardholder to additional authentication pages. 3D Secure 2 enhanced security features without negatively impacting the cardholder experience.
Note
Currently, 3D Secure 2 is the only version of the 3D Secure protocol, as 3D Secure 1 was decommissioned in 2022. Throughout this document, the phrase “3D Secure” refers to 3D Secure 2, unless stated otherwise.

3D Secure and the SCA regulation in Europe

3D Secure is the primary method for meeting the increased security requirements for the strong customer authentication (SCA) regulation in Europe. The SCA regulation requires that transactions be authenticated using the 3D Secure protocol.

Liability shift

If an online payment is successfully authenticated via 3D Secure, the merchant is not liable for subsequent fraud-related chargebacks on that transaction. If a transaction is disputed by the cardholder as fraudulent, liability shifts from the merchant to the card issuer. However, if a cardholder disputes a transaction for a reason other than fraud, liability remains with the merchant. For these cases, you should have a plan for avoiding and managing disputes. There are rare cases when transactions authenticated by 3D Secure do not shift liability to the issuer; for example, if an account experiences excessive levels of fraud. Transactions that have been authenticated using 3D Secure cannot be disputed as fraudulent; however, the issuer may investigate a transaction by requesting additional information.

Exemptions

An exemption allows a transaction to take place without conforming to the SCA two-factor authentication requirement. You can take advantage of exemptions allowed under the Revised Payment Services Directive (PSD2). Transactions that qualify for an exemption enable a frictionless experience for cardholders while remaining vigilant for fraud risk. Exemptions may be granted in cases such as low-value transactions, low-risk transactions, those involving secure corporate payments, or those with merchants on the allow list. Be aware that exemptions present the following considerations:
  • You are responsible for any fraud-related chargebacks on exempt transactions.
  • You likely will not be able to dispute chargeback claims on exempt transactions.
The cardholder can likely claim full reimbursement from their payment service provider if there was no SCA measure in place and the cardholder did not act fraudulently. The key details of the SCA exemptions were defined in the Official Journal of the European Union on March 13, 2018 and in PSD2 Directive 2015/2366 of the European Parliament and of the Council of November 25, 2015.

3D Secure policies

The following 3D Secure policies are available:
  • Challenge All
  • Delegated Decisioning
  • Automated Decisioning

Challenge All

You can choose to apply strong customer authentication (SCA), also known as a challenge, for every 3D Secure authentication request by a requestor or merchant. This is the most regulation-compliant and the most risk-free option, but it is also the most restrictive. This option is best suited for cases where all 3D Secure authentication requests need to be challenged, and neither Delegated Decisioning nor Automated Decisioning is being used to make a decision.

Delegated Decisioning

If you want to fully control 3D Secure authentication decision-making as well as the related monitoring, reporting, and audit requirements, you can choose the Delegated Decisioning option. This option provides complete control over 3D Secure decisioning and delegates all 3D Secure decision-making to your systems. Delegated Decisioning allows you to exempt low-risk authentication requests using risk rules that are tailored to your system and regions of operation. This option requires you to implement the web interfaces that call Marqeta’s systems in order to delegate the 3D Secure authentication decision-making to you. You then integrate with Marqeta’s systems and set up the required configurations for your program. If your Delegated Decisioning endpoint is unavailable, Marqeta will request a challenge from the cardholder by default; however, you can also choose to configure the fallback as frictionless.

Automated Decisioning

Marqeta’s Automated Decisioning solution enables you to configure and implement a 3D Secure authentication decision-making policy without having to build or host your own. Automated Decisioning is the preferred configuration for programs that want to implement granular control without having to build and maintain a decisioning gateway. Based on the rules you set up using the Automated Decisioning service, the system decides whether to apply a challenge to an incoming transaction authentication request or to exempt it. Automated Decisioning permits you to take advantage of the various exemptions that are allowed as part of the PSD2. It automatically determines whether a transaction qualifies for an exemption or not, maximizing the frictionless experience for your customers while balancing that against the risk of fraud. The Marqeta Issuer Transaction Risk Analysis (TRA) feature gives you access to the 3D Secure Rules Engine dashboard, which allows you to write rules for 3D Secure challenges or Frictionless flows. Under this option, you also get access to a service reporting API for downloading authentication and transaction data, which you can use to satisfy the necessary monitoring, reporting, and audit requirements. For further details, refer to the PSD2 regulation.

Authentication

There are two options available for authenticating your cardholders when it has been determined that an SCA challenge is required:
  • Advanced Authentication
  • Marqeta’s default OTP
Both of these options are available, regardless of the 3D Secure policy that you choose; however, each option has unique integration and configuration requirements.

Advanced Authentication

Using this option, you can choose to implement your own customized method of cardholder authentication. This can be whatever method you choose and is managed by you. In-app and biometric authentication mechanisms to authenticate cardholders fall under this option. Advanced Authentication requires an integration with Marqeta’s access control server (ACS). The ACS can call your system to prompt you when you need to perform the authentication with your cardholder and send a notification from you to Marqeta with the authentication result.

Marqeta’s default OTP

If you do not want to use your own authentication mechanism, Marqeta has a default OTP authentication option that does not require an integration with Marqeta’s ACS, but does require some configuration. Marqeta’s default authentication option uses an OTP that is generated and delivered by Marqeta to the cardholder via an on-file phone number or email address.
Tip
Ensure that the cardholder has a valid SMS-enabled telephone number or email address on file. By default, OTPs are sent to the cardholder via SMS; if a telephone number is not available, the OTP is sent via email.

Authentication lifecycle

In the payments ecosystem, authorization occurs after the completion of 3D Secure authentication. The merchant uses the authentication data captured as part of the 3D Secure process to submit an authorization for approval. For more on authorization transactions, see About Transactions.

OTP authentication lifecycle

Authentication lifecycle for OTP
When a cardholder attempts to make an online payment to a merchant supporting OTP authentication, the following process occurs:
1
The merchant initiates an authentication request by sending the request to the card network.
2
The card network routes the authentication request to the Marqeta platform.
3
The Marqeta platform prompts the cardholder, via an iFrame exposed in the merchant’s checkout experience, to enter an OTP that Marqeta sends via SMS or email.
4
The Marqeta platform captures the authentication results.
5
If the authentication is successful, the Marqeta platform sends an authentication response to both the card network and the merchant; authentication is complete.

Advanced Authentication lifecycle

Authentication lifecycle for Advanced Authentication
When a cardholder attempts to make an online payment to a merchant supporting Advanced Authentication, the following process occurs:
1
The merchant initiates an authentication request by sending the request to the card network.
2
The card network routes the authentication request to the Marqeta platform.
3
Depending on your 3D Secure configuration, an SCA challenge requirement is determined for the request.
4
Depending on your 3D Secure configuration, Marqeta prompts the cardholder via an iFrame exposed in the merchant’s checkout experience, and then prompts you to perform authentication with the cardholder using your chosen method.
5
Marqeta sends a request for you to authenticate the cardholder using your /three-ds/authentication endpoint. You respond to Marqeta’s request with OK (200) within three seconds to authenticate the cardholder, and then return the verification result to Marqeta using the following asynchronous endpoint within the time frame sent in the initial request: https://authentication-acs.marqeta.com/v3/three-ds/authentication-result. The Marqeta platform captures the authentication result.
6
The Marqeta platform sends an authentication response to the card network; authentication is complete.
The following provides a detailed view of the Advanced Authentication process:
Authentication lifecycle for Advanced Authentication detail

Authentication results

On the Marqeta platform, the cardholder_authentication_data object, which may be embedded in the transaction object, stores the authentication data from 3D Secure. If the transaction is funded through the Just-in-Time (JIT) Funding mechanism, cardholder_authentication_data is contained in the jit_funding object. For a full description of the transaction data contained in the cardholder_authentication_data object, see Transaction Data for JIT Funding Decisions.

Monitoring, reporting, and audit liability

In order to claim any of the allowed SCA exemptions, the PSD2 regulation mandates certain monitoring, reporting, and auditing requirements. Marqeta does not own any liability or responsibility in regard to satisfying the requirements of monitoring, reporting, or audits under PSD2 or when any SCA exemptions are claimed. Marqeta is an issuer processor. For 3D Secure, the transaction authentication requests are limited to remote (i.e., card not present) e-commerce transactions only. The fraud rate and other reporting requirements, however, apply at the issuer level and across all payment transactions, i.e., both remote and non-remote. Marqeta cannot provide a holistic view of fraud rates and other data for the issuer bank, which may have many programs for which they have issued cards. It is your responsibility—or the responsibility of your issuer bank—to manage this, whether you are using your own systems to make 3D Secure SCA decisions or using the Automated Decisioning self-serve solution, which also depends on whether you or the issuing bank are the BIN sponsor, and also on the agreement between you and your bank.