> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md). # EMV® 3-D Secure (EMV 3DS) Cardholder authentication for online payments – handled by the gateway, required by regulation, designed to stop fraud without stopping sales. EMV® 3-D Secure (EMV 3DS), commonly referred to as 3DS2, is the global authentication protocol for online card payments developed by EMVCo. It enables the card issuer to verify the cardholder’s identity before an online payment is authorized, by securely exchanging authentication and transaction data between the merchant, the card scheme, and the issuer. Customers may recognize the process under the card scheme brand names Visa Secure and Mastercard Identity Check. For merchants in Europe, EMV 3DS is more than a fraud tool: it is the standard mechanism for meeting Strong Customer Authentication (SCA) requirements under PSD2 for online card payments. The SEB Ecommerce Payment Gateway handles EMV 3DS as an integral part of card payment processing – the gateway initiates the authentication flow whenever it is necessary for the payment, so you do not need to decide when 3DS applies. ### Key Benefits * Reduces online payment fraud * Increases payment authorization rates by reducing false declines * Supports Strong Customer Authentication (SCA) requirements under PSD2 * Improves the customer checkout experience through frictionless authentication * Optimized for web, mobile, and in-app payments ### Capability Summary
CapabilitySupport
ProtocolEMV® 3-D Secure 2.x – version 2.2.0; version 2.3.1 supported as required by the card schemes
Scheme ProgramsVisa Secure, Mastercard Identity Check
Authentication FlowsFrictionless and challenge
InitiationBy the gateway, whenever authentication is necessary for the payment
SCA ExemptionsSupported in accordance with PSD2 and card scheme rules
Merchant-Initiated Transactions3DS Requestor-Initiated (3RI) authentication, where applicable
Authentication ExperienceRedirect-based flow; the challenge is presented by the customer’s issuer
Liability ShiftIn accordance with card scheme rules (see Liability Shift)
Integration EffortNone for Hosted Checkout; redirect handling for Merchant API integrations
Sandbox TestingSupported – 3DS authentication flows can be tested in the Sandbox environment
Availability of individual capabilities depends on your merchant agreement, enabled services, and acquiring configuration. ### How EMV 3DS Works When a card payment requires authentication, the following happens – largely invisibly to you and, in most cases, to the customer: 1. The gateway initiates authentication. During payment processing, the gateway determines that authentication is necessary – for example, because SCA applies to the transaction – and initiates the EMV 3DS flow. 2. Data is shared with the issuer. Rich transaction and device data is exchanged with the issuer through the card scheme’s 3-D Secure infrastructure. Compared to the legacy 3DS 1 protocol, EMV 3DS carries an order of magnitude more data points, allowing the issuer to assess risk accurately without disturbing the customer. 3. The issuer assesses the risk. Based on its risk assessment, the issuer decides whether to authenticate the customer silently (frictionless flow) or to require an additional verification step (challenge flow). 4. The customer authenticates if required. If a challenge is required, the customer completes it directly with their issuer – typically a confirmation in their mobile banking app, a one-time password, or biometric verification. The gateway manages the redirect-based authentication flow. 5. The payment proceeds to authorization. The authentication result is attached to the authorization request, and the issuer makes the final authorization decision. #### Frictionless and Challenge Flows
Frictionless FlowChallenge Flow
What happensThe issuer authenticates the transaction based on the exchanged data – no customer interactionThe customer completes an additional verification step with their issuer
Customer experienceNothing visible – checkout continues uninterruptedBanking app confirmation, one-time password (OTP), or biometric verification
When it appliesLower-risk transactions, applicable SCA exemptions, issuer’s risk-based decisionHigher-risk transactions, regulatory requirements, or the issuer’s policy
Industry estimates indicate that the large majority of EMV 3DS authentications complete through the frictionless flow – the customer never notices that authentication took place. The decision between the two flows always belongs to the issuer. ### SCA and Exemptions Under PSD2, Strong Customer Authentication is required for customer-initiated online card payments in Europe. In practice, this means an initial or one-click card payment may need to be authenticated with EMV 3DS before the issuer approves it. The gateway applies authentication in line with regulatory requirements and card scheme rules – including support for the applicable SCA exemptions, such as low-value transactions or Transaction Risk Analysis (TRA), where your acquiring configuration allows. Two important points about how this works in practice: * The issuer has the final word. Even when an exemption is applied, the issuer may still require authentication and decline the initial authorization attempt (a “soft decline”). In that case the payment proceeds through the 3DS flow – the gateway manages this; no action is required from you. * MITs are handled differently. Merchant-Initiated Transactions are processed without the customer being present; where applicable, they may use 3DS Requestor-Initiated (3RI) authentication. The SCA performed during the initial customer-initiated payment covers the setup of the stored credential. See Merchant-Initiated Transactions (MIT). ### Liability Shift Successful EMV 3DS authentication may shift the liability for fraud-related chargebacks from the merchant to the issuer, in accordance with card scheme rules. This is one of the most tangible commercial benefits of 3DS: for an authenticated transaction that later turns out to be fraudulent, the dispute is generally borne by the issuer rather than by you. Keep in mind that liability shift is governed and determined by the card schemes and issuers – it depends on the authentication outcome, the transaction type, and the applicable scheme rules, and it does not apply to all dispute reasons (for example, disputes about goods or services are unaffected). Authentication reduces fraud liability; it does not replace good order and delivery practices. ### EMV 3DS and Other Payment Methods * Digital wallets. Apple Pay, Google Pay, and Click to Pay typically perform strong customer authentication within the wallet flow, which means a separate 3DS step may not be required. Where 3DS processing applies – for example, for Google Pay payments with a card on file – the gateway handles it automatically. * Pay by Bank. Pay by Bank does not use 3DS at all: Strong Customer Authentication is performed by the customer’s bank within its own authentication flow. * Stored credentials. One-click card payments are customer-initiated and may require 3DS depending on exemptions and the issuer’s decision; recurring charges are merchant-initiated and use 3RI where applicable. ### What You Need EMV 3DS is part of card payment processing – there is no separate activation for it. #### If You Use Hosted Checkout Nothing. The gateway initiates authentication when necessary and presents the challenge flow through Hosted Checkout. #### If You Build Your Own Checkout (Merchant API) Strong Customer Authentication is performed through a redirect-based flow where required: your integration handles the redirect of the customer to the authentication step and their return to your checkout, as described in the integration guide. You do not implement any 3DS logic yourself – the gateway determines when authentication is necessary and manages the message exchange with the card scheme infrastructure. {% hint style="warning" %} Do not attempt to detect, skip, or suppress authentication in your integration. When the gateway initiates 3DS, it is because regulation, scheme rules, or the issuer requires it – bypassing it results in declined payments. {% endhint %} ### Merchant Best Practices * Treat authentication as part of the normal payment flow – keep orders pending until the final payment status is confirmed, including payments where the customer is completing a challenge. * Handle abandoned authentication gracefully: if the customer does not complete the challenge, let them retry or choose another payment method. * Provide accurate order and customer data in your payment requests – richer, more accurate data supports the issuer’s risk assessment and increases the share of frictionless authentications. * Do not fulfil orders based on the customer’s return to your website – rely on the confirmed payment status and callback notifications. * Inform customers that their bank may ask them to confirm the payment – for example, in their mobile banking app – so the challenge step does not come as a surprise. ### Testing The Sandbox environment supports testing of 3DS authentication flows. Before requesting Production activation, verify: * Successful payments with frictionless authentication. * Successful payments with a challenge flow, including the customer’s redirect and return. * Failed and abandoned authentication scenarios – the customer must be able to retry or choose another payment method, and no order may be fulfilled. * Correct order status handling based on callback notifications for all authentication outcomes. ### Frequently Asked Questions #### Does every card payment go through 3DS? No. The gateway initiates authentication when it is necessary – because SCA applies, scheme rules require it, or the issuer requests it. Exemptions and out-of-scope cases (such as merchant-initiated transactions) mean that many payments are processed without a 3DS step, and most authenticated payments complete frictionlessly. #### Do I need to implement 3DS myself? No. With Hosted Checkout, authentication is fully handled on the Hosted Checkout page. With the Merchant API, your integration handles the redirect-based authentication flow – the redirect out and the customer’s return – but the decision-making and the 3DS message exchange are managed by the gateway. #### Why was my customer asked to confirm the payment in their banking app? The issuer decided that a challenge was required – based on its risk assessment, regulatory requirements, or its own policy. This is normal and protects both the customer and you. The choice of challenge method (banking app, OTP, biometrics) belongs to the issuer. #### Does 3DS guarantee I will not receive chargebacks? No. Successful authentication may shift liability for fraud-related chargebacks to the issuer under card scheme rules, but disputes for other reasons – such as goods not received – are unaffected. Liability shift determination rests with the card schemes and issuers. #### Which 3DS version does the gateway support? EMV® 3-D Secure 2.x – currently version 2.2.0, with version 2.3.1 supported as it becomes required by the card schemes. Version upgrades are handled on the gateway side and do not require changes to your integration. #### Can I request that a specific payment skips or forces 3DS? Authentication is applied in line with regulation, card scheme rules, and the issuer’s requirements. Where SCA exemptions are applicable, they are handled through the gateway and your acquiring configuration – discuss the options with your SEB representative. ### Related Documentation Continue with the following topics: * [Cards](/payment-methods/cards.md) * [Strong Customer Authentication (SCA)](/compliance/strong-customer-authentication-sca.md) * [PSD2 (Second Payment Services Directive)](/compliance/psd2-second-payment-services-directive.md) * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) * [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) * [Testing](/payment-methods/cards/testing.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.