10 minute read
September 1, 2023

3D Secure in Europe

3D Secure

3D Secure (3DS) adds a layer of security, prior to authorization, to help authenticate online transactions by requiring customers to complete an additional verification with the card issuer. The merchant initiates 3DS at checkout, and the cardholder must complete the authentication step (for example, via biometric authentication on their smartphone).

There are two versions of 3DS:

  • 3D Secure 1 (3DS 1) – A challenge-all and one-time passcode (OTP) solution. This version has been largely deprecated and is now only used in some parts of the world.

  • 3D Secure 2 (3DS 2) – Provides an improved cardholder experience and is updated for payments made using smartphones.

Marqeta supports both 3D Secure 1 and 3D Secure 2 for Visa. With 3DS 2, Marqeta provides several services for advanced authentication. 3DS 2 introduces frictionless authentication, which minimizes the inconveniences cardholders might experience when making a card purchase, while also reducing fraud and providing added security to online transactions.

For more information, see About 3D Secure.

3D Secure network setup

During your network setup, you are required to provide the network with relevant URLs so that they can connect to Marqeta to perform 3DS authentication where possible. Both versions of 3DS should be configured to fully support all merchants.

  • 3DS 1

    • Visa – https://acs-visa-api.marqeta.com/v3/threeDSecure/v102/verifyenrollment

    • Mastercard – Not supported by Marqeta

  • 3DS 2 (2.1 and 2.2)

    • Visa – https://acs-visa-v2-api.marqeta.com/v3/threeDSecure/v220

    • Mastercard – https://acs-mc-v2-api.marqeta.com/v3/threeDSecure/v220

3D Secure configurations

The available 3DS option combinations are outlined below.

  • Automated Decisioning (recommended for customers in Europe)

    • Marqeta makes the decision whether to challenge based on static rules.

    • No-code option fully handled by Marqeta.

  • Advanced Authentication (recommended for customers in Europe)

    • Cardholder authentication is delegated via API request to customer to authenticate and return verification result.

    • Low-code option decisioning.

  • Default OTP

    • Marqeta handles verification using data configured via API.

    • No-code option fully handled by Marqeta.

  • Delegated Decisioning

    • Customer uses own risk logic to determine whether challenge is required or transaction is applicable to be frictionless.

    • High-code option with full flexibility and control over 3DS attempts.

For more information, see Available configurations.

For some use cases, such as those for Buy Now, Pay Later (BNPL) applications, challenge-all configuration may result in challenging cards that are not enrolled for one-time passcode (OTP) or biometrics decisioning. In these cases, implement delegated decisioning at your gateway to prevent unnecessary declines. To do this, perform the decisioning at your gateway to identify the risk for the user and transaction, and if the risk is low, exempt the transaction at the gateway.

Automated decisioning

Marqeta’s 3DS solution provides an optional automated decisioning service that enables you to configure and implement a 3DS authentication decision-making policy without having to build or host your own. Based on our rules, the system decides whether to apply a challenge to an incoming transaction authentication request or to exempt it.

Automated decisioning allows you to take advantage of the various exemptions that are allowed as part of the Payments Services Directive 2 (PSD2), automatically determining whether a transaction qualifies for an exemption or not, to maximize the frictionless experience for your customers. Under this option, you also get access to an API to download authentication and transaction data to satisfy necessary monitoring, reporting, and audit requirements.

Automated decisioning rules

Marqeta’s automated decisioning service makes up one part of managing and challenging your cardholders to perform strong customer authentication (SCA). It comes configured with the following rule set based around PSD2 and SCA guidelines within the EU region.

  • Article 14 – Exempt Recurring Payments – Payment service providers can decide whether to request SCA based on the following conditions:

    • 1.1. Shall request SCA when a cardholder creates, amends, or initiates a recurring transaction of the same amount/payee for the first time.

    • 1.2. Shall be allowed to exempt SCA for subsequent payment transactions, including a recurring transaction featuring the same amount/payee.

  • Article 16 – Exempt Low Value Transactions – Payment service providers shall be allowed to exempt SCA during e-commerce payments, provided the following conditions are met:

    • 2.1. The amount of the payment does not exceed €30.

    • 2.2. The cumulative amount of payments since the last SCA does not exceed €100.

    • 2.3. The number of previous payments since the last SCA does not exceed 5.

  • SCA is not required for any transaction where the following conditions are met:

    • 3.1. Data share only.

    • 3.2. SCA already performed.

    • 3.3. Acquirer transaction risk analysis (TRA).

    • 3.4. Merchant-initiated transaction (MIT).

Advanced authentication

Marqeta’s advanced authentication introduces enhanced device authentication, such as in-app login or biometrics (for example, fingerprint and face recognition), allowing you to assess which verification method is required for your cardholder. The details of advanced authentication are outlined below.

  • Marqeta configures URL, username, and password (eight-character minimum), which act as the gateway to receive the authentication request and response within three seconds.

    • HTTP 200 response to confirm authentication.

    • Time allowed for authentication is shown within max_response_time (in minutes).

  • Upon 200 response cardholder authentication, the screen prompts the cardholder awaiting the authentication result to be returned to Marqeta.

    • Your company logo can replace the Marqeta logo.

  • Verification results should be returned to Marqeta on an asynchronous URL within the timeframe sent in the initial request.

    • https://authentication-acs.marqeta.com/v3/three-ds/authentication-result

  • For browsers and devices that support JavaScript, auto-submit functionality immediately submits the request upon return of the API response.

    • Auto-submit is hidden for JavaScript-enabled applications.

For details about managing SCA, see E-commerce low value payments.

Unsecured e-commerce

It is the merchant’s decision whether they wish to trigger 3DS before a transaction event is processed. In some instances, merchants decide either not to request 3DS or to proceed with the transaction despite 3DS failing. Therefore, there is a need to monitor for unsecured e-commerce transactions and apply SCA when required.

Merchants can submit authorizations without authentication within PSD2 rules (set via card product) if they meet the following conditions:

  • The amount of the remote electronic payment transaction does not exceed €30;

  • The cumulative amount of previous remote electronic payment transactions initiated by the payer since the last application of SCA does not exceed €100;

  • The number of previous remote electronic payment transactions initiated by the payer since the last application of SCA does not exceed five consecutive electronic payment transactions.

SCA is not required on transactions that meet the following specified criteria:

  • A mobile wallet payment (for example, Apple Pay and Google Wallet) is considered to be SCA secured.

  • The transaction has been through 3DS, and the cardholder has provided verification.

  • The acquirer_exemption field is present, stating that SCA is not required or cannot be completed.

The electronic_commerce_indicator field provides confirmation of the security applied to e-commerce transactions:

  • authentication_successful – Indicates 3DS was completed successfully.

  • authentication_attempted – Indicates 3DS was attempted but was not successful.

  • no_authentication – Indicates the transaction contains no authentication.


Is this helpful?


Is this helpful?


Cardholder authentication data

Visa’s Cardholder Authentication Verification Value (CAVV) and Mastercard’s accountholder authentication value (AAV) use the universal cardholder authentication field (UCAF) field within authorization messages. These tokens are generated by Marqeta’s access control server (ACS) and provide evidence of successful cardholder authentication or attempted authentication by the merchant.

Cardholder authentication data is a network-provided service that offers further insight into the authentication of a transaction. These elements include:

  • A 3DS message version indicating the version (1.0, 2.1, or 2.2).

  • The status of the authentication (successful or failed).

  • The method of which the transaction was secured (for example, biometrics or one-time password).

  • Matching verification_result and verification_value_created_by fields.

Alternative 3D Secure solutions

Default one-time passcode

This is the default authentication option if you do not want to use your own authentication mechanism. This option does not require an integration with Marqeta’s access control server (ACS) but does require some configuration. Marqeta’s default authentication option uses a one-time passcode (OTP) generated and delivered by Marqeta to the cardholder via an on-file phone number or email address.

Default OTP options include:

  • Challenge-all with default OTP.

    • Challenges every attempt using default OTP and fully handled by Marqeta.

    • Not fully compliant in all regions with the requirement to conduct further SCA.

  • Delegate decisioning with default OTP.

  • Marqeta automated decisioning with default OTP.

Default OTP can be configured with the following combinations:

  • SMS OTP (primary), Email OTP (secondary).

  • Knowledge-based questions (KBA) Only.

  • SMS OTP (primary), Email OTP (secondary) plus KBA.

    • Meets SCA standards in most regions.

3DS correspondence

Marqeta issues correspondence to the cardholder directly, on the customer’s behalf. This is predefined text with dynamic value injection. The template for the subject and body text is described below.

  • Subject: $programName <noreply@marqeta.com>

  • Body: One-time PIN for the transaction of $purchaseAmount $purchaseCurrency at $merchantName using $programName card $lastFour is: $otp Expires in 10 minutes. Sincerely, $programName

The notification language can be configured to display text in different languages. It can be configured at the card product level and overridden by the cardholder level as needed. Language support includes French (fra), Spanish (spa), German (deu), Polish (pol), Czech (ces), Italian (ita), and Swedish (swe). The default language is English.

3DS personalization

3DS configuration can be personalized to configure the screens and correspondence to better suit your cardholders' language requirements and to show issuer logos. It can be configured only once, at the program level, and configuration characteristics are outlined below.

  • A name or logo can be chosen to appear on the one-time passcode (OTP) screen to present to cardholders.

    • Supported format is .png.

    • Maximum file dimensions are 47 pixels (height) x 140 pixels (width).

    • Maximum file size is 5 MB.

  • The program name can be displayed in customer notifications, such as email and SMS OTP.

  • The custom alphanumeric sender ID for SMS OTP can contain up to 11 characters from the following categories:

    • Upper-case letters A - Z.

    • Lower-case letters a - z.

    • Numbers 0 - 9.

    • Spaces.

      • Sender IDs must contain at least one letter. Special characters and punctuation are not allowed.

Knowledge-based questions

Knowledge-based questions can be used to authenticate the user, both solely and in conjunction with OTP, to provide enhanced SCA. The characteristics of knowledge-based questions are outlined below.

  • Cardholder metadata is used to configure questions and answers.

  • Three free-form questions and answers can be set per cardholder.

  • Marqeta displays one question at random and validates cardholder input with a stored answer.

  • Cardholder validates OTP first, followed by a random knowledge-based question.


Is this helpful?


Delegated decisioning

If you want to fully control 3DS authentication decision-making, as well as related monitoring, reporting, and audit requirements, you can choose the delegated decisioning option. This option provides complete control over 3DS decisioning and delegates all 3DS 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 3DS authentication decision-making to you. You then integrate with Marqeta’s systems and set up the required configurations for your program. Marqeta informs customers of decision results via the /three-ds/authentication endpoint to confirm the outcomes of the decisions they request.


Is this helpful?


Is this helpful?


3D Secure webhook notifications

The Marqeta platform supports webhook notifications for 3DS transition events.

3DS transition events include when a merchant requests 3DS authentication for a transaction (initialization) and when the Marqeta platform sends the merchant the outcome of the authentication request (completion).

For more details, see 3D Secure transition events.

3D Secure (3DS) responsibilities

If you have a card program in Europe, there are several responsibilities that you and Marqeta maintain. These responsibilities include:

Responsibility Powered By Managed By

Set up and maintain 3DS configuration with the network



Host and provide 3DS solutions for customers, and provide support with different combinations



Manage risk decisions and implement delegated decision rules to challenge cardholders, if applicable (Delegated Decisioning)



Manage automated decisions using predefined rules to challenge cardholders, if applicable (Automated Decisioning)



Authenticate cardholders via a chosen verification method, if applicable (Advanced Authentication)



Authenticate cardholders via a chosen verification method, if applicable



Subscribe to our developer newsletter