3D Secure Compliance

3D Secure Compliance: How 3DS Supports Strong Customer Authentication

For ecommerce merchants, the most important thing to understand about 3D Secure compliance is that two different concepts are often collapsed into one.

Strong Customer Authentication (SCA) is a regulatory requirement.

3D Secure (3DS) is a technical card-authentication protocol that can help payment service providers meet that requirement.

Under the EU's PSD2 framework, payment service providers generally must apply SCA when a payer initiates an electronic payment transaction, subject to applicable exemptions and other scope rules. For remote electronic payments, the authentication must also support dynamic linking to the transaction amount and payee. The regulation deliberately remains technology-neutral; it does not say that every SCA-compliant card transaction must use one named authentication technology.

For ecommerce card payments, however, EMV 3-D Secure has become the principal protocol through which merchants, issuers, acquirers, and card networks exchange authentication information. EMVCo specifically describes EMV 3DS as enabling data exchange between merchants and issuers so the issuer can authenticate the consumer and assess card-not-present risk. It also states that EMV 3DS 2.x supports SCA use cases.

That distinction has direct operational consequences.

A merchant needs to understand not just whether SCA applies, but:

•whether the transaction should enter 3DS;

•whether an exemption is being requested;

•whether the issuer accepts a frictionless authentication;

•whether the issuer requests a challenge;

•what transaction and customer information should be passed;

•and how the authentication result is carried into authorization.

Those decisions can affect compliance, fraud exposure, authorization rates, checkout friction, and ultimately conversion.

What is 3D Secure?

3D Secure is an authentication protocol for card-not-present payments that allows information to be exchanged between a merchant and the cardholder's issuer so the issuer can assess whether the person making the purchase is the legitimate cardholder.

EMVCo maintains the modern EMV 3-D Secure specifications. The technology is used through card-network programs such as Visa Secure and Mastercard Identity Check, among others.

A 3DS authentication normally happens before the merchant submits the payment for final authorization.

The authentication layer answers a question broadly equivalent to:

“How confident is the issuer that this is the legitimate cardholder?”

Authorization answers a different question:

“Should this payment actually be approved?”

A transaction can therefore successfully authenticate through 3DS and still be declined during authorization—for example, because of insufficient funds, issuer risk policies, card restrictions, or another authorization decision.

3DS is not itself authorization.

It is also not PSD2.

It is the technical mechanism used to exchange authentication and risk information before authorization.

What is 3DS2?

3DS2 is the common industry shorthand for the second-generation EMV 3-D Secure protocol family.

Compared with legacy 3DS implementations, EMV 3DS 2.x was designed to support richer data exchange, browser and app-based commerce, risk-based authentication, more integrated challenge experiences, and modern authentication techniques.

EMVCo explains that the protocol can transmit information about:

•the transaction;

•the payment method;

•the customer's device;

•the customer;

•the customer's relationship with the merchant;

•previous activity relevant to authentication.

That additional context allows the issuer's Access Control Server, or ACS, to perform a more informed risk assessment.

“3DS2” should not be treated as one permanent version number.

EMVCo continues to develop the protocol. Its current materials reference the 2.2 and 2.3.1 specification families, while a draft 2.4 specification was published for industry comment in June 2026. Merchants should therefore verify which protocol versions their PSP, gateway, acquirer, card schemes, and target issuers actually support rather than assuming that “supports 3DS2” answers every compatibility question.

3D Secure versus Strong Customer Authentication

The cleanest way to understand 3DS compliance is to separate three layers.

Layer

What it is

Who defines it

Practical merchant question

Strong Customer Authentication

Regulatory authentication requirement

PSD2 / applicable national or regional regulation

Does this transaction require SCA or qualify for an exemption or other treatment?

EMV 3-D Secure

Technical authentication and messaging protocol

EMVCo

How will authentication data be exchanged with the issuer?

Card-network 3DS rules

Scheme-specific operating requirements

Visa, Mastercard and other networks

What authentication messages, indicators, programs, and transaction treatment does the card scheme require?

This separation prevents several common mistakes.

3DS is not the regulation

PSD2 and its Regulatory Technical Standards define the regulatory outcome.

For SCA, the authentication generally needs to rely on two or more independent elements from the categories of:

•knowledge — something the customer knows;

•possession — something the customer possesses;

•inherence — something the customer is.

For remote payments, additional dynamic-linking requirements apply.

The legislation does not mandate a named protocol such as 3DS.

3DS does not itself constitute an authentication factor

This distinction is subtle but important.

The EBA has expressly clarified that EMV 3DS is a communication protocol, not itself an inherence, knowledge, or possession factor. The compliant factors must come from the actual authentication method used through or alongside the protocol.

For example, an issuer might use:

•possession of a registered mobile device plus an OTP;

•a mobile banking application plus biometric authentication;

•another combination of independent compliant factors.

3DS provides the framework through which the interaction and authentication result can be exchanged.

Is 3D Secure required for SCA?

PSD2 does not explicitly require 3D Secure as the only way to perform SCA.

The regulatory framework is deliberately technology-neutral. The EBA has also recognized communication protocols such as EMV 3DS as a means through which merchants and issuers can support SCA.

But merchants should not stop the analysis there.

Card-network requirements can separately make EMV 3DS highly relevant or effectively required for particular ecommerce card transactions.

For example, Mastercard's current transaction-processing rules state that for covered remote electronic transactions in SCA countries, EMV 3DS/Identity Check authentication is required unless an applicable acquirer exemption, another compliant SCA method, delegated authentication arrangement, or other defined exception applies.

The practical answer is therefore:

SCA regulation does not mandate 3DS as the only technology, but merchants accepting ecommerce cards in SCA markets will normally need a payment stack capable of supporting EMV 3DS and the relevant scheme rules.

Merchants should confirm the position with their PSP or acquirer for each market and card network.

How a 3DS transaction works

A modern 3DS flow involves several participants.

The cardholder

The customer attempts to make the ecommerce purchase.

The merchant or 3DS Requestor

The merchant—or a PSP acting on its behalf—initiates the 3DS authentication request.

The 3DS Server

The server sends the authentication request into the 3DS ecosystem.

The Directory Server

The relevant card network's Directory Server routes the request toward the card issuer.

The issuer's Access Control Server

The ACS receives the authentication information and evaluates the transaction.

A simplified flow looks like this:

Customer checkout

→ Merchant / PSP

→ 3DS Server

→ Card-network Directory Server

→ Issuer ACS

→ Authentication decision

The ACS evaluates the data sent in the Authentication Request, commonly called the AReq.

It can then determine that:

No additional cardholder interaction is needed

→ frictionless flow

or:

Additional authentication is required

→ challenge flow.

EMVCo's current documentation confirms that the ACS reviews the AReq and can request a challenge when further checks are needed—for example because the transaction appears higher risk or authentication is required because of regulation or another mandate.

After authentication, the relevant authentication result is passed forward into the payment process.

The transaction must still go through authorization.

What is a frictionless 3DS flow?

A frictionless flow is a 3DS authentication in which the issuer does not require the customer to complete an interactive challenge.

The customer can effectively:

enter payment details → click Pay → continue

while the authentication decision happens in the background.

EMVCo explains that frictionless authentication is supported by a real-time issuer risk assessment using information such as transaction characteristics, customer history, merchant relationship, device information, and technical context.

That does not mean the issuer has ignored the transaction.

It means the issuer believes it has sufficient information to reach the appropriate authentication outcome without interrupting the shopper.

Frictionless does not automatically mean “SCA exemption”

Merchants should avoid equating:

frictionless = exempt

and:

challenge = SCA

Those are different concepts.

A frictionless experience may occur because of an exemption, an issuer decision, a compliant authentication method that does not require a visible challenge, or other applicable transaction treatment.

Similarly, seeing a challenge tells the merchant that additional authentication is occurring, but the regulatory classification still depends on the actual authentication method and transaction circumstances.

The merchant should rely on the returned authentication and exemption information from its PSP, acquirer, and 3DS implementation rather than inferring the legal treatment from what the checkout looked like.

What is a 3DS challenge flow?

A challenge flow occurs when the issuer determines that further interaction with the cardholder is required.

The customer might be asked to:

•enter a one-time password;

•authenticate through a mobile banking app;

•provide a biometric;

•use WebAuthn or another supported authentication method;

•complete another issuer-controlled verification step.

EMVCo's current 3DS guidance also supports out-of-band authentication, where the shopper confirms the transaction through a separate channel such as their banking application.

The important point for merchants is that the challenge itself is controlled by the issuer side of the 3DS ecosystem.

The merchant must make sure its checkout can display or hand off that challenge correctly.

Who decides whether the customer receives a challenge?

The issuer's ACS ultimately determines whether additional authentication is required.

The merchant or 3DS Requestor can express a preference using 3DS message fields.

For example, it can indicate:

•no preference;

•challenge preferred;

•challenge requested;

•no challenge requested;

•or certain reasons why no challenge is being requested.

But the request is not an instruction the issuer must always follow.

EMVCo's current technical guidance explains that the 3DS Server communicates an authentication preference and the ACS can respond by requiring a challenge.

That means a merchant cannot guarantee:

“This transaction will be frictionless.”

Nor should an ecommerce site promise customers that a valid SCA exemption means they can never be challenged.

The issuer can still determine that authentication is required.

Can 3DS be used when requesting an SCA exemption?

Yes.

One of the important capabilities of modern 3DS is that authentication messaging can also communicate information relevant to SCA exemptions.

The regulatory framework provides exemptions under defined circumstances, including certain low-value remote transactions, trusted beneficiaries, qualifying recurring transactions, and transaction risk analysis, subject to the relevant conditions.

3DS can be used to signal that no challenge is being requested because an exemption is being sought.

For example, the EMV 3DS Requestor Challenge Indicator includes values expressing the Requestor's authentication preference, while current Mastercard rules specify how a Transaction Risk Analysis exemption can be identified through EMV 3DS.

The sequence can therefore look like:

Merchant / acquirer identifies potentially eligible transaction

→ 3DS authentication request carries exemption-related indicator

→ issuer receives authentication data

→ issuer evaluates transaction

→ issuer accepts frictionless treatment or requests authentication

This creates an important distinction:

Requesting an exemption is not the same as receiving a guaranteed exemption outcome.

The merchant's PSP or acquirer normally determines how exemption strategy is implemented in practice, because regulatory eligibility, acquirer fraud rates, scheme rules, transaction characteristics, and issuer decisioning can all matter.

For the detailed legal treatment of individual exemptions, a merchant should refer to SCA Exemptions rather than treating 3DS configuration itself as the exemption rule.

What information should merchants provide during 3DS authentication?

One of the biggest differences between legacy authentication approaches and modern EMV 3DS is the amount of contextual information available to the issuer.

Better information can help the ACS distinguish a normal returning customer from genuinely unusual activity.

EMVCo specifically recommends providing accurate and complete information where available because incomplete or artificial data can increase challenges or contribute to authentication failure.

Useful information can include:

Transaction information

•amount;

•currency;

•purchase context;

•merchant information;

•transaction type.

Cardholder information

•name;

•billing address;

•shipping address;

•email;

•phone information where applicable.

Merchant relationship information

•age of the customer's merchant account;

•previous transaction history;

•previous authenticated activity;

•login or account-authentication information.

Device and browser information

For browser transactions, EMVCo's current specification guidance covers data including browser IP address, language, screen size, time zone, user-agent information, and other browser characteristics.

For app transactions, richer device information can be collected through the 3DS SDK, subject to applicable permissions, privacy requirements, and platform restrictions.

3DS Method execution

For browser authentication, the issuer may provide a 3DS Method URL so additional browser and device information can be collected before authentication.

EMVCo states that merchants should run this method when requested; failure to do so can result in higher step-up rates and authentication failures because the issuer receives less information for its risk analysis.

The practical principle is straightforward:

Do not send dummy values simply to satisfy required fields.

More data is useful only if the data is accurate.

Merchants must also ensure that the collection and use of device or customer information complies with applicable privacy requirements.

How can 3DS affect authorization and conversion?

3DS can influence conversion in both directions.

Better issuer information can reduce unnecessary friction

Rich 3DS data can allow an issuer to identify legitimate transactions more confidently.

EMVCo states that richer data and flexible authentication can improve issuer decision-making and reduce false declines.

That can mean more legitimate transactions complete through a frictionless path.

Challenges add a checkout step

If the issuer requires additional authentication, the customer must complete it.

Conversion can suffer if:

•the challenge loads slowly;

•the challenge window is poorly integrated;

•the shopper changes devices unexpectedly;

•the banking app handoff fails;

•the OTP does not arrive;

•the customer does not understand why authentication is occurring;

•the return from the issuer does not restore the checkout correctly.

SCA compliance and checkout optimization are therefore not competing objectives.

The implementation goal should be:

give issuers enough reliable information to make good authentication decisions, while making unavoidable challenges easy for legitimate customers to complete.

Authentication does not guarantee authorization

This deserves emphasis.

A successful 3DS result means that the authentication step produced a successful outcome.

The issuer can still decline the subsequent payment authorization.

Likewise, liability-shift treatment can depend on card-network rules and the authentication outcome. It should not be described as a universal consequence of “using 3DS.”

Merchants should confirm scheme-specific liability treatment with their PSP or acquirer.

Merchant responsibilities in a 3DS implementation

The merchant is usually not the regulated payment service provider making the final SCA decision.

That does not mean the merchant has nothing to implement.

A merchant may need to ensure that:

•the checkout integrates with the PSP's supported 3DS flow;

•relevant transaction and customer data is passed accurately;

•browser and device information is available;

•required 3DS Method processing works;

•challenge flows render correctly;

•redirects or app handoffs return customers to the correct state;

•the authentication result is preserved for authorization;

•exemption requests are represented correctly;

•stored-credential and recurring-payment indicators are accurate;

•failures and retries do not accidentally change the transaction classification;

•authentication works across supported browsers, devices, currencies, and markets.

Merchant, PSP, acquirer, issuer, and card-network responsibilities are therefore interconnected.

A merchant should understand which decisions its PSP is making automatically and which configuration decisions remain with the merchant.

Common 3D Secure compliance mistakes

Treating 3DS as the law

It is not.

3DS is the protocol. SCA is the regulatory requirement.

Sending every transaction through an unnecessary challenge

3DS2 was specifically designed to support risk-based and frictionless authentication.

“Forcing 3DS” should not automatically mean “forcing the shopper to enter an OTP.”

Assuming an exemption means the issuer cannot challenge

An exemption request expresses a desired regulatory treatment.

The issuer may still require authentication.

Sending poor-quality authentication data

Incomplete, inconsistent, or fabricated data gives the issuer less confidence and can increase challenges or failures.

Confusing authentication with authorization

The payment is not complete merely because 3DS succeeded.

Ignoring geographic scope

PSD2 SCA does not apply globally.

Other markets may impose different authentication requirements, while card networks can impose their own 3DS rules independently of PSD2.

Merchants expanding internationally should assess Authentication Requirements by Country instead of assuming the European model applies everywhere.

Treating all recurring transactions alike

Initial setup, subsequent recurring payments, merchant-initiated transactions, and customer-initiated stored-card purchases can receive different SCA treatment.

Those distinctions belong in Recurring Payments and SCA and Merchant-Initiated Transactions and SCA, not in a generic rule saying “subscriptions are exempt.”

What merchants should test before going live with 3DS

A 3DS integration should be tested as part of the payment flow—not merely checked as a successful API call.

Test frictionless authentication

Confirm that:

•the authentication returns correctly;

•no unnecessary customer interruption appears;

•authentication data reaches authorization;

•analytics record the result.

Test challenge authentication

Verify:

•browser challenges;

•responsive challenge windows;

•mobile challenges;

•out-of-band banking-app authentication where supported;

•successful return to checkout;

•customer cancellation;

•failed challenges.

Test authentication failures

Include:

•ACS unavailable;

•Directory Server errors;

•network timeout;

•incomplete 3DS Method;

•unsupported version;

•issuer unable to authenticate.

The business should know whether each condition means:

retry

continue under an allowed treatment

or

stop the payment

rather than improvising in production.

Test exemption behavior

Where your PSP supports merchant or acquirer exemption strategies, verify:

•how exemption eligibility is determined;

•which indicator is transmitted;

•what happens if the issuer rejects the exemption;

•whether the transaction can be retried with authentication.

Test authorization after authentication

Check that returned authentication values are passed correctly to the authorization request.

Authentication and authorization should not be treated as disconnected integrations.

Test stored-card and recurring flows

The initial customer setup and later merchant-triggered charges can follow different regulatory and scheme logic.

Test by market and card type

Issuer behavior varies.

Testing one card from one issuer is not evidence that the checkout works across the intended market.

Measure the whole authentication funnel

Useful operational metrics include:

•percentage entering 3DS;

•frictionless outcomes;

•challenge rate;

•challenge completion;

•authentication failure;

•authorization after successful authentication;

•checkout abandonment;

•exemption-request outcomes;

•results by issuer, country, device, and card network.

The objective is not to maximize or minimize the use of 3DS.

It is to ensure the correct authentication path succeeds for as many legitimate transactions as possible.

Key takeaway

The central rule for 3D Secure compliance is simple:

Do not treat 3D Secure, Strong Customer Authentication, and card-network rules as the same thing.

SCA defines the regulatory authentication requirement.

EMV 3-D Secure provides a technical framework for exchanging the information and authentication results needed to support ecommerce card authentication.

Card networks then define additional operating requirements for how their 3DS programs should be used.

For merchants, the practical sequence is:

Determine whether SCA is relevant

→ determine whether the transaction is in scope, exempt, or otherwise treated differently

→ send accurate data through 3DS

→ allow the issuer to make the authentication decision

→ support a frictionless or challenge outcome

→ pass the authentication result correctly into authorization

The biggest implementation mistakes happen when those decisions are compressed into a single rule such as:

“European payment = force 3DS challenge.”

A better payment architecture lets the merchant, PSP, acquirer, card network, and issuer perform their actual roles while the checkout supports whatever authentication outcome is required.

That is also why 3DS should be tested before the final launch stage. Authentication touches the checkout interface, customer data, issuer decisioning, exemption strategy, authorization messaging, retries, recurring payments, and analytics. Discovering those requirements after the checkout is already complete is how authentication compliance becomes a launch blocker instead of a built-in part of payment infrastructure.

Specific SCA and 3DS requirements depend on the market, transaction type, payment service providers involved, scheme rules, and current regulatory framework. Merchants should confirm the treatment of their payment flows with their PSP, acquirer, and appropriate regulatory advisers.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

For this article, I’d make the SEO/editorial strategy revolve around one distinction: 3DS is the authentication protocol; SCA is the regulatory requirement; card schemes add another operating-rule layer. That is the strongest reason for this page to exist within the Authentication and Payment Regulation cluster.

SEO recommendations

Element

Recommendation

H1

3D Secure Compliance: How 3DS Supports Strong Customer Authentication

Title tag

3D Secure Compliance: 3DS2, SCA & PSD2 Explained

Alternative title tag

3D Secure Compliance: Is 3DS Required for SCA?

URL

/3d-secure-compliance/

3D Secure compliance

Meta description

Learn how 3D Secure supports SCA, how frictionless and challenge flows work, how exemptions interact with 3DS2, and what merchants should test before launch.

Suggested excerpt

3D Secure is not the regulation itself. Learn how EMV 3DS supports Strong Customer Authentication, when customers may be challenged, and what merchants need to implement before launch.

I slightly prefer “Is 3DS Required for SCA?” as the title-tag angle if search acquisition is the priority. It mirrors the actual commercial question behind the query rather than merely repeating the article title.

Google’s current guidance continues to favor informative, compact page titles and descriptive internal-link anchors rather than repetitive keyword use.

The semantic terms worth naturally covering are 3DS compliance, 3DS2 compliance, 3D Secure SCA, PSD2 3D Secure, 3D Secure requirements, EMV 3-D Secure, frictionless 3DS, 3DS challenge flow, SCA exemption, 3DS authentication, issuer ACS, authentication vs authorization, and Strong Customer Authentication. I would not attempt to hit every variant repeatedly.

The search position I would try to own

A lot of available content falls into one of two extremes: regulatory SCA explainers or highly technical 3DS integration documentation. Current PSP documentation, for example, tends to approach 3DS specifically as an implementation mechanism for PSD2/SCA.

“We accept ecommerce cards and need to satisfy authentication requirements. What exactly does 3DS do, when will the customer see a challenge, and what needs to work before we launch?”

That makes the article relevant to developers and payments/product/compliance leadership.

The primary editorial thesis should appear very early and perhaps as a designed pull quote:

3D Secure is not SCA. 3DS is a protocol that helps deliver cardholder authentication; SCA determines when compliant authentication is required.

Add a direct-answer box

Immediately after the introduction, I’d add a compact box called “3D Secure Compliance at a Glance.”

Question

Direct answer

Is 3DS the same as SCA?

No. SCA is a regulatory requirement; 3DS is an authentication protocol.

Does PSD2 specifically mandate 3DS?

No. The regulatory framework is technology-neutral, although EMV 3DS is widely used for ecommerce-card SCA.

Does 3DS always interrupt checkout?

No. Authentication can be frictionless.

Who decides whether to challenge?

The issuer, through its Access Control Server, makes the authentication decision.

Can 3DS carry an exemption request?

Yes, depending on the exemption strategy and implementation.

Can the issuer challenge anyway?

Yes. Requesting an exemption does not guarantee a frictionless transaction.

Does successful authentication mean payment approval?

No. Authorization is a separate step.

That gives search engines, AI answer systems, executives, and developers a concise summary before the deeper explanation.

Featured-snippet target

Under “Is 3D Secure required for SCA?”, make the opening paragraph something like:

PSD2 does not mandate 3D Secure as the only way to perform Strong Customer Authentication. SCA is a regulatory requirement, while EMV 3-D Secure is an authentication protocol widely used by ecommerce merchants, issuers and acquirers to exchange the information needed to support card authentication and SCA.

That is probably the highest-value standalone answer on the page.

One editorial addition I strongly recommend

Add a very short H2:

Authentication vs authorization: what is the difference?

Then make the distinction almost visual:

Authentication asks:

Is this likely the legitimate cardholder?

Authorization asks:

Should the issuer approve this transaction?

Then explain that successful 3DS authentication can still be followed by an authorization decline.

That misconception is common enough—and commercially important enough—that it deserves more prominence than it currently has.

Internal-link structure

This article should function as the technical bridge in the cluster rather than explaining all of SCA itself.

Strong Customer Authentication Explained should receive the strongest link near the first regulatory definition, using anchor text such as Strong Customer Authentication.

SCA Requirements for Merchants belongs in the section answering whether 3DS is required, with anchor text such as when SCA applies to ecommerce payments.

SCA Exemptions belongs in the exemption section, using SCA exemptions naturally.

PSD2 Explained should be linked from the first discussion of the EU regulatory basis.

Then use narrower downstream links from the relevant edge cases to Recurring Payments and SCA, Merchant-Initiated Transactions and SCA, Transaction Risk Analysis Exemptions, and Authentication Requirements by Country.

Google's current internal-link guidance specifically recommends descriptive, concise anchor text and contextual links between related pages.

Visual assets I would add

This article is an excellent candidate for diagrams. Decorative fintech photography would add very little.

Visual

What it should communicate

Placement

Hero — Checkout → 3DS → Issuer → Authorization

3DS sits between ecommerce checkout and issuer authentication

Top

3DS vs SCA vs Network Rules

Regulation, protocol and scheme rules are three separate layers

After definitions

Frictionless vs Challenge Flow

Issuer decides whether shopper interaction is necessary

Flow section

SCA Exemption Request Flow

Exemption request does not guarantee no challenge

Exemptions section

Authentication vs Authorization

Successful 3DS ≠ payment approval

Conversion section

3DS Go-Live Checklist

What merchant teams should test

Implementation section

Signature visual: 3DS vs SCA vs card-network rules

I’d make this the page’s most reusable graphic.

Strong Customer Authentication

Regulatory layer

Defines the required authentication outcome.

↓

EMV 3-D Secure

Technical layer

Carries authentication data and results between merchant/payment infrastructure and issuer.

↓

Card-network programs and rules

Operating layer

Define how 3DS is used within the relevant card scheme.

Footer:

Three layers. One payment flow. Different requirements.

Filename: 3ds-vs-sca-card-network-rules.svg

Alt text: Difference between Strong Customer Authentication EMV 3D Secure and card network authentication rules

Frictionless vs challenge diagram

Start with:

Merchant sends 3DS authentication request

↓

Issuer evaluates transaction, customer and device information

Then split into:

Frictionless

→ sufficient issuer confidence

→ no customer interaction

→ authentication result

versus

Challenge

→ additional verification required

→ bank app / biometric / OTP / supported method

→ authentication result

Both reconnect at:

Payment authorization

The footer should say:

The issuer determines the authentication path.

This is the visual I would expect developers and product managers to refer back to most often.

Exemption-request diagram

This should show:

Potentially eligible transaction

→ Merchant / PSP / acquirer exemption strategy

→ 3DS request carries relevant information

→ Issuer evaluates

Then split:

No challenge required

or

Issuer requests authentication

The key caption:

Exemption requested ≠ authentication impossible

That one line prevents a major conceptual error.

Authentication vs authorization asset

This can be very small:

3DS AUTHENTICATION

“Is this likely the legitimate cardholder?”

↓

PAYMENT AUTHORIZATION

“Should this payment be approved?”

↓

Approved / Declined

This could even be a designed callout rather than a full infographic.

Hero-image direction

I’d avoid padlocks, giant shields, courthouses, or generic cybersecurity imagery.

The hero should look like payment infrastructure:

Customer device → Checkout → 3DS authentication layer → Issuer → Authorization response

Place two small labels above the flow:

SCA regulatory requirement

over the authentication portion, and

EMV 3DS protocol

directly over the technical exchange.

Suggested filename: 3d-secure-compliance-sca.jpg

Suggested alt text: 3D Secure authentication flow supporting Strong Customer Authentication for ecommerce card payments

Google recommends descriptive filenames and alt text as part of helping Search understand image content.

FAQ opportunities

I would add a short FAQ before the Key Takeaway, focused only on genuinely useful questions: Is 3D Secure mandatory under PSD2? What is the difference between 3DS and 3DS2? Does every 3DS payment require an OTP? Who decides whether a challenge appears? Can an issuer challenge when an exemption was requested? Does successful 3DS guarantee authorization?

Those questions strengthen semantic coverage without turning the article into a manufactured FAQ page.

Technical/editorial treatment

Show a visible Last reviewed date because three things can evolve independently: regulation, card-network rules, and the EMV 3DS specification. Current 2026 search results still show merchant implementation material centering on EMV 3DS 2.2/2.3.1 functionality, reinforcing the need for version-aware rather than timeless implementation guidance.

I’d also use an anchored table of contents, Article or BlogPosting structured data, BreadcrumbList, genuine author/reviewer information, crawlable SVGs for the diagrams, and contextual internal links rather than separate “related articles” links doing all of the work.

Best editorial positioning

If I reduced the entire strategy to one line, it would be:

Make this the merchant-focused page that explains how the regulatory SCA requirement becomes an actual 3DS authentication flow at checkout.

And I would repeat this conceptual sequence throughout the page:

SCA requirement → 3DS request → issuer decision → frictionless or challenge → authentication result → authorization

That makes the article useful not just for somebody asking “What is 3DS?”, but for the much more valuable reader asking “What actually has to work before I launch?”