SCA Requirements for Merchants

SCA Requirment

The most expensive Strong Customer Authentication problem is not always failing to support authentication. It is building a payment flow that cannot tell when authentication is required, when an exemption may be requested, or how to recover when an issuer asks for authentication after the merchant expected a frictionless payment.

That is why SCA requirements for merchants should be treated as payment architecture, not as a one-time compliance checkbox.

Merchants need a checkout that can support strong authentication when required, send the transaction information needed by their payment provider and issuer, distinguish customer-initiated payments from genuine merchant-initiated payments, handle exemptions correctly, and recover from authentication-related declines without creating unnecessary payment failures.

The merchant does not make every SCA decision alone. Payment service providers (PSPs), acquirers, card networks, and issuers all participate in the process. In particular, the issuer may require authentication even when an exemption has been requested.

This article explains what merchants need to implement for ecommerce payments under the current European Economic Area (EEA) PSD2 framework and the UK's separate SCA regime. Specific requirements depend on jurisdiction, transaction type, payment method, provider setup, and business model, so merchants should confirm their own obligations with their payment providers and qualified regulatory or legal specialists.

When do SCA requirements apply to merchants?

Under PSD2, payment service providers must apply Strong Customer Authentication (SCA) when a payer performs specified activities including initiating an electronic payment transaction, unless an applicable exemption or other scope treatment applies. For remote electronic payments, authentication must also dynamically link the transaction to a specific amount and payee.

SCA means authentication using at least two independent elements from three categories:

•Knowledge: something only the customer knows, such as a password or PIN.

•Possession: something only the customer possesses, such as a registered device.

•Inherence: something the customer is, such as a fingerprint or facial biometric.

The factors must be sufficiently independent so that compromising one does not compromise the reliability of the other.

For ecommerce merchants, SCA is particularly relevant to payer-initiated electronic card payments.

But the geographic test is more nuanced than:

“European merchant = SCA.”

The locations and roles of the payer's and payee's payment service providers matter. The EBA has also clarified that one-leg transactions—where one PSP is inside the EEA and another is outside—can still create SCA-related responsibilities for the part of the transaction occurring within the EEA.

So merchants should avoid hard-coding simplistic assumptions such as:

European customer → always SCA

or:

non-European card → never SCA.

The payment provider and acquiring architecture should determine the appropriate regulatory treatment using the actual transaction context.

The UK now operates under its own Payment Services Regulations and FCA technical standards. The core SCA concept remains similar, but merchants operating in both the UK and EEA should treat them as separate regulatory regimes rather than assuming every current exemption or threshold remains identical.

Internal link opportunity: Strong Customer Authentication Explained

What merchants actually need to support

A merchant does not normally implement the regulatory framework directly.

It implements a payment flow capable of complying with it.

For card payments, that usually means supporting:

•an SCA-capable authentication route;

•EMV 3-D Secure through the merchant's PSP/acquirer where appropriate;

•sufficient payment, customer, device, and transaction context;

•correct customer-initiated, recurring, and merchant-initiated transaction classification;

•supported exemption requests;

•authentication challenges when required;

•recovery when an issuer requests SCA;

•correct subsequent-payment handling;

•logging and monitoring of authentication outcomes;

•testing across normal and failure scenarios.

The implementation therefore needs to answer more than:

“Do we have 3D Secure?”

It needs to answer:

“Can this payment flow correctly move between no SCA required, exemption requested, frictionless authentication, customer challenge, authentication failure, and authenticated retry?”

That is the real merchant implementation problem.

3D Secure is the mechanism, not the regulation

Strong Customer Authentication is the regulatory requirement. EMV 3-D Secure is a technical authentication protocol commonly used to support SCA for ecommerce card payments.

Keeping those concepts separate prevents a lot of implementation confusion.

A merchant does not become SCA-compliant simply because somebody enabled a field labelled 3DS.

The checkout needs to integrate the complete authentication and authorization flow correctly.

Modern EMV 3-D Secure, often referred to as 3DS2, allows merchants and payment providers to send richer transaction and device information through the authentication ecosystem. Depending on the transaction and issuer decision, the authentication flow may proceed without an interactive customer challenge or require the customer to complete an authentication step.

The issuer ultimately participates in determining the authentication outcome.

3DS1 should no longer be designed as the normal fallback

One important correction to older SCA implementation guidance is that merchants should not design new integrations around 3DS1 as the fallback from EMV 3DS.

Major card schemes sunset support for 3DS 1.0.2 in 2022 and moved authentication to EMV 3DS. Visa, for example, discontinued 3DS 1.0.2 support in October 2022, while Mastercard likewise documented the retirement of 3DS1 support.

The current implementation question is therefore:

Does the merchant's PSP/acquirer support the appropriate current EMV 3DS flow and versions for the card networks and markets being served?

not:

Can we redirect to 3DS1 if 3DS2 fails?

Internal link opportunity: 3D Secure Compliance

What payment data should merchants pass?

The exact API fields depend on the payment provider, gateway, acquirer, and network.

But the underlying principle is consistent:

The authentication ecosystem can only make a good decision from the information it receives.

Relevant information can include:

•transaction amount;

•currency;

•merchant/payee identity;

•card or token information;

•customer account information;

•billing and shipping information where appropriate;

•browser or application information;

•device context;

•transaction history where supported;

•whether the customer is actively initiating the payment;

•recurring-payment information;

•stored-credential status;

•merchant-initiated transaction indicators;

•exemption request information;

•previous authentication or agreement references where required.

Merchants should not invent or misclassify these fields merely to avoid an authentication challenge.

For example, a returning customer clicking Pay now with a stored card is still participating in a customer-initiated payment. The fact that the credential was previously stored does not automatically convert the transaction into a merchant-initiated transaction.

Accurate classification is part of correct SCA implementation.

Exemptions reduce unnecessary authentication—but merchants do not control them alone

SCA exemptions can allow qualifying transactions to proceed without requiring full strong authentication in the particular transaction.

But an exemption is not:

a permanent merchant setting

or:

a guarantee that the customer will never be challenged.

It is better understood as part of a transaction-level decision involving the merchant, its PSP/acquirer, and ultimately the issuer.

Low-value transactions

Under the current EEA RTS, a remote electronic payment can potentially use the low-value exemption where the individual transaction does not exceed €30 and the regulatory cumulative/count conditions since the previous SCA have not been exceeded. The current framework refers to a cumulative amount of €100 or five consecutive individual remote transactions.

The UK currently uses separate thresholds: £25 for the individual remote transaction, with a £85 cumulative condition or five consecutive transactions under the relevant provision.

But this does not mean the merchant should build its own counter of every low-value purchase made on a card.

The relevant PSPs—including the issuer in the card flow—operate the regulatory authentication logic and counters. A merchant should integrate the exemption capabilities its PSP/acquirer supports rather than attempting to recreate issuer-side eligibility itself.

Transaction Risk Analysis exemptions

A Transaction Risk Analysis (TRA) exemption can allow a qualifying remote electronic payment assessed as low risk to proceed without SCA under defined regulatory conditions.

The important implementation point for merchants is:

TRA eligibility is not based simply on the merchant deciding that the transaction “looks safe.”

Under the regulatory framework, the relevant payment service provider's monitored fraud rate, applicable value conditions, and real-time risk analysis matter. The UK's current technical standards, for example, explicitly tie TRA to the payment service provider's fraud rate and transaction-level risk analysis.

A merchant using an acquirer-supported TRA exemption therefore needs the correct PSP/acquirer integration.

It does not need to invent its own regulatory TRA calculation.

Trusted beneficiaries

A payer may, through their account-servicing PSP, establish a list of trusted beneficiaries. Qualifying payments to a trusted beneficiary can then potentially proceed without SCA under the applicable exemption.

Critically:

The merchant does not simply declare itself trusted.

The trusted-beneficiary relationship is established by the payer through the relevant PSP.

Exemption requested does not mean exemption guaranteed

Even where an exemption is available and properly requested, merchants should be prepared for the issuer to require authentication.

Current Mastercard rules, for example, support exemption indicators within EMV 3DS but still allow an issuer to require authentication in relevant risk circumstances or when applicable conditions are not met.

The merchant implementation should therefore assume:

Exemption path

→ issuer accepts

or:

Exemption path

→ issuer requests SCA

Both are normal outcomes the checkout needs to handle.

Internal link opportunity: SCA Exemptions

Exemption eligibility should be managed dynamically, not hard-coded

Version 1 was right about the operational principle: exemption handling is an ongoing process rather than a one-time switch.

But the merchant's responsibility needs to be framed accurately.

The merchant generally should not attempt to own regulatory calculations that belong to issuers, acquirers, or PSPs.

Instead, it needs to ensure that:

•transactions are classified accurately;

•the relevant PSP receives enough information;

•exemption indicators are sent correctly;

•recurring and MIT agreements are preserved;

•authentication-required responses are handled;

•provider configuration remains current;

•authentication results are monitored.

That distinction matters.

A merchant-maintained rule that says:

“All payments under €30 bypass authentication”

is not a correct implementation of the low-value exemption.

Neither is:

“Our fraud rate is low, therefore every €200 purchase gets TRA.”

Exemption logic needs to operate through the regulated payment infrastructure that is actually entitled to apply it.

Recurring payments require correct setup and classification

Recurring payments are one of the most commonly confused areas of SCA.

There are two related but distinct concepts.

Fixed recurring series

Under the EEA RTS, SCA is required when the payer creates, amends, or initiates for the first time a series of recurring transactions with the same amount and same payee. Subsequent transactions in that qualifying series may then use the recurring-payment exemption.

Operationally:

Customer sets up subscription

→ SCA at setup/first qualifying transaction

→ subsequent same-amount recurring charges

Merchant-initiated transactions

A genuine merchant-initiated transaction (MIT) is different.

European regulatory guidance has clarified that transactions genuinely initiated by the payee without subsequent payer involvement can fall outside the SCA requirement when they are based on a valid prior mandate or standing agreement. Where that mandate is established remotely, SCA may be required when it is created.

This distinction matters for variable subscriptions, usage-based billing, hotel charges, no-show fees, and other stored-credential arrangements.

Merchants should therefore preserve:

•customer consent;

•the agreement or mandate;

•the initial authenticated setup where required;

•linkage between subsequent charges and that agreement;

•correct stored-credential and MIT indicators required by their provider/network.

Stored credential does not automatically mean MIT

Consider two transactions using the same saved card.

Transaction A

The customer returns to the website, selects a product, and clicks Buy.

That remains customer initiated.

Transaction B

The merchant automatically charges a previously agreed subscription amount when the customer is not interacting with the checkout.

That may qualify as a recurring or merchant-initiated payment depending on its structure.

Same card.

Very different SCA analysis.

Internal link opportunity: Recurring Payments and SCA

Internal link opportunity: Merchant-Initiated Transactions and SCA

How should merchants handle authentication failures?

Merchants should distinguish at least three situations.

•The customer fails or cancels authentication

The merchant should not treat the payment as successfully authenticated.

Depending on the provider response, the checkout may:

•allow another legitimate authentication attempt;

•ask the customer to use another payment method;

•return the customer safely to checkout.

Do not simply submit the same payment repeatedly without understanding the authentication result.

•The issuer says authentication is required

A merchant may first submit a transaction without authentication because it appears exempt, out of scope, or otherwise eligible for a frictionless authorization path.

The issuer can nevertheless indicate that SCA is required.

This is often described operationally as an SCA-related soft decline.

The correct recovery pattern is generally:

Authorization attempted

→ issuer indicates authentication required

→ initiate EMV 3DS while customer is available

→ customer authenticates if challenged

→ resubmit authorization with the authentication result

Current Mastercard documentation explicitly describes issuer responses requiring SCA and authentication-before-reattempt patterns.

This is why authentication recovery should happen while the customer is still in the checkout session where possible.

•The payment has a genuine hard decline

Authentication is not a universal cure for every declined payment.

If the issuer response indicates that the merchant should not retry—for example because of a different card/account or fraud-related reason—the merchant should follow the PSP/network response rather than repeatedly attempting SCA.

The merchant therefore needs to distinguish:

authentication required

from:

authentication failed

from:

issuer declined the payment for another reason.

Treating all three as “3DS failed” creates unnecessary retries and confusing customer journeys.

Incorrect exemption handling does not always produce the same failure

One useful improvement over older implementation guidance is to avoid saying:

“If you request the wrong exemption, the payment simply fails.”

Possible outcomes can vary.

The issuer may:

•accept the exemption;

•require SCA;

•decline authorization;

•return another authentication or authorization outcome depending on the network/provider flow.

The merchant therefore needs recovery logic, not an assumption about one universal failure response.

This is another reason exemption requests should be handled through the merchant's payment provider rather than through static checkout rules.

Merchant, PSP, acquirer, and issuer responsibilities are different

SCA is a shared payment flow.

Participant

Typical SCA role

Merchant

Build SCA-capable checkout, pass accurate transaction data, classify transactions correctly, preserve recurring/MIT agreements, support challenges, and handle outcomes

PSP / gateway

Provide merchant integration, transmit authentication context, expose exemptions and authentication results, and orchestrate relevant technical flows

Acquirer

Participate in transaction routing and supported exemption/authentication handling; TRA eligibility can depend on acquirer/PSP fraud performance

Issuer

Authenticate its customer, assess transaction risk, determine whether a challenge is required in relevant flows, and make the authorization decision

Card network / EMV 3DS infrastructure

Define and transport relevant authentication messages under applicable technical/network rules

The most important implication is:

The merchant must support SCA correctly without pretending it controls the issuer's authentication decision.

That changes how the checkout should be designed.

Instead of asking:

“Should we challenge this customer?”

the merchant often needs to ask:

“What transaction context should we send, what exemption or classification is appropriate, and can our checkout respond correctly to the issuer's decision?”

Avoid challenging every payment simply to be safe

The opposite implementation mistake is to force interactive authentication on every transaction.

That may appear conservative from a compliance perspective, but it ignores the purpose of permitted exemptions and risk-based authentication flows.

A merchant should not bypass required authentication.

But neither should it assume:

more challenges = better compliance.

Unnecessary challenge flows can:

•add checkout steps;

•increase abandonment risk;

•introduce customer confusion;

•create additional failure points.

The better architecture lets the regulated authentication ecosystem determine when customer interaction is necessary while giving it enough data to make that decision accurately.

Internal link opportunity: How to Reduce Unnecessary 3DS Challenges

What should merchants monitor after launch?

SCA should not be treated as a project that ends when the integration passes QA.

Monitor outcomes such as:

•percentage of payments entering EMV 3DS;

•frictionless versus challenged authentication outcomes where available;

•authentication success/failure;

•customer cancellations during challenge;

•authentication-required declines;

•successful recovery after authentication;

•authorization rate after successful SCA;

•exemption-request outcomes;

•recurring/MIT classification errors;

•payments failing because required authentication could not be completed;

•changes by market, issuer, payment provider, or device type.

Do not collapse all of these into a single 3DS conversion rate.

An authentication can succeed and authorization can still fail.

Likewise, authorization performance can change for reasons unrelated to authentication.

Keep:

authentication outcome

and:

issuer authorization outcome

separate.

That distinction makes troubleshooting much faster.

SCA implementation checklist for merchants

Before launching an EEA or UK ecommerce payment flow, verify the following.

Scope and routing

•We know which markets and payment flows may be subject to SCA.

•We do not use merchant location alone to determine SCA scope.

•Our PSP/acquirer supports the relevant EEA and/or UK requirements.

Authentication

•Current EMV 3DS is implemented for relevant card flows.

•We are not relying on 3DS1 as a fallback architecture.

•Both frictionless and challenge outcomes are supported.

•Challenge completion can return the customer reliably to checkout.

•Authentication state survives redirects/app transitions where relevant.

Data

•Required transaction and customer context is passed accurately.

•Amount and currency remain consistent across authentication and authorization.

•Merchant/payee information is correct.

•Browser/device information required by our integration is supplied.

•Transaction-purpose indicators are correct.

Exemptions

•We know which exemption requests our PSP/acquirer supports.

•We do not hard-code low-value eligibility solely from transaction amount.

•We do not calculate TRA eligibility from an unsupported merchant-only fraud metric.

•We understand that an issuer can still require SCA.

•We have a recovery path when an exemption is not accepted.

Recurring payments and stored credentials

•Initial subscription/setup transactions authenticate where required.

•Customer consent/mandate is preserved.

•Subsequent recurring transactions are linked correctly.

•Merchant-initiated transactions are genuinely merchant initiated.

•Customer-initiated saved-card payments are not incorrectly labelled MIT.

•Variable and fixed recurring models are classified correctly.

Failure handling

•Authentication failures are distinguished from authorization declines.

•SCA-required soft declines can trigger authentication and reauthorization.

•Hard declines are not blindly retried.

•Timeouts and authentication-unavailable states have safe customer flows.

•Duplicate charging is prevented during retries.

Monitoring

•Authentication success is measured separately from authorization success.

•Soft-decline recovery is monitored.

•Recurring/MIT errors are visible.

•Provider or regulatory changes can be reflected without rebuilding checkout logic.

What should merchants test before launch?

A standard successful 3DS transaction is not enough.

Test at least these scenarios with your payment provider:

•SCA-required customer-initiated payment

•Frictionless EMV 3DS flow

•Interactive issuer challenge

•Customer successfully completes challenge

•Customer fails authentication

•Customer cancels authentication

•Authentication times out

•Exemption requested and accepted

•Exemption requested but issuer requires SCA

•Authorization soft-declined for authentication

•Successful SCA followed by reauthorization

•Hard issuer decline

•Stored-card customer-initiated purchase

•First recurring-payment setup

•Subsequent recurring charge

•Genuine merchant-initiated transaction

•Changed recurring agreement

•International transaction where geographic scope differs

•Mobile/app authentication return flow if applicable

•Duplicate/retry protection

A merchant that tests only:

“Does the 3DS challenge page open?”

has tested the smallest part of the SCA implementation.

Common SCA implementation mistakes

Treating 3DS as synonymous with SCA

EMV 3DS is a technical mechanism used in card authentication. SCA is the regulatory requirement.

Building around 3DS1 fallback

Major card-network support for 3DS1 was sunset years ago. Modern integrations should use current EMV 3DS capabilities.

Treating every transaction as a challenge

An SCA-capable payment can take different authentication paths. The merchant should support the issuer/provider decision rather than force unnecessary customer interaction.

Treating exemptions as merchant-owned rules

Low-value counters, regulatory TRA conditions, and issuer decisions cannot simply be reconstructed as static merchant checkout logic.

Assuming an exemption guarantees no authentication

It does not.

Confusing recurring exemption with MIT

Fixed recurring series and genuine merchant-initiated payments have different regulatory concepts and implementation requirements.

Calling every stored-card payment an MIT

If the customer actively initiates the payment, stored credentials do not automatically make it merchant initiated.

Ignoring SCA-related soft declines

A payment initially sent without authentication may require the merchant to authenticate and then reauthorize.

Retrying every decline through 3DS

Some declines should not be retried.

Mixing authentication success with payment approval

The issuer still performs authorization after authentication.

SCA requirements continue to change

The strongest idea from older versions of this article remains valid:

SCA is not something a merchant implements once and forgets.

But the maintenance burden should be understood correctly.

Merchants should monitor:

•regulatory changes;

•PSP/acquirer implementation changes;

•card-network requirements;

•supported EMV 3DS versions;

•exemption handling;

•recurring/MIT rules;

•authentication failure patterns.

The EU is currently progressing a new Payment Services Regulation alongside PSD3. Parliament and Council reached a provisional political agreement in November 2025, and official EU legislative material in 2026 described the package as close to adoption, with final compromise texts progressing through the legislative process.

Until replacement provisions become applicable, merchants should continue implementing the requirements actually in force rather than building production decisions around proposed rules.

The UK should also be monitored independently. Its SCA technical standards remain separate and were amended again in March 2026, illustrating why merchants operating in both regimes should not assume that exemption rules will evolve in lockstep.

A practical engineering principle follows:

Keep SCA configuration changeable. Do not bury jurisdictional thresholds, transaction classifications, or provider assumptions permanently inside checkout code.

The key takeaway

SCA compliance for merchants is not:

“Turn on 3D Secure.”

It is:

Identify the transaction correctly

→ send sufficient context

→ support current EMV 3DS

→ request supported exemptions appropriately

→ allow the issuer to require authentication

→ handle challenges and failures

→ classify recurring and merchant-initiated payments correctly

→ reauthorize when authentication is requested

→ monitor what happens after launch

The merchant's job is not to decide authentication in isolation.

It is to build a payment flow that can correctly respond to the regulatory, provider, acquirer, network, and issuer decisions surrounding each transaction.

That is the difference between an SCA integration that technically exists and one that actually supports compliant payments without creating avoidable checkout failures.

🙂 🙂 🙂 🙂 🙂

Below is the consolidated V2: it keeps the stronger operational thesis and SEO-relevant concepts from V1, while correcting legacy 3DS, exemption, geographic-scope, and responsibility assumptions to fit the V2 implementation brief.

SEO, EDITORIAL & VISUAL GUIDANCE — NOT PART OF THE ARTICLE

Yes. The strongest positioning is to make this page the cluster’s merchant implementation page, not another general explanation of SCA. The brief is specifically practical/commercial: readers already understand SCA at a basic level and want to know what they must actually build, configure, test, and monitor.

SEO recommendations

Element

Recommendation

SCA Requirements for Merchants: 3DS, Exemptions & Testing

H1

SCA Requirements for Merchants: What You Need to Implement

Slug

/solve/compliance-slows-launches/authentication-and-payment-regulation/sca-requirements-for-merchants/

SCA requirements for merchants

Secondary terms

SCA compliance requirements, merchant SCA requirements, Strong Customer Authentication requirements, PSD2 merchant requirements

Meta description

Learn what merchants need to implement for SCA, including EMV 3DS, exemptions, recurring payments, soft declines, payment data, responsibilities, and launch testing.

Search intent

Practical implementation / commercial informational

Core differentiator

Merchant implementation architecture rather than another definition of SCA

The proposed SEO title keeps the exact commercial concept while surfacing three subjects likely to matter to someone actually implementing SCA. Google recommends concise, descriptive titles rather than repeated keyword variants.

I would not try to force all four secondary keywords into headings. Google’s current Search Essentials emphasize using the words readers would use in prominent locations while still prioritizing helpful, people-first content.

Add a very compact direct-answer block

Immediately below the introduction:

What do merchants need to implement for SCA?

Merchants generally need an SCA-capable checkout that supports current EMV 3-D Secure, passes accurate transaction context, handles supported exemption requests, distinguishes customer-initiated from recurring and merchant-initiated payments, responds when an issuer requires authentication, and correctly retries authorization after successful authentication where appropriate. The merchant supports the flow; the merchant does not make every authentication decision itself.

This is probably the strongest SEO improvement available because it directly satisfies the intent before the reader reaches the detailed sections.

Google says snippets are primarily generated from on-page content, so a clean, self-contained answer block has more value than obsessing over the meta description alone.

The page needs one original framework

I would name it:

The Merchant SCA Implementation Stack

Layer

What the merchant needs to establish

•Scope

Could this transaction be subject to SCA?

•Classification

Customer initiated, recurring, MIT, or another payment type?

•Context

Is the right payment/customer/device information being sent?

•Authentication

Can the checkout support current EMV 3DS?

•Exemption

Is an exemption supported and appropriate to request?

•Issuer response

Did the issuer accept the path or request authentication?

•Recovery

Can authentication-required payments be recovered correctly?

•Authorization

What happened after authentication?

•Monitoring

Are authentication and authorization outcomes measured separately?

•Maintenance

Can changing rules/provider configurations be updated without rebuilding checkout?

The important caption:

SCA compliance is a transaction flow, not a checkbox attached to 3D Secure.

This gives the page a memorable piece of original editorial architecture, which is more valuable than simply reproducing regulatory descriptions. Google's people-first guidance specifically asks whether content contributes original analysis and substantial value beyond available source material.

Visual asset 1 — SCA transaction decision flow

This should be the primary infographic.

Transaction begins

↓

Could SCA apply?

↓

Classify transaction

Customer initiated / recurring / genuine MIT / other

↓

Send transaction context

↓

Exemption or other non-challenge route available?

↙ Yes

Request through supported PSP/acquirer flow

↘ No

Proceed through authentication as required

↓

Issuer decision

↙ No customer challenge required

Continue

↘ Authentication required

EMV 3DS challenge / authentication

↓

Authentication result

↓

Authorization

↓

Final payment outcome

Caption:

The merchant prepares and responds to the authentication flow; the issuer still participates in deciding whether authentication is required and whether the payment is authorized.

That directly visualizes the brief's key distinction that the merchant alone does not determine authentication.

Visual asset 2 — SCA versus 3D Secure

This deserves a very simple two-column graphic.

SCA

EMV 3-D Secure

Regulatory authentication requirement

Technical card-authentication protocol

Defines required authentication characteristics

Carries authentication information

Includes exemptions/scope rules

Supports frictionless and challenge flows

Applies according to regulatory circumstances

Used for relevant card-payment authentication

The “what”

One major part of the “how”

Then one line:

Implementing 3DS is not the same thing as understanding every SCA requirement.

This is highly search-friendly because “Is 3D Secure required for SCA?” is an obvious secondary intent embedded in the brief.

Visual asset 3 — Scope, exemption and out-of-scope are not interchangeable

This distinction is important enough to visualize because many SCA pages blur it.

Potentially in scope + SCA

Exemption requested

Outside SCA scope / different treatment

Regulatory starting point

SCA applies unless another treatment is available

Transaction is within the framework but an exemption may be applied/requested

Transaction is not treated as requiring SCA for a different reason

Merchant assumption

Authentication path must be supported

No guarantee of frictionless processing

Do not call it an “exemption” unless it actually is one

Can issuer still affect outcome?

Yes

Yes

Payment authorization still remains separate

Do not populate this with dozens of transaction examples. That would duplicate SCA Exemptions and Merchant-Initiated Transactions and SCA.

The important editorial point is simply:

“No challenge expected” does not tell you why no challenge is expected.

That is an excellent distinction for sophisticated payment teams.

Visual asset 4 — Merchant vs PSP/acquirer vs issuer

This might be the most commercially useful diagram.

Merchant

PSP / Acquirer

Issuer

Build checkout

Orchestrate supported auth flow

Authenticate cardholder

Pass accurate context

Carry exemption indicators

Assess authentication requirement

Classify transaction

Apply provider/acquirer capabilities

Accept/reject relevant exemption path

Preserve recurring/MIT setup

Route EMV 3DS

Challenge when appropriate

Handle customer return

Return auth status

Produce auth result

Recover soft declines

Support retry/re-auth flow

Decide authorization

Monitor outcomes

Provide reporting/data

—

Beneath it:

The merchant owns implementation quality—not unilateral control over the SCA decision.

This should probably appear before the detailed exemption section because it prevents the reader from misinterpreting everything that follows.

Visual asset 5 — Exemption request is not exemption approval

A miniature flow would help:

Merchant / PSP identifies possible exemption

→ Request exemption

→ Issuer evaluates transaction

Then split:

Exemption accepted

→ authorization proceeds

or:

Authentication required

→ EMV 3DS

→ authentication

→ authorization

Caption:

Build both paths. An exemption request should never be treated as a guaranteed frictionless payment.

That is more useful than listing exemption thresholds in another graphic.

Visual asset 6 — Recurring versus stored credential versus MIT

This is an area where merchants make expensive implementation mistakes.

Customer-initiated stored card

Customer returns

→ chooses saved card

→ clicks Pay

Customer is present and initiating payment

Recurring series

Customer establishes agreement

→ initial setup/payment appropriately authenticated

→ subsequent qualifying recurring payments

Genuine MIT

Customer establishes mandate/agreement

→ later merchant initiates payment

→ customer not actively initiating that transaction

Then:

Stored credential describes the credential. It does not, by itself, describe who initiated the transaction.

That is an excellent callout and should be preserved almost verbatim.

Visual asset 7 — SCA soft-decline recovery flow

This should sit directly beside the authentication-failure section:

Authorization without completed SCA

↓

Issuer: authentication required

↓

Customer still available?

↓

Start EMV 3DS

↓

Authentication successful?

No → payment not completed / alternative route

Yes → reauthorize with authentication result

↓

Issuer authorization

Caption:

Authentication-required declines need a recovery flow; blindly retrying the original authorization does not solve the problem.

This is likely one of the most useful diagrams for developers and payment teams.

Visual asset 8 — Authentication success is not authorization success

A tiny funnel:

100 payment attempts

↓

Authentication initiated

↓

Authentication completed

↓

Authorization attempted

↓

Issuer approved

Do not put invented numbers in it.

Use the stages only.

Then:

Measure authentication and authorization separately.

This is important because otherwise merchants may blame 3DS for declines that actually happen after successful authentication.

Turn the implementation checklist into a downloadable-style reader asset

The existing checklist is strong. Visually position it as:

Pre-Launch SCA Readiness Checklist

Group it into six cards:

Scope

Authentication

Data

Exemptions

Recurring & MIT

Failure Recovery & Monitoring

This makes the article much more bookmarkable.

Google's people-first guidance explicitly asks whether content is useful enough that readers might bookmark or recommend it; a genuinely operational checklist supports that objective.

Editorial recommendation: separate “regulatory requirement” from “merchant implementation”

Consider adding small labels when necessary:

REGULATORY REQUIREMENT

What PSD2/UK SCA rules require.

PAYMENT IMPLEMENTATION

What a merchant/PSP architecture commonly needs in order to satisfy the requirement.

NETWORK / PROVIDER BEHAVIOR

What may depend on card-scheme or PSP mechanics.

MERCHANT BEST PRACTICE

A recommendation rather than a legal obligation.

This would materially improve credibility because the brief specifically asks you to distinguish regulation, card-network rules, technical standards, industry practice, and recommendations.

It is especially valuable around:

•EMV 3DS;

•soft declines;

•exemption indicators;

•MIT flags;

•retry handling;

•monitoring metrics.

Editorial recommendation: keep current thresholds out of the core visual hierarchy

The current article appropriately mentions current EEA and UK low-value thresholds.

But I would not make those numbers the headline feature of the page.

Why?

Because this page owns implementation, while Low-Value Transaction Exemptions should own the detailed threshold discussion.

Thresholds also age faster than the architectural principles.

Use a compact note such as:

Current exemption values differ between the EEA and UK and may change. Treat thresholds as configuration, not permanent application logic.

That has much stronger long-term editorial value.

Create a “hard-code vs configure” box

This could be excellent for developers.

Do not hard-code as permanent assumptions

Keep configurable / provider-driven

exemption thresholds

jurisdictional exemption rules

TRA assumptions

PSP/acquirer capability

SCA geography assumptions

market/provider routing

supported EMV 3DS versions

provider-supported versions

recurring classifications

transaction metadata/mapping

retry rules

issuer/provider response handling

Caption:

Build SCA as configurable payment policy rather than regulatory logic scattered through checkout code.

This supports the “compliance slows launches” pillar exceptionally well because it explains how architecture can reduce future rework.

Internal-link architecture

The brief provides an unusually clean cluster.

Current section

Destination

Suggested anchor

Initial regulatory explanation

Strong Customer Authentication Explained

how Strong Customer Authentication works

3DS section

3D Secure Compliance

implementing EMV 3-D Secure for SCA

Exemptions

SCA Exemptions

which SCA exemptions may be available

Low-value example

Low-Value Transaction Exemptions

how the low-value exemption works

TRA example

Transaction Risk Analysis Exemptions

how TRA exemptions are determined

Recurring section

Recurring Payments and SCA

how SCA applies to recurring payment series

MIT discussion

Merchant-Initiated Transactions and SCA

how genuine merchant-initiated transactions are treated

Regulatory-maintenance section

Authentication Requirements by Country

how authentication requirements differ by market

Use concise, descriptive anchors. Google explicitly recommends anchor text that makes the destination understandable to readers and search engines.

Do not add a generic FAQ purely for SEO

The brief is right to discourage manufactured FAQ sections.

Instead, make existing H2s directly answer high-intent questions such as:

When do SCA requirements apply to merchants?

Does a merchant need to implement 3D Secure?

What data does a merchant need to send for SCA?

Can a merchant request an SCA exemption?

How should merchants handle SCA soft declines?

How does SCA work for recurring payments?

Who decides whether authentication is required?

What should merchants test before launch?

Those questions align naturally with the page’s search intent instead of adding duplicate answers at the bottom.

Structured-data recommendation

Use Article structured data, plus BreadcrumbList if that is part of the site's normal architecture.

For the Article data, use genuine:

•headline;

•author;

•reviewer if your system supports/visibly presents one;

•datePublished;

•dateModified;

•representative image.

Google recommends adding applicable Article properties and validating structured data before deployment.

For this particular article, I would visibly display:

Regulatory review: August 2026

Coverage: EEA and UK merchant implementation

Status: General informational guidance, not individualized legal advice

Only change the regulatory review date after a substantive recheck.

Image SEO recommendations

For the original diagrams:

•use actual HTML image elements rather than CSS-only backgrounds;

•use short descriptive filenames;

•place visuals beside the section they explain;

•provide genuinely descriptive alt text;

•keep the same information available in HTML prose/tables rather than embedding essential regulatory content only inside graphics.

Google says filenames, nearby text, captions, and especially alt text help it understand images, while keyword stuffing in alt attributes should be avoided.

Example filename:

sca-merchant-implementation-flow.svg

Example alt text:

Merchant SCA implementation flow showing transaction classification, exemption handling, issuer authentication decisions, EMV 3D Secure, authorization and monitoring.

Best hero visual

Avoid the usual:

shield + fingerprint + credit card

It says “security,” but not what this page teaches.

I would instead use:

Headline

SCA is a payment flow—not a checkbox

Hero flow

Merchant checkout

→ Transaction context

→ PSP / acquirer

→ SCA / exemption path

→ Issuer decision

→ EMV 3DS if required

→ Authorization

Underneath:

The merchant implements the flow. The issuer still decides authentication and payment outcomes.

That summarizes the entire page before the reader starts scrolling.

Highest-priority editorial additions

If you implement only five enhancements, I would choose:

•Merchant SCA Implementation Stack immediately after the introduction.

•SCA vs 3D Secure comparison beside the 3DS section.

•Merchant / PSP-acquirer / issuer responsibility map before exemptions.

•Soft-decline recovery flow beside authentication failures.

•Pre-Launch SCA Readiness Checklist as a visually distinct end-of-page asset.

I would also protect three sentences very deliberately through future edits:

SCA compliance is a transaction flow, not a checkbox attached to 3D Secure.

Stored credential describes the credential; it does not tell you who initiated the transaction.

The merchant's job is to support the authentication decision correctly—not to make every authentication decision itself.

Those three ideas give the article substantially more SEO and editorial value than simply being another summary of PSD2 authentication rules.

V1

SCA Requirements for Merchants

Strong Customer Authentication isn't a feature a merchant builds once and forgets about. It's a regulatory requirement under PSD2 that has to be actively maintained — the authentication mechanism itself, the exemption logic sitting on top of it, and the monitoring needed to keep those exemptions valid all have to keep working together, on an ongoing basis, or payments start failing that shouldn't.

This covers general patterns in how SCA compliance typically works for merchants operating in the EEA and UK. It isn't legal advice — specific obligations depend on transaction type, business model, and evolving regulation, and should be confirmed with qualified legal and compliance counsel.

What SCA actually requires

SCA requires authentication using at least two independent factors, drawn from three categories: something the customer knows (a PIN or password), something they have (a phone or hardware token), and something they are (a fingerprint or facial biometric). This applies to remote, electronic payments — card-not-present transactions, in practice — where both the customer's issuing bank and the merchant's acquirer are located within the EEA or UK. Transactions falling outside that two-leg geographic test (for example, a customer whose card was issued outside the EEA) generally fall outside SCA's direct scope, even if the merchant itself is based within it. (See PSD2 Explained and Strong Customer Authentication Explained for the fuller regulatory background.)

3DS2 is the mechanism, not the regulation

EMV 3-D Secure 2 (3DS2) is the primary technical protocol merchants actually implement to satisfy SCA on card transactions — it's the "how," where SCA is the "what's required." Where an issuing bank doesn't yet support 3DS2, transactions fall back to the older 3DS1 protocol, which relies on a redirect to a separate authentication window and is generally considered a worse checkout experience with lower completion rates. Merchants integrating for SCA compliance should be building for 3DS2 as the primary path, with 3DS1 as a fallback rather than the default, since 3DS1's redirect-heavy flow is a meaningful source of the exact checkout abandonment covered in Why 3D Secure Causes Checkout Abandonment.

Exemptions exist, but they have to be actively earned and monitored

SCA allows for exemptions that let qualifying transactions skip the full authentication challenge, which is the difference between a frictionless checkout and one that interrupts every purchase. The main categories:

•Low-value transaction exemptions — transactions below a defined value threshold can qualify, subject to cumulative limits on how many low-value transactions a card can process before a full authentication is required again

•Transaction Risk Analysis (TRA) exemptions — allowing a PSP or acquirer with a low enough fraud rate to skip authentication on qualifying transactions, with the specific value thresholds available scaling based on how low that fraud rate actually is

•Recurring transaction and merchant-initiated transaction (MIT) exemptions — once a customer has completed one SCA-authenticated setup transaction, subsequent recurring or merchant-initiated charges on that same arrangement generally don't require repeated authentication

•Trusted beneficiary ("whitelisting") exemptions — a customer can mark a specific merchant as trusted through their own bank, exempting future transactions with that merchant from repeated challenges

Each of these is covered in more depth on its own page — SCA Exemptions, Low-Value Transaction Exemptions, Transaction Risk Analysis Exemptions, and Recurring Payments and SCA — but the operational point that applies across all of them is the same: an exemption isn't a permanent switch a merchant flips once. It's a request made per transaction, evaluated against thresholds that have to be actively tracked.

The operational catch most merchants underestimate

Requesting an exemption requires knowing, in real time, whether the transaction actually still qualifies — how many low-value transactions have already gone through on that card, what a provider's current fraud rate actually is for TRA purposes, whether a given recurring arrangement's original setup transaction was properly authenticated in the first place. A merchant that doesn't actively track this doesn't get a graceful fallback to a slightly slower but still-successful transaction — a wrongly-requested exemption typically results in a rejected authorization, meaning the payment fails outright rather than simply taking the longer authenticated path. Getting the exemption logic wrong is a direct cause of failed payments, not just a missed convenience.

The rules have moved before, and are moving again

SCA's own enforcement timeline is a useful reminder that "the current deadline" isn't necessarily final. The original EU enforcement date in 2019 was extended by regulators to the end of 2020, and the UK ran its own separate timeline, reaching full enforcement only by March 2022 — years after SCA was first introduced. Merchants who treat today's specific rules and thresholds as permanent are working from the same assumption that turned out to be wrong twice already in SCA's own history.

The EU is currently working through a further evolution: a proposed Payment Services Regulation (PSR) alongside a revised Payment Services Directive (PSD3), still progressing through the EU legislative process as of this writing, with no fully settled implementation timeline yet confirmed. The direction of the proposed changes is worth tracking even before the final rules land: refinements to the TRA exemption framework with more granular fraud-rate thresholds, clarified definitions around scope, and strengthened requirements specifically for open banking authentication flows. What isn't expected to change is the core mechanism — 3DS2 remains the expected primary path for meeting SCA on card transactions under the proposed framework, not something being replaced. (See SCA Exemptions Explained for how this may specifically affect exemption logic once finalized.)

What this means practically for a merchant's authentication stack

•Build for 3DS2 as the default, with 3DS1 handled as a genuine fallback rather than treated as equivalent

•Track exemption eligibility in real time, not as a static configuration — cumulative low-value transaction counts, current TRA fraud rate standing, and MIT setup-transaction history all need active monitoring

•Avoid blanket full-challenge authentication on every transaction regardless of eligibility, since this trades unnecessary friction and abandonment for a compliance margin that a properly monitored exemption framework wouldn't have required in the first place — see How to Reduce Unnecessary 3DS Challenges

•Monitor the regulatory timeline directly, rather than assuming current exemption thresholds and definitions will hold indefinitely, given SCA's own history of shifting deadlines and the PSD3/PSR changes currently in progress

Title

SCA Requirements for Merchants

Url

/solve/compliance-slows-launches/authentication-and-payment-regulation/sca-requirements-for-merchants/

Pillar

Compliance Slows Launches

Cluster

E — Authentication and payment regulation

SCA isn't a checkbox you implement once. It's an ongoing compliance obligation with exemptions that have to be actively monitored — get the tracking wrong and payments start failing.

Status

draft — regulatory specifics checked against current sources (July 2026); PSD3/PSR timeline still progressing through the EU legislative process as of this writing and should be reconfirmed before publishing. This is general informational content, not legal advice.