Strong Customer Authentication Explained

Strong Customer Authentication Explained: A Guide for Merchants

Strong Customer Authentication can change what happens at the most sensitive point in an ecommerce journey: the moment a customer tries to pay.

A checkout that appears to require only card details can suddenly ask the customer to approve a banking-app notification, provide another authentication factor, or complete an issuer challenge. Another transaction can proceed without visible authentication at all.

For merchants, the challenge is understanding why.

Strong Customer Authentication (SCA) is a regulatory authentication requirement that, when applicable, requires the payer to be authenticated using at least two independent elements from specified categories. In the European Economic Area, the current SCA framework comes from the Second Payment Services Directive (PSD2) and its Regulatory Technical Standards. It is designed to improve payment security and reduce fraud.

But SCA does not mean that every ecommerce payment must show the customer an extra challenge.

Some transactions can qualify for exemptions. Others can fall outside the SCA requirement altogether. Authentication can also take place without a visible challenge.

For a merchant designing a payment flow, the practical task is therefore to understand:

Is SCA in scope?

→ Is an exemption potentially available?

→ Can the payment be authenticated frictionlessly?

→ What happens if the issuer requires customer interaction anyway?

The article brief correctly makes these distinctions central to a merchant-friendly explanation of SCA.

What is Strong Customer Authentication?

Under PSD2, Strong Customer Authentication means authentication based on at least two elements from the categories of:

•knowledge — something only the customer knows;

•possession — something only the customer possesses;

•inherence — something the customer is.

The elements must be independent so that compromising one does not undermine the reliability of the other.

In practical payment terms, this might involve combinations such as:

possession + knowledge

or:

possession + inherence.

The regulation defines the categories rather than prescribing one universal customer interface.

SCA therefore does not mean:

password + OTP in every checkout.

Different banks, devices, payment methods, and authentication technologies can implement the requirement differently.

Why does SCA exist?

The regulatory objective is payment security.

PSD2 requires payment service providers to apply SCA in specified circumstances, including when a payer initiates an electronic payment transaction. For remote electronic payments, the framework additionally requires authentication that dynamically links the payment to a specific amount and payee.

That dynamic-linking requirement is intended to make the authentication relevant to the transaction actually being authorized rather than merely proving that a customer previously logged in.

From the merchant's perspective, this creates a trade-off to manage carefully:

payment security

without:

unnecessary checkout friction.

The merchant does not solve that trade-off by avoiding authentication.

It solves it by implementing the payment flow correctly so that SCA can be applied when required and appropriate exemptions or lower-friction authentication paths can be used when permitted.

What are the three SCA authentication factors?

The easiest way to understand SCA is to separate the three factor categories.

Factor

Regulatory concept

Typical form

Knowledge

Something only the user knows

Password, PIN or other secret

Possession

Something only the user possesses

Registered device or other controlled authentication instrument

Inherence

Something the user is

Biometric characteristic

Two elements are needed, and they must meet the regulatory requirements for independence.

That means two pieces of information from the same factor category do not automatically satisfy SCA merely because the customer performed two actions.

The question is not:

How many screens did the customer complete?

It is:

Were appropriate independent authentication elements used?

When does Strong Customer Authentication apply?

Under the current EEA PSD2 framework, payment service providers are generally required to apply SCA when the payer:

•accesses a payment account online;

•initiates an electronic payment transaction;

•performs a remote action that may create a risk of payment fraud or other abuse.

For remote electronic payment transactions, the dynamic-linking requirement also applies.

For an ecommerce merchant, the most relevant case is usually:

the customer initiates an electronic payment.

A typical customer-initiated online card purchase can therefore fall within the SCA framework.

But that is only the beginning of the analysis.

The merchant must then determine whether:

SCA is required without an applicable exemption

or:

the transaction may qualify for an exemption

or:

the transaction is outside the relevant SCA scope.

Those outcomes are different.

SCA applies to a regional regulatory framework—not every payment worldwide

SCA should not be presented as a universal ecommerce rule.

The framework discussed here is primarily the European PSD2 SCA regime.

The UK retained its own Strong Customer Authentication requirements after leaving the EU. Current FCA guidance states that UK SCA rules apply when a payer initiates an electronic payment, accesses a payment account online, or performs certain risky remote actions, subject to applicable exemptions. The UK now has its own technical standards, which remain related to but legally separate from the EU framework.

Other countries can have different payment-authentication requirements.

A global merchant should therefore avoid implementing:

sca_required = true

for every international card payment.

Authentication configuration should be sensitive to the applicable market, transaction, payment method, and provider setup.

When might SCA not be required?

There are two fundamentally different reasons why a customer might not complete SCA for a payment:

•The transaction is in scope, but an exemption applies

The regulatory requirement exists, but the payment qualifies for an exemption under defined conditions.

•The transaction is outside the SCA requirement

The transaction does not fall within the payer-initiated payment situation to which the requirement applies in the first place.

These should never be merged into:

“SCA bypass.”

The legal reasoning and operational treatment are different.

What are the main SCA exemptions?

The EU Regulatory Technical Standards contain several defined exemptions.

Not all are equally relevant to ecommerce merchants, and eligibility does not guarantee that the customer will never be authenticated.

Important examples include the following.

Low-value remote payments

The current EU RTS permits payment service providers not to apply SCA to qualifying low-value remote electronic payments when the specified amount and cumulative/count conditions are satisfied.

This is a defined regulatory exemption.

It is not a merchant rule that says:

“Any payment under €30 never needs authentication.”

The RTS includes cumulative controls, and PSPs can require SCA earlier based on fraud-management procedures.

Transaction Risk Analysis

The Transaction Risk Analysis, or TRA, exemption can allow a payment service provider not to apply SCA to a qualifying remote electronic transaction assessed as low risk, subject to the detailed fraud-rate, transaction-value, and real-time risk-analysis conditions in the RTS.

For merchants, the important distinction is:

TRA eligibility depends on the payment-service-provider framework and transaction risk—not simply on the merchant deciding that a customer looks trustworthy.

Detailed TRA thresholds and fraud-rate mechanics deserve their own treatment rather than being reduced to a sentence in a foundational SCA article.

Trusted beneficiaries

The RTS permits an exemption where a payer initiates a payment to a payee previously included in a trusted-beneficiary list maintained through the payer's payment-service provider. SCA is required when creating or amending that list.

This is largely controlled through the payer's payment provider rather than by a merchant adding itself to a private “trusted” database.

Recurring transactions

For a qualifying series of recurring payments with the same amount and same payee, the current RTS requires SCA when the payer creates, amends, or initiates the series for the first time. Subsequent payments within that defined series may proceed without SCA under the recurring-transactions exemption.

This is often oversimplified as:

“Subscriptions are exempt from SCA.”

That statement is too broad.

A recurring subscription can involve different payment structures, including merchant-initiated transactions, variable amounts, customer-present recovery payments, and changes to the recurring agreement.

Those scenarios do not all depend on the same SCA treatment.

An exemption request does not guarantee a frictionless payment

This is one of the most important merchant implementation points.

A merchant or its acquirer may structure a transaction so that an applicable exemption is requested.

That does not mean the merchant has the final word.

EBA guidance states that, in a card transaction, the payer's PSP—the issuer—ultimately decides whether to accept or apply an exemption. If the issuer does not accept an exemption and wants SCA, it can require authentication where technically feasible or decline the payment.

So the operating model is closer to:

PAYMENT CREATED

|

v

IS SCA IN SCOPE?

/ \

NO YES

| |

| v

| EXEMPTION ELIGIBLE?

| / \

| NO YES

| | |

| v v

| SCA EXEMPTION

| REQUEST /

| APPLICATION

| |

| v

| ISSUER MAY ACCEPT

| OR REQUIRE SCA

| |

+---------------+

|

v

PAYMENT OUTCOME

This is why merchants should never promise product teams:

“This exemption removes authentication.”

A better description is:

“This transaction may be eligible to proceed without SCA, subject to the applicable payment-service-provider and issuer decision.”

What does “outside the scope of SCA” mean?

An out-of-scope transaction is conceptually different from an exemption.

A particularly important example is a genuine merchant-initiated transaction, or MIT.

The European Banking Authority has explained that a payment initiated by the payee without interaction or involvement by the payer is not subject to SCA in the same way as a payer-initiated transaction, provided the relevant conditions are satisfied.

For example, a customer might establish an appropriate agreement allowing a merchant subsequently to initiate a payment without the customer being present.

If a later transaction is genuinely initiated by the merchant under that mandate and does not depend on a new action by the customer, it can be treated differently from a customer clicking:

Pay now.

The EBA specifically explains that standing agreements can support payee-initiated transactions where the merchant initiates later payments independently of a specific payer action.

This distinction matters greatly for:

•subscriptions;

•usage-based billing;

•hotel charges;

•delayed charges;

•certain stored-credential arrangements.

But a merchant should not simply label a payment:

MIT

to avoid SCA.

The actual transaction must fit the relevant payment and regulatory classification.

Initial setup can still require SCA for later merchant-initiated payments

The fact that a later merchant-initiated payment can fall outside the payer-initiated SCA requirement does not mean the original relationship can be established without appropriate authentication.

EBA guidance on card arrangements has explained that when a payer remotely establishes a mandate allowing later payee-initiated transactions, SCA can be required when that mandate is set up because the remote action may itself carry fraud or abuse risk.

Operationally, this produces a lifecycle rather than a one-time rule:

CUSTOMER-PRESENT SETUP

|

v

SCA WHERE REQUIRED

|

v

RECURRING / STORED-CREDENTIAL

RELATIONSHIP ESTABLISHED

|

v

LATER PAYMENT

|

+--> PAYER INITIATES → assess SCA/exemptions

|

+--> GENUINE MIT → different SCA treatment

This distinction becomes especially important for subscription merchants.

How does 3D Secure relate to SCA?

3-D Secure and SCA are not the same thing.

SCA is the regulatory requirement.

EMV 3-D Secure (EMV 3DS) is a technical messaging protocol used for card-not-present authentication between participants in an ecommerce payment.

EMVCo describes EMV 3DS as a protocol that enables consumers to authenticate with their card issuer during card-not-present ecommerce purchases and is designed to support both frictionless and active authentication experiences.

A useful merchant mental model is:

SCA = regulatory requirement

3DS = one technical mechanism that can support cardholder authentication

That means neither of these statements is accurate:

“PSD2 requires every merchant to show a 3DS challenge.”

or:

“If we integrated 3DS, every payment is automatically SCA compliant.”

Whether the final authentication satisfies the applicable requirement depends on the payment flow and authentication result.

Frictionless 3DS does not mean authentication was skipped

Modern 3DS flows can transmit payment and risk data so that the issuer can assess the transaction without necessarily asking the cardholder to complete an additional visible step.

EMVCo's 3DS materials explicitly describe support for frictionless authentication alongside challenge flows.

This gives merchants an important UX distinction.

Frictionless flow

The authentication process can complete without requiring an additional interactive challenge from the customer.

Challenge flow

The issuer requires the cardholder to complete an active authentication step.

Both can be part of the 3DS ecosystem.

So:

no challenge

does not necessarily mean:

no authentication.

And:

challenge shown

does not mean:

payment authorization is guaranteed.

Authentication and authorization remain separate

SCA or 3DS authentication answers a question about the legitimacy of the customer/payment interaction.

Authorization answers:

Will the issuer approve this transaction?

A payment can therefore have:

successful authentication

followed by:

declined authorization.

Possible reasons for an authorization decline can involve factors unrelated to the authentication result.

Merchants should preserve these as separate states in their payment data:

authentication_status

and:

authorization_status.

Do not collapse them into one:

payment_verified = true.

Who decides whether authentication is required?

Several participants can influence the payment flow.

Merchant

The merchant designs checkout and provides the payment context required by its PSP/acquirer.

PSP or acquirer

The merchant's payment provider can determine how the payment is submitted, whether an eligible exemption is requested or applied where permitted, and how 3DS is invoked.

Card network and technical infrastructure

Networks and authentication protocols define how the relevant card-authentication information is transmitted.

Issuer

For card transactions, the payer's PSP—the issuer—has the ultimate position on whether to accept an applicable exemption or require SCA within the regulatory framework.

This is why checkout architecture must support more than the merchant's preferred outcome.

A merchant cannot safely build:

“frictionless only.”

It needs a path for:

issuer requests authentication

→ customer completes authentication

→ payment continues.

How does SCA affect ecommerce conversion?

Authentication can add customer interaction.

Any additional interaction can create a point where customers abandon checkout.

But the correct commercial objective is not:

minimize SCA at all costs.

It is:

avoid unnecessary friction while ensuring required authentication can complete successfully.

Poorly implemented SCA can hurt conversion through problems such as:

•broken challenge redirects;

•poor mobile UX;

•lost payment state after authentication;

•authentication pages that do not return customers correctly;

•retrying payments without understanding the previous authentication state;

•failing to pass relevant transaction data;

•assuming an exemption will always be accepted;

•failing to handle issuer step-up requests.

Merchants should therefore measure the authentication funnel separately from overall payment conversion.

Useful stages include:

authentication initiated

→ frictionless authentication completed

or:

challenge presented

→ challenge completed

→ authorization submitted

→ authorization approved.

That allows the merchant to distinguish:

authentication abandonment

from:

issuer authorization decline.

What should merchants implement to support SCA?

A robust ecommerce flow should be designed for multiple outcomes.

•Know which transactions are subject to the relevant SCA regime

Do not apply European SCA assumptions globally.

At minimum, understand:

•customer/payment geography;

•acquiring setup;

•payment method;

•transaction type;

•customer participation.

•Support the authentication protocol required by your provider

For online cards, this will commonly involve EMV 3DS through the merchant's PSP or acquirer.

The PSP should provide the specific technical implementation requirements.

•Handle both frictionless and challenge outcomes

The application must not assume that authentication always requires customer interaction—or never does.

Support both paths cleanly.

•Preserve payment state across authentication

A returning customer should not accidentally create:

•a duplicate order;

•a duplicate authorization;

•a lost checkout;

•an inconsistent transaction state.

Engineering should design for idempotency and reliable state transitions.

•Keep exemptions distinct in the payment model

Useful internal fields can include:

•exemption requested;

•exemption type;

•SCA applied;

•authentication result;

•3DS result;

•issuer response;

•authorization result.

Do not store only:

3ds = yes/no.

•Support issuer step-up

A payment designed to use an exemption can still need SCA if the issuer requires it.

Your checkout should be able to transition to authentication rather than simply failing.

•Treat recurring and stored-credential payments as a lifecycle

Record whether:

•the customer is present;

•a recurring arrangement exists;

•initial authentication was completed;

•the current payment is customer-initiated or genuinely merchant-initiated;

•a failed off-session payment requires the customer to return.

This becomes essential for subscription businesses.

•Test the real customer journey

Do not validate only the API response.

Test:

•desktop;

•mobile browser;

•app/webview where relevant;

•challenge flows;

•abandoned authentication;

•authentication timeout;

•customer return;

•authorization after successful authentication;

•failed authentication;

•exemption rejection/step-up.

Compliance and conversion meet in the implementation.

What should merchants ask their PSP?

Before launching an SCA-affected payment flow, get explicit answers to questions such as:

•Which of our transactions fall within the SCA framework?

•How does your integration invoke 3DS?

•Which exemptions can your acquiring setup support?

•Who applies or requests each exemption?

•How do we identify when an exemption was used?

•How do we handle issuer step-up?

•Which authentication results are exposed through the API?

•Which fields distinguish authentication from authorization?

•How are recurring payments classified?

•How are merchant-initiated transactions represented?

•How should we recover a payment that now requires customer authentication?

•Does the implementation differ by acquiring route or country?

A vague answer such as:

“We handle SCA automatically.”

is not enough for a merchant that needs reliable payment-state and customer-experience design.

SCA exemptions and out-of-scope payments should remain separate in reporting

A useful reporting model might distinguish:

Payment treatment

Meaning

SCA performed

Strong Customer Authentication applied

Exemption applied/requested

Payment was in scope but relied on an available exemption

Issuer step-up

Authentication required despite the intended lower-friction path

Out of scope

Transaction did not fall within the relevant payer-initiated SCA requirement

Authentication failed

Required authentication did not complete successfully

Authentication succeeded, authorization declined

Authentication and payment approval produced different outcomes

This makes payment optimization substantially easier than grouping everything under:

3DS transactions.

Do not design SCA around today's EU framework alone

As of August 2026, PSD2 and the current SCA Regulatory Technical Standards remain the operative EU framework reflected in official Commission materials. The EU has reached political agreement on replacement PSD3 and Payment Services Regulation legislation, but current official materials still show the revision process rather than a replacement regime already applying.

That makes SCA implementation a maintained payment capability rather than a one-time PSD2 project.

A merchant should know:

•who owns regulatory monitoring;

•who owns PSP/network changes;

•whether authentication logic is configurable;

•whether exemption handling can change without rebuilding checkout;

•whether reporting preserves enough detail to understand the resulting payment behavior.

Strong Customer Authentication is a payment-flow requirement, not a checkout popup

The simplest description of SCA is:

Authenticate the customer using two or more qualifying independent factors when the applicable payment rules require it.

The merchant implementation is more nuanced.

A customer-initiated electronic payment can fall within SCA.

A qualifying payment can potentially use an exemption.

The issuer can still require authentication.

A genuine merchant-initiated transaction can be treated differently because it is outside the payer-initiated payment situation rather than merely “exempt.”

3-D Secure can provide the card-authentication mechanism, but 3DS itself is not the regulation.

And successful authentication does not guarantee successful authorization.

For merchants, that turns SCA into a payment-state design problem:

TRANSACTION CREATED

|

v

DETERMINE PAYMENT CONTEXT

|

v

SCA IN SCOPE?

/ \

NO YES

| |

| v

| EXEMPTION?

| / \

| NO YES

| | |

| v v

| SCA REQUEST/APPLY

| |

| v

| ISSUER DECISION

| |

+-------+-----+

|

v

AUTHENTICATION IF REQUIRED

|

v

AUTHORIZATION

|

v

FINAL PAYMENT STATE

The merchant that understands those transitions can build a checkout that supports regulation without adding unnecessary friction or discovering authentication requirements just before launch.

This article provides general information and does not constitute legal, regulatory, financial, or commercial advice. Strong Customer Authentication requirements vary by jurisdiction, transaction type, payment method, payment-service-provider arrangement, and current regulation. Merchants should verify the rules and implementation requirements that apply to their payment flows with qualified advisers, payment providers, acquirers, and relevant authorities.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

For this page, the strongest SEO opportunity is not adding more regulatory detail; it is making the distinctions between SCA, exemptions, out-of-scope transactions, 3DS, authentication, and authorization exceptionally easy to extract and understand. Those distinctions are explicitly central to the brief.

SEO guidance

Element

Recommendation

Strong Customer Authentication Explained: SCA Guide for Merchants

Alternative SEO title

What Is Strong Customer Authentication (SCA)? Merchant Guide

H1

Strong Customer Authentication Explained: A Guide for Merchants

Meta description

Learn how Strong Customer Authentication works, when PSD2 SCA applies, which transactions may be exempt or out of scope, how 3D Secure fits, and what merchants should implement.

Slug

/strong-customer-authentication/

Strong Customer Authentication

Secondary terms

SCA explained, Strong Customer Authentication requirements, SCA payments, PSD2 SCA, SCA ecommerce

Schema

Article + BreadcrumbList

FAQPage schema

Optional only if the visible FAQ genuinely serves readers; don't manufacture FAQs for schema

The alternative “What Is Strong Customer Authentication (SCA)?” title is slightly stronger for broad informational search. The supplied title is better if consistency with the Authentication and Payment Regulation cluster matters more.

Featured-answer block

I would insert this near the top:

Strong Customer Authentication (SCA) is an authentication requirement that, when applicable, requires a payer to be authenticated using at least two independent elements from the categories of knowledge, possession, and inherence. Under the European PSD2 framework, SCA can apply to customer-initiated electronic payments, while qualifying transactions may use exemptions and some transactions may fall outside the SCA requirement altogether.

This is concise enough for featured snippets and AI answers while retaining the most important regulatory nuance.

Recommended excerpt

Strong Customer Authentication requires qualifying payments to authenticate the customer using independent factors such as knowledge, possession, or inherence. For merchants, the key is distinguishing transactions that require SCA, transactions eligible for exemptions, and transactions outside the SCA scope—and supporting issuer step-up when authentication is still requested.

High-value long-tail search targets

The article already supports these naturally:

•what is Strong Customer Authentication

•how does SCA work

•PSD2 SCA requirements

•when is SCA required

•Strong Customer Authentication ecommerce

•SCA authentication factors

•SCA knowledge possession inherence

•SCA exemptions

•SCA exempt vs out of scope

•does 3D Secure satisfy SCA

•SCA vs 3D Secure

•frictionless 3DS vs SCA

•who decides whether SCA is required

•can issuer require SCA after exemption

•recurring payments SCA

•merchant initiated transactions SCA

•subscription payments SCA

•SCA and authorization

•SCA checkout conversion

I would not create a separate heading for every phrase. The brief appropriately prioritizes semantic completeness over keyword repetition.

Editorial recommendations

•Make this the central distinction box

The article's strongest editorial asset is:

Treatment

Meaning

SCA required

Transaction is in scope and no applicable exemption removes the immediate SCA requirement

SCA exemption

Transaction is in scope, but defined conditions may allow it to proceed without SCA

Out of scope

Transaction is not subject to the relevant payer-initiated SCA requirement in the first place

Frictionless authentication

Authentication occurs without a visible customer challenge

Issuer step-up

Issuer requires customer authentication despite the intended lower-friction route

This should sit fairly high on the page.

It solves several reader misconceptions at once.

•Promote “3DS ≠ SCA” into a visual callout

The body explains this well, but it deserves a stronger editorial treatment:

SCA is the regulatory requirement. 3-D Secure is a technical authentication protocol that can help support SCA for online card payments.

That is extremely extractable for search engines and AI answers.

•Make “authentication ≠ authorization” equally prominent

A second callout:

Authentication asks whether the payer has been appropriately verified. Authorization asks whether the issuer will approve the payment. A transaction can authenticate successfully and still be declined.

This will differentiate the page from basic SCA explainers.

•Add a compact “merchant implementation checklist”

Near the end, I would summarize the practical requirements as:

Merchant SCA readiness

•Determine where SCA rules apply.

•Support your PSP's 3DS implementation.

•Handle frictionless and challenge flows.

•Preserve checkout/payment state through authentication.

•Support issuer step-up.

•Track exemption and authentication outcomes separately.

•Distinguish customer-initiated and merchant-initiated payments.

•Test recovery when an off-session payment requires customer authentication.

•Monitor authentication and authorization separately.

This converts the article from explanation into implementation guidance without turning it into the separate SCA Requirements for Merchants page.

•Keep exemption details deliberately shallow

The article should name and explain:

•low value;

•Transaction Risk Analysis;

•trusted beneficiaries;

•recurring fixed-amount series.

But I would not expand all thresholds, cumulative counters, fraud-rate bands, or detailed qualification mechanics here.

Those belong in:

•SCA Exemptions

•Low-Value Transaction Exemptions

•Transaction Risk Analysis Exemptions

The brief explicitly wants neighboring articles to retain their own scope.

Internal-link strategy

Suggested anchor

Destination

the wider PSD2 payment framework

PSD2 Explained

what merchants need to implement for SCA

SCA Requirements for Merchants

which payments may qualify for an SCA exemption

SCA Exemptions

using 3-D Secure to support card authentication

3D Secure Compliance

how authentication works across a subscription lifecycle

Recurring Payments and SCA

when later off-session charges can be merchant initiated

Merchant-Initiated Transactions and SCA

the specific low-value SCA exemption

Low-Value Transaction Exemptions

risk-based exemption mechanics

Transaction Risk Analysis Exemptions

how authentication requirements differ internationally

Authentication Requirements by Country

The supplied cluster brief explicitly identifies these internal-link relationships.

Visual asset 1 — SCA Decision Flow

This should be the hero visual.

PAYMENT CREATED

|

v

IS THE TRANSACTION

WITHIN SCA SCOPE?

/ \

NO YES

| |

v v

OUT OF IS AN EXEMPTION

SCOPE POTENTIALLY AVAILABLE?

/ \

NO YES

| |

v v

SCA EXEMPTION PATH

|

v

ISSUER MAY STILL

REQUIRE SCA

|

+----------+----------+

| |

v v

FRICTIONLESS CHALLENGE

AUTHENTICATION IF REQUIRED

\ /

+---------+---------+

|

v

AUTHORIZATION

Headline:

First determine scope. Then exemption eligibility. Then authentication outcome.

Alt text:

Strong Customer Authentication decision flow showing SCA scope, exemptions, issuer step-up, frictionless or challenge authentication, and final authorization.

Visual asset 2 — SCA vs 3DS vs Authorization

Concept

Primary question

Role

SCA

Is strong authentication legally required?

Regulation

3-D Secure

How can cardholder authentication be communicated and performed?

Authentication protocol

Authentication

Has the payer been appropriately verified?

Identity/security step

Authorization

Will the issuer approve the payment?

Payment approval

Headline:

Four concepts that should not be collapsed into “3DS.”

This is probably the most valuable reference graphic in the whole article.

Visual asset 3 — The Three Authentication Factors

STRONG CUSTOMER

AUTHENTICATION

|

+----------+----------+

| | |

v v v

KNOWLEDGE POSSESSION INHERENCE

Something Something Something

you know you have you are

Use at least two

qualifying independent factors

Headline:

SCA is based on independent factors, not simply two checkout steps.

Visual asset 4 — Exempt vs Out of Scope

SCA EXEMPTION

Transaction IS within SCA framework

|

v

Defined conditions permit

SCA not to be applied

|

v

Issuer may still require authentication

OUT OF SCOPE

Transaction does NOT fall within

the relevant SCA requirement

|

v

Different regulatory reasoning

Headline:

Exempt and out of scope can produce similar checkout experiences for completely different reasons.

This distinction is specifically required by the editorial brief and should be visually unavoidable.

Visual asset 5 — Subscription Authentication Lifecycle

CUSTOMER SIGNS UP

|

v

CUSTOMER-PRESENT PAYMENT

|

v

SCA WHERE REQUIRED

|

v

CREDENTIAL / MANDATE

RELATIONSHIP ESTABLISHED

|

v

LATER PAYMENT

/ \

v v

CUSTOMER MERCHANT

INITIATED INITIATED

| |

v v

ASSESS SCA / DIFFERENT

EXEMPTIONS SCA TREATMENT

|

v

IF AUTHENTICATION

IS REQUIRED:

BRING CUSTOMER BACK

Headline:

For subscriptions, SCA is a lifecycle—not a one-time checkout setting.

This creates a clean bridge to Recurring Payments and SCA without taking over that article.

Visual asset 6 — Frictionless vs Challenge 3DS

3DS AUTHENTICATION

|

v

ISSUER RISK ASSESSMENT

/ \

/ \

v v

FRICTIONLESS CHALLENGE

No additional Customer completes

visible step active authentication

\ /

+----+----+

|

v

AUTHENTICATION RESULT

|

v

AUTHORIZATION

Headline:

No visible challenge does not necessarily mean no authentication occurred.

Visual asset 7 — Merchant SCA Data Model

A useful technical/editorial asset:

PAYMENT

|

|-- transaction_type

| CIT / MIT / recurring / other

|

|-- sca_scope

| in_scope / out_of_scope

|

|-- exemption

| requested / type / result

|

|-- authentication

| frictionless / challenge / failed

|

|-- 3ds_result

|

|-- issuer_response

|

|-- authorization

approved / declined

Headline:

Store authentication state separately from payment authorization.

This makes the article materially more useful to developers and payment operations teams.

Suggested editorial callouts

I would add four short boxes:

Key distinction: An SCA exemption applies to a transaction that is otherwise in scope. An out-of-scope transaction is outside the relevant SCA requirement in the first place.

Technical distinction: 3-D Secure is a protocol. SCA is a regulatory requirement.

Payments distinction: Successful authentication does not guarantee authorization.

Issuer principle: Exemption eligibility does not guarantee that the issuer will allow the payment to proceed without SCA.

These four statements effectively encode the article's entire conceptual model.

Optional FAQ additions

A short FAQ would be useful if the CMS supports it:

•Does every online payment require SCA?

•Is 3D Secure the same as SCA?

•Can a merchant choose not to use SCA?

•Does an SCA exemption guarantee no customer challenge?

•Are subscription payments exempt from SCA?

•What is the difference between an SCA exemption and an out-of-scope transaction?

•Can a payment pass SCA and still be declined?

•Does SCA apply outside Europe?

I would keep answers around 50–100 words and avoid duplicating full sections.

Best three assets to prioritize

If only three visual/editorial additions are feasible, I would use:

•SCA Decision Flow — best overall decision framework.

•SCA vs 3DS vs Authorization — fixes the biggest technical misconception.

•Exempt vs Out of Scope — protects regulatory accuracy and directly satisfies the brief.

Together, they make the page much more extractable for search, AI answers, developers, and payment teams while preserving the article's assigned role as the foundational SCA explainer, rather than allowing it to cannibalize the deeper exemption, recurring-payment, MIT, or 3DS pages.