A checkout may work perfectly for domestic buyers yet fail when a card issued in the UK or European Economic Area is used. The authorization may be declined not because the card lacks funds, but because the issuer expects Strong Customer Authentication before it will approve the payment.

That distinction matters for ecommerce merchants. Treating every SCA-related authorization decline as a lost sale can unnecessarily reduce conversion, while repeatedly submitting the same unauthenticated transaction can create more declines without solving the underlying problem.

Strong Customer Authentication, commonly shortened to SCA, is a regulatory authentication requirement designed to reduce payment fraud. Under the EU framework, the current PSD2 definition describes SCA as authentication based on two or more independent elements categorized as knowledge, possession, and inherence.

For ecommerce card payments, EMV 3-D Secure—usually called 3DS or 3DS2—is the principal card-industry protocol used to exchange authentication information between merchants, payment providers, card networks, and issuers. 

A properly implemented 3DS flow does not necessarily mean forcing every shopper through a visible challenge. EMVCo describes both frictionless and challenge flows, with the issuer making the authentication decision based on available transaction information and risk.

A practical Strong Customer Authentication UK and EU strategy therefore needs more than an “enable 3DS” switch. Merchants need to determine scope, understand exemptions and out-of-scope transactions, correctly classify recurring and merchant-initiated transactions, recognize SCA soft declines, retry with authentication when required, and reconcile the final payment state.

Most importantly, authentication and authorization are separate events. Authentication helps establish that the payment interaction satisfies applicable security requirements; authorization is the issuer’s financial decision about whether the transaction should actually proceed.

Merchants selling internationally should also avoid assuming that UK SCA rules and EU SCA rules remain perfectly interchangeable. The EU framework continues to rely on PSD2 and its applicable regulatory technical standards while its payment-services legislation is being revised, whereas the UK applies its own Payment Services Regulations and FCA technical standards.

For a broader view of how issuer, acquirer, gateway, authorization, settlement, and reconciliation fit together in international commerce, this guide to cross-border payment processing provides useful supporting context.

What Is Strong Customer Authentication?

Strong Customer Authentication is an authentication standard intended to make electronic payments harder to misuse when payment credentials are stolen or compromised. In the EU, PSD2 defines SCA using at least two independent elements drawn from three categories: knowledge, possession, and inherence.

Those categories are generally understood as:

• Knowledge: something only the user knows.
• Possession: something only the user possesses.
• Inherence: something the user is.

The elements must be independent so that compromise of one does not undermine the reliability of the other. The regulatory technical standards also require the authentication process to generate an authentication code and establish security requirements around how those elements and codes are used.

The EU’s Regulatory Technical Standards for Strong Customer Authentication set out the authentication requirements and the conditions under which payment service providers may apply defined SCA exemptions. These standards are an important primary reference for merchants and payment providers handling in-scope EEA electronic payments.

The purpose is not simply to add another password screen. Modern SCA payments are designed to combine regulatory authentication with risk-sensitive payment flows, particularly for ecommerce authentication where issuers can receive richer contextual data than was common in older online card systems.

The UK’s framework has a similar foundation but is now legally distinct. The FCA states that its SCA requirements arise from the Payment Services Regulations and associated technical standards and apply when a payer initiates an electronic payment transaction, accesses an account online, or takes certain remote actions that may create fraud risk unless an applicable exemption applies.

SCA compliance therefore should not be reduced to a geographic checkout rule such as “challenge European shoppers.” Whether authentication is necessary depends on the regulatory scope, transaction type, participants, available exemption or exception, issuer decision, and payment-provider implementation.

Where SCA Applies and Why Geography Matters

SCA scope depends on more than the shopper’s physical location. For card payments, the location and regulatory status of payment service providers—particularly the issuer and acquirer—can matter, along with who initiated the transaction and whether the payment is electronic.

Under the EU framework, SCA generally applies when a payer initiates an electronic payment transaction within the relevant PSD2 scope. The European Banking Authority has also addressed “one-leg” situations where one payment service provider is within the Union and another is outside it, illustrating why a simple “European customer” test is inadequate.

A shopper could be physically visiting the United States while using an EEA-issued card. Conversely, a shopper located in France could use a card issued outside the EEA. Those situations do not automatically have identical regulatory consequences.

Merchants should let their PSP, acquirer, gateway, and network-certified payment stack determine applicable transaction routing rather than inventing scope decisions from IP geolocation alone.

Sales Into the UK vs. EU/EEA

The UK retained an SCA regime after leaving the EU, but its rules now sit within the UK’s own Payment Services Regulations and FCA technical standards. The FCA maintains specific provisions for exemptions such as low-value payments, recurring transactions, trusted beneficiaries, secure corporate processes, and transaction risk analysis.

The Financial Conduct Authority’s Strong Customer Authentication guidance explains that UK SCA requirements arise from the Payment Services Regulations and related technical standards and apply to activities including payer-initiated electronic payment transactions unless an applicable exemption is available.

This matters because some numerical thresholds are not identical. For example, the EU regulatory technical standard’s remote low-value exemption uses a €30 individual transaction threshold, together with cumulative/count conditions, while the FCA’s UK technical standard uses £25 and a cumulative threshold of £85, again subject to the applicable conditions.

Merchants should therefore avoid maintaining one hard-coded “European SCA threshold” for every market.

Cross-border sellers based outside Europe may still encounter SCA because their customers use UK- or EEA-issued cards and the acquiring or issuing arrangement brings the transaction into relevant regulatory or card-network processes. 

Even where a transaction is technically outside a particular regulatory requirement, an issuer may still use 3DS, risk controls, or other authentication mechanisms.

SCA Scope Decision Table

Scenario	SCA Potentially Applies?	Why
EEA-issued card + EEA acquirer	Yes	A payer-initiated electronic card transaction is generally within EU SCA scope unless an exemption or other applicable treatment applies.
UK-issued card + UK acquirer	Yes	UK Payment Services Regulations and FCA SCA standards generally apply to qualifying payer-initiated electronic transactions.
EEA-issued card + non-EEA acquirer	Scope is more complex	One-leg treatment depends on which portions of the transaction fall within the regulated area; network and issuer authentication behavior can still matter.
Merchant-initiated recurring charge	Often treated differently	A genuine payee/merchant-initiated transaction established under a valid mandate is not equivalent to a new payer-initiated ecommerce purchase.
Genuine MOTO transaction	Generally treated outside ecommerce SCA requirements	A true mail-order/telephone-order transaction is not the same as a payer initiating an electronic ecommerce transaction. Classification must reflect reality.
Anonymous payment instrument	May fall outside SCA obligation	Relevant regulatory guidance recognizes different treatment where payment instruments are genuinely anonymous, subject to the instrument and legal framework.

The EBA specifically identifies merchant-initiated transactions and certain one-leg transactions separately when discussing card transactions to which SCA is not applied.

The FCA’s technical-standard guidance likewise notes that payments made using anonymous instruments may not be subject to the SCA obligation while also cautioning that the position changes if the anonymity is lifted.

How 3-D Secure 2 Supports SCA

EMV 3-D Secure provides a structured way for ecommerce participants to exchange authentication information. The protocol brings together the merchant or 3DS Requestor, a 3DS Server, the card network’s Directory Server, the issuer’s Access Control Server, and the cardholder interaction when one is necessary.

The merchant typically does not communicate directly with every issuer’s authentication system. Instead, its gateway, PSP, or 3DS provider handles much of the protocol orchestration.

EMVCo’s documentation describes 3DS as an additional security layer for online transactions and identifies two principal flows: frictionless and challenge.

Frictionless 3DS vs. Challenge Flow

In a frictionless flow, the issuer’s Access Control Server receives transaction and contextual information and determines that active cardholder interaction is unnecessary for that authentication. The shopper may not see an authentication screen at all.

That does not mean authentication was “skipped,” nor does it automatically mean an SCA exemption was used. Frictionless authentication and an SCA exemption are different concepts.

In a challenge flow, the issuer requires additional cardholder interaction. Depending on the issuer and device, that could involve an issuer app, biometric interaction, a one-time credential, or another supported method.

EMVCo explains that an issuer can trigger the challenge flow when it determines that additional confirmation is appropriate, while low-risk transactions may be authenticated frictionlessly.

The merchant can provide information and express certain preferences, but it should not assume it controls the final issuer authentication path.

3DS2 Data Quality Matters

Issuers make better risk decisions when authentication requests contain accurate information. Depending on the integration and protocol version, useful contextual information can include customer, account, device, browser, transaction, billing, shipping, and merchant details.

EMVCo specifically recommends populating accessible device information because richer information can support issuer risk assessment and may improve authentication outcomes.

That does not mean merchants should invent data or collect unnecessary personal information. It means required and supported fields should be accurate, internally consistent, and supplied according to the gateway and EMV 3DS implementation.

A mature checkout might provide:

• Correct billing and shipping information.
• Consistent merchant identity.
• Customer account age where supported.
• Relevant prior transaction history.
• Device and browser information available through the integration.
• Accurate contact details.
• Recurring-payment information when the transaction genuinely belongs to a recurring series.

Authentication vs. Authorization

Authentication asks whether the payment interaction satisfies identity and security requirements. Authorization asks whether the issuer will approve the financial transaction.

Those decisions may happen close together, but they should never be treated as the same event.

A payment can successfully complete 3DS authentication and still fail authorization because:

• The account has insufficient available funds.
• The card is restricted for that transaction.
• The issuer’s fraud controls reject the purchase.
• The card has expired or been replaced.
• The transaction exceeds issuer limits.
• Another issuer-specific risk rule applies.

Conversely, an initial authorization submitted without required authentication may be declined even though the account is otherwise valid. That is the scenario in which an SCA soft-decline recovery flow becomes particularly valuable.

A merchant’s order system should preserve the difference:

Authentication success ≠ authorization approval ≠ capture ≠ settlement

This is particularly important in API-driven ecommerce. A “3DS successful” callback should not automatically mark the order paid. Likewise, a customer’s browser arriving at a success page should not automatically trigger fulfillment.

Merchants reviewing their overall checkout controls can also use this guide to online payment security best practices, which covers gateway security, tokenization, fraud controls, and secure online payment architecture.

SCA Exemptions and Out-of-Scope Transactions

SCA exemptions ecommerce teams use are not universal permission slips to bypass authentication. An exemption operates under defined regulatory conditions, and an issuer can still require SCA when it determines authentication is necessary.

The essential rule is:

An SCA exemption is generally requested, not guaranteed. The issuer may reject the exemption and require authentication.

Merchants should also distinguish an exemption from an out-of-scope transaction. An exemption concerns a transaction that would otherwise fall within the SCA regime but may proceed without SCA under defined criteria. 

An out-of-scope transaction falls outside the relevant SCA requirement for another reason, such as a genuine merchant-initiated payment depending on the legal and transactional facts.

Low-Value Payment Exemption

Under the EU RTS, a payer-initiated remote electronic payment may qualify for the low-value exemption when the individual amount does not exceed €30 and the regulatory cumulative/count conditions have not been exceeded. 

The RTS refers to a cumulative amount of previous remote electronic payments since the last SCA not exceeding €100, or no more than five previous consecutive qualifying remote payments.

Under the current FCA technical standard, the UK low-value figures are different: an individual remote electronic transaction must not exceed £25, with a cumulative threshold of £85 or the corresponding count condition.

These are payment-service-provider exemption rules, not a merchant guarantee. A merchant should not locally count five transactions and assume the sixth must be challenged; issuer and PSP state can affect the actual result.

Transaction Risk Analysis Exemption

The transaction risk analysis exemption, commonly called TRA, allows a qualifying payment service provider to avoid SCA for certain transactions its real-time transaction monitoring identifies as low risk, provided the regulatory fraud-rate and transaction-value requirements are satisfied.

Under the EU RTS, the reference thresholds for remote electronic card payments are €100 at a 0.13% reference fraud rate, €250 at 0.06%, and €500 at 0.01%. These are not merchant fraud-score cutoffs; they apply to qualifying payment service providers using the TRA exemption under the regulatory methodology.

The UK framework maintains its own sterling threshold structure. Current FCA reporting materials identify TRA bands of £85, £220, and £440 and require relevant payment service providers to monitor and report compliance with the applicable reference fraud rates.

A merchant therefore cannot declare “this order looks safe, so TRA applies.” Availability depends on the acquirer’s or relevant PSP’s eligibility, risk assessment, routing, transaction value, monitored fraud performance, and issuer acceptance.

Trusted Beneficiary Exemption

The trusted-beneficiary concept allows a payer to maintain a trusted payee list through the payer’s payment service provider. Under the EU and UK-style frameworks, SCA is required when that trusted-beneficiary list is created or amended, while subsequent payments to a beneficiary already on the list may qualify for exemption treatment.

The critical point for merchants is that the issuer or account-servicing PSP controls the trust-list mechanism. A merchant cannot simply set a request field saying “customer trusts us” and transform itself into a trusted beneficiary.

EMV 3DS also contains trust-list functionality that can help exchange information relevant to issuer-managed trust-list flows. EMVCo notes that consistent merchant identification is important because issuer/ACS systems may use merchant information to manage those relationships.

Recurring Payments and Merchant-Initiated Transactions

Recurring transaction SCA rules require careful classification. Under the EU RTS, SCA is required when a payer creates, amends, or first initiates a series of recurring transactions with the same amount and same payee; subsequent qualifying payments in that regulatory recurring series may be processed without repeated SCA. The UK technical standard contains corresponding recurring-transaction provisions.

However, modern subscription billing frequently also relies on merchant-initiated transaction, or MIT, concepts. A genuine MIT is initiated by the merchant under a mandate previously established with the customer rather than being a new customer-initiated ecommerce purchase.

The EBA has clarified that when a mandate for future payee-initiated transactions is established remotely, SCA may be required when that mandate is established.

This is why saying “subscriptions are exempt” is misleading.

MOTO, Corporate Payments, and Anonymous Instruments

Genuine mail-order and telephone-order payments may be treated differently because they are not electronically initiated by the payer in the same way as ecommerce payments. But merely manually keying card details does not automatically turn an online payment into MOTO.

The EBA has specifically stated that manually keyed card transactions do not automatically qualify for MOTO treatment and can still require SCA where they remain payer-initiated electronic transactions.

Secure corporate processes are another limited category. The EU and UK frameworks permit exemptions for certain dedicated payment processes or protocols available only to non-consumer payers when the relevant authority is satisfied that they provide equivalent security. 

This does not mean every commercial, purchasing, corporate, or business card automatically receives an SCA exemption.

Anonymous payment instruments may receive different SCA treatment where they genuinely satisfy the legal conditions. Merchants should rely on issuer, network, and PSP implementation rather than trying to infer eligibility from the card product themselves.

SCA Exemption Comparison Table

Exemption or Treatment	Typical Use	Merchant Can Request?	Issuer Can Still Require Authentication?
Low-value	Qualifying small remote payment within regulatory counters	Often through PSP/acquirer support	Yes
TRA	PSP-determined low-risk transaction within eligible fraud/value thresholds	Often through eligible acquirer/PSP routing	Yes
Trusted beneficiary	Payer has established merchant/payee on issuer-managed trust list	Merchant can support the flow but cannot self-designate	Yes, depending on conditions/risk
Recurring series	Qualifying subsequent recurring transaction following proper setup	Correct recurring data must be supplied	Yes where conditions are not met or risk requires it
Merchant-initiated transaction	Genuine merchant-initiated payment based on prior mandate	Correct MIT/stored-credential indicators are required	Treatment depends on transaction facts and network/regulatory rules
Secure corporate process	Approved dedicated non-consumer payment process	Only through eligible approved arrangements	Not a blanket business-card exemption
Genuine MOTO/out-of-scope treatment	Mail or telephone order not electronically initiated by payer	Correct classification is required	Not an exemption request in the same sense

What Is an SCA Soft Decline?

An SCA soft decline occurs when an authorization is rejected in a manner indicating that additional authentication may enable the transaction to succeed. In practice, an issuer may reject an authorization submitted without SCA after an exemption was unavailable, refused, incorrectly indicated, or otherwise insufficient for the issuer’s requirements.

“Soft decline” is an operational payments term, not a guarantee that every processor exposes the same decline code.

A gateway may return a specific SCA-required field. Another might map network information into a generic decline category. A third may automatically launch 3DS and hide much of the recovery sequence behind its API.

That is why merchants must use their processor’s current decline-code and SCA documentation rather than building retry logic around a copied list of numeric codes.

Soft Decline vs. Hard Decline

Decline Type	Meaning	Recommended Response
SCA/authentication soft decline	Issuer indicates authentication is required or missing	Start appropriate 3DS/SCA flow and retry authorization correctly
Temporary issuer decline	Potentially transient issuer condition	Follow processor-specific retry guidance; do not assume SCA is the cause
Insufficient funds	Issuer cannot approve available amount	Ask for another payment method or customer action; avoid aggressive retries
Lost/stolen card	Serious issuer/card status decline	Do not automatically retry
Invalid/closed card	Credential or account cannot be used	Request another valid payment method

A soft decline should not be interpreted as “try again immediately.” It means the application should first determine why the authorization failed.

Why SCA Soft Declines Happen

Common causes include:

• The merchant requested an exemption but the issuer required authentication.
• No authentication was attempted on an in-scope transaction.
• The authorization did not carry the required authentication result.
• Transaction indicators were incorrect or incomplete.
• The issuer evaluated the transaction as higher risk.
• A recurring or MIT transaction was incorrectly classified.
• An implementation did not correctly link the authentication and authorization.
• The PSP exposed an issuer/network response indicating SCA was required.

Soft declines are therefore useful signals. A well-designed payment system interprets them as a state transition rather than immediately displaying “payment failed.”

Recovering Failed Authorizations After an SCA Soft Decline

The objective of soft decline payment recovery is not to keep retrying until an issuer gives in. The correct strategy is to add the authentication the issuer requested and then make a properly linked authorization attempt.

A practical workflow is:

1. Receive the authorization decline: Preserve the processor’s payment-attempt ID, network/issuer response, SCA indicator, and internal order state.
2. Classify the decline: Use the PSP’s documented decline category rather than guessing from the customer-facing message.
3. Determine whether authentication is required: If the response indicates SCA or 3DS is needed, move the payment into an authentication-required state.
4. Initiate 3DS authentication: Allow the issuer to perform either frictionless authentication or a challenge.
5. Receive the authentication outcome: Do not assume browser completion means success.
6. Retry authorization correctly: Include the authentication data and transaction linkage required by your provider.
7. Process the issuer’s new decision: The payment may now be approved or may still receive a legitimate financial decline.
8. Update the order state: Only mark the order paid after confirmed authorization/capture according to your business flow.
9. Prevent duplicate capture or fulfillment: Use idempotency and server-side reconciliation.

The recovery sequence can be represented as:

Authorization Attempt → SCA Soft Decline → 3DS Authentication → Authentication Result → Authorization Retry → Approved or Declined

This is the core of recovering failed authorizations SCA workflows.

Do Not Blindly Retry Soft Declines

Repeating the original unauthenticated authorization usually does not address an authentication requirement. It may simply generate another decline.

Repeated attempts can also complicate fraud analysis, customer messaging, reconciliation, and duplicate-payment prevention.

A better system limits retry behavior according to the reason for the decline. Authentication-required responses should invoke authentication; technical failures may use carefully controlled retry policies; permanent card-status declines generally should not be automatically resubmitted.

Retry Logic and Idempotency

Idempotency is essential whenever authorization or capture calls may be repeated. A network timeout can occur even after a payment provider has successfully processed the first request, so the merchant may not know whether resubmitting will create another payment.

An idempotency key or equivalent provider mechanism allows repeated requests associated with the same logical operation to resolve safely instead of generating multiple transactions.

A reasonable payment state machine could look like:

Created → Authentication Required → Authenticating → Authenticated → Authorization Pending → Authorized → Capture Pending → Captured

Failure states might include:

Authentication Failed → Authorization Declined → Canceled

Provider semantics vary, so the merchant’s local state should map carefully to the provider’s objects and events.

Browser Session Recovery, Webhooks, and Reconciliation

3DS challenge flows introduce a major ecommerce problem: the browser is unreliable as the sole source of payment truth.

The shopper might authenticate successfully and close the tab. A redirect might fail. A mobile app might switch to an issuer banking app and later return. The customer could lose connectivity after the issuer’s decision but before your page updates.

Therefore:

A return to a success URL is not proof that money was authorized or captured.

Use server-side payment status, authenticated provider API responses, and webhooks to establish final state.

Webhooks also are not infallible. If an expected webhook never reaches your server, a scheduled reconciliation process should query unresolved payment objects and repair the local order state.

A reliable model is:

Order → Authentication → Authorization → Capture → Processor Payment Object → Webhook/API Status → Local Order State

For payment systems generally, ecommerce merchants should select processing infrastructure that supports card-not-present controls, recurring billing, and reliable gateway integration. The overview of different types of merchant accounts explains how ecommerce and recurring-payment environments differ operationally from ordinary card-present processing.

Recurring Billing, Stored Credentials, and Merchant-Initiated Transactions

Subscriptions are one of the areas where SCA implementation errors are most common. A recurring charge may be genuinely merchant initiated, a regulatory recurring payment, or a new customer-initiated purchase made using a stored card. Those are not interchangeable.

A useful subscription lifecycle distinguishes:

Signup → Payment Credential Setup → Initial Customer-Initiated Payment/Authentication → Mandate Established → Subsequent Merchant-Initiated Billing → Renewal Failure Recovery

Initial Subscription Payment and Mandate

When a customer signs up and actively initiates a card payment, that initial transaction is generally a customer-initiated payment. If it falls within SCA scope and no applicable exemption is accepted, authentication may be required.

If the relationship will support later merchant-initiated charges, the merchant also needs appropriate consent or mandate arrangements and correct stored-credential setup.

The EBA has clarified in relevant MIT scenarios that where a mandate is provided remotely, SCA may be required when the mandate is established.

A good subscription implementation therefore records the relationship rather than merely saving a token.

Relevant data may include:

• Customer consent to recurring or future charges.
• Billing frequency or method for determining charges.
• Appropriate customer disclosures.
• Provider/network stored-credential indicators.
• Original transaction or credential-establishment references.
• Cancellation and payment-update status.

Subsequent Recurring and MIT Charges

A properly established subsequent merchant-initiated transaction occurs without the customer actively initiating that specific payment. Examples may include an agreed subscription renewal or another contractually permitted merchant-initiated charge.

Correct network indicators and transaction linkage matter. EMVCo’s recurring-transaction guidance notes that 3DS servers can provide recurring-transaction data and identifiers associated with prior authentication to help the issuer evaluate related transactions.

Card-network rules also govern stored credentials and merchant-initiated transactions, so merchants should implement the indicators specified by their acquirer and PSP rather than constructing their own interpretation.

A tokenized or stored card alone does not make a payment an MIT.

If a customer signs into an account, adds an item, and presses “Buy now” using the card already on file, the transaction is still customer initiated. The storage method does not change who initiated the purchase.

Plan Changes, Free Trials, and Failed Renewals

Subscription amount changes need careful treatment. Regulatory recurring exemptions can contain conditions such as the same amount and same payee, while card-network MIT frameworks address broader stored-credential scenarios through their own rules and indicators.

Merchants should not assume every changed subscription price inherits whatever SCA treatment the original payment received.

Free trials deserve similar attention. When no payment occurs at signup but a card is collected for later charging, the merchant still needs a valid framework for the future payment and should follow its PSP’s requirements for establishing the mandate and authenticating relevant setup interactions.

Failed renewal recovery also should respect initiation type. If an automatic renewal fails and the merchant performs permitted MIT retry activity, it should remain correctly identified. If the customer later returns to the website and actively submits a replacement card or triggers a new purchase, that interaction may become customer initiated and require different SCA handling.

Exemption Strategy, Frictionless Authentication, and Conversion

Every SCA strategy balances authentication friction, issuer approval probability, fraud risk, and regulatory correctness.

One approach is:

Request Exemption → Attempt Authorization → Recover With 3DS if Issuer Requires SCA

Another is:

Perform 3DS Upfront → Frictionless or Challenge Authentication → Submit Authorization

Neither approach is universally superior.

An eligible low-risk payment may benefit from an exemption request because the issuer could approve it without active authentication. On the other hand, an issuer that rejects the exemption can create an extra round trip if the merchant then needs to start 3DS.

Upfront 3DS does not necessarily mean a visible challenge. EMV 3DS can produce a frictionless result based on issuer risk assessment, meaning merchants may gain authentication context without interrupting the shopper.

Measuring SCA Performance

Merchants should measure the entire funnel instead of focusing only on challenge rate.

Useful metrics include:

• Initial authorization approval rate.
• Number and rate of exemption requests.
• Exemption acceptance/rejection where exposed.
• SCA-related soft-decline rate.
• 3DS authentication-start rate.
• Challenge rate.
• Authentication completion rate.
• Post-authentication authorization approval rate.
• Final payment approval rate.
• Challenge abandonment.
• Duplicate payment attempts.
• Unresolved payment states.

A simple SCA recovery funnel could look like this:

Stage	Transactions	Conversion Metric
Initial authorization	10,000	Baseline attempts
Soft declined	Actual observed count	Soft declines ÷ initial attempts
Authentication started	Actual observed count	Auth starts ÷ recoverable declines
Authentication completed	Actual observed count	Completed ÷ auth starts
Retried authorization	Actual observed count	Retries ÷ completed authentication
Final approval	Actual observed count	Recovered approvals ÷ recoverable declines

The figures should come from the merchant’s own data. There is no responsible universal conversion benchmark that applies across countries, issuers, card portfolios, verticals, ticket sizes, fraud profiles, and PSP configurations.

Customer Messaging and Challenge UX

Customer-facing messages should describe what needs to happen without accusing the shopper of fraud.

For example:

“Your bank requires an additional verification step to complete this payment.”

If authentication fails, the interface might offer another legitimate card or supported payment method rather than repeatedly presenting the same unexplained error.

Mobile checkout deserves particular attention. 3DS challenges may involve browser frames, issuer applications, out-of-band authentication, native SDK flows, or app switching. EMVCo publishes implementation and UI/UX guidance for browser and app-based 3DS experiences.

The merchant should preserve checkout state when the customer leaves the app temporarily, handle return/deep-link behavior correctly, and verify the final result server-side.

Checkout Architecture, Payment APIs, and Operational Controls

SCA implementation complexity varies considerably by checkout architecture.

A hosted payment page may handle much of the 3DS flow automatically. An embedded payment element can keep the shopper on the merchant’s page while the payment provider controls sensitive payment fields. 

A custom API integration can offer greater flexibility but also requires stronger handling of authentication states, callbacks, errors, redirects, webhooks, retries, and reconciliation.

Hosted vs. Custom Checkout

With a hosted checkout, the PSP may:

• Collect card details.
• Determine 3DS eligibility.
• Initiate authentication.
• Display issuer challenges.
• Return the customer.
• Expose authorization status through an API or webhook.

The merchant still needs to ensure that fulfillment depends on final payment status rather than browser behavior.

A direct API integration usually requires more application logic. Developers may need to manage 3DS browser or SDK flows, payment-intent states, authorization retries, idempotency keys, webhook verification, and unresolved-state reconciliation.

Regardless of architecture, the core flow remains:

Checkout → SCA Scope → Exemption/Authentication → 3DS → Authorization → Final Payment State

API Integration Checklist

Area	Verify
3DS support	Supported EMV 3DS versions, browser/app flows, and issuer compatibility
SCA exemption fields	Which exemptions the PSP/acquirer can request and how
Authentication result	Where final authentication state and identifiers are returned
Soft-decline indicator	Which response fields mean authentication is required
Retry flow	How an authenticated authorization retry must be submitted
Idempotency	How duplicate authorization/capture is prevented
MIT/recurring flags	Correct stored-credential and initiation indicators
Webhook handling	Signature validation, event processing, duplicate events
Final-state reconciliation	API process for resolving missing or delayed events

Payment integrations should also log enough metadata for support and analytics without recording prohibited payment information.

Useful operational fields include:

• Internal order ID.
• Provider payment ID.
• Payment-attempt ID.
• SCA scope result.
• Exemption requested.
• 3DS authentication status.
• Authorization result.
• Decline category.
• Retry outcome.
• Capture state.
• Relevant non-sensitive network/provider references.

Never place raw security credentials, authentication secrets, CVV values, or prohibited cardholder data in application logs.

Cross-Border Acquiring, One-Leg Payments, and Liability

Acquirer location can influence SCA scope, but merchants should not choose acquiring geography merely as a mechanism for evading authentication.

The EBA has explained that one-leg payments require nuanced treatment because PSD2 may apply to portions of a transaction occurring within the Union even when one PSP is outside it.

This is one reason the statement “use a non-European acquirer and SCA disappears” is unsafe. Regulatory scope, issuer requirements, card-network rules, acquiring arrangements, and issuer risk decisions can all affect what happens at authorization.

Merchants should also distinguish regulatory responsibilities from protocol roles. At a high level, the issuer is generally central to cardholder authentication and authorization decisions, while the acquirer/PSP carries merchant-side transaction and exemption information through the ecosystem. EMV 3DS provides the protocol through which authentication messages are exchanged.

Liability Shift Is Not Universal Protection

3DS can change fraud liability in certain card-network scenarios, but merchants should not say that every authenticated transaction is automatically protected from fraud losses.

Actual liability depends on card network, region, authentication result, transaction indicators, merchant/acquirer configuration, reason for the dispute, and applicable network rules.

Even where a fraud-related liability benefit exists, 3DS does not eliminate disputes involving:

• Merchandise not received.
• Refund disagreements.
• Subscription cancellation.
• Service dissatisfaction.
• Duplicate processing.
• Incorrect amount.
• Other non-fraud dispute categories.

Authentication evidence can also help merchants understand or defend some transactions, but it is not a substitute for fulfillment records, cancellation records, receipts, customer communications, or dispute management.

Fraud Prevention Beyond SCA

SCA is an authentication control, not a complete fraud-prevention program.

Online merchants still need layered controls appropriate to their business model. These can include:

• AVS where supported.
• CVV verification at the appropriate payment interaction.
• Device and behavioral analysis.
• Velocity controls.
• Account-takeover prevention.
• Fraud scoring.
• Shipping and fulfillment checks.
• Manual review for selected high-risk orders.
• Tokenization.
• Secure customer-account management.

Never store CVV after authorization. Payment-data handling should follow applicable PCI DSS and provider requirements.

SCA also does not eliminate friendly fraud. A real cardholder can authenticate a purchase and later dispute it for reasons unrelated to unauthorized account use.

For subscription merchants, recognizable billing descriptors, renewal notifications where required or appropriate, easy cancellation, receipts, and accessible support remain important dispute-prevention controls.

Avoid SCA Exemption Abuse

Merchants should never manipulate transaction classifications to avoid authentication.

Problematic practices include:

• Falsely labeling customer-initiated purchases as MITs.
• Classifying ecommerce payments as MOTO because card details were manually entered somewhere downstream.
• Requesting exemptions that do not fit the transaction.
• Routing transactions primarily to circumvent authentication obligations.
• Reusing recurring indicators without establishing the underlying mandate.

The EBA’s treatment of manually keyed transactions demonstrates why “keyed” is not synonymous with MOTO.

Misclassification can produce authorization problems, compliance concerns, unexpected liability, poorer issuer trust, and reconciliation errors.

Processor Configuration and SCA Monitoring

Many SCA failures are configuration failures rather than regulatory mysteries. A merchant may technically support 3DS yet still fail to pass the right authentication data into authorization, incorrectly map soft declines, or mis-tag recurring payments.

Review payment-provider settings whenever you launch a new market, switch acquirers, add subscriptions, change gateways, or materially revise checkout architecture.

Verify:

• Whether SCA/3DS is enabled for applicable traffic.
• Which EMV 3DS versions and flows are supported.
• Which SCA exemptions the provider can request.
• Whether exemptions are automatically selected or merchant controlled.
• How rejected exemptions are surfaced.
• How SCA soft declines are identified.
• Whether recovery can automatically initiate 3DS.
• How MIT and recurring transactions are flagged.
• Which identifiers link subsequent transactions.
• Which webhook events communicate authentication and authorization state.
• What happens when the customer abandons the challenge.
• How unresolved transactions should be reconciled.
• Which liability conditions apply to authenticated transactions.

SCA Implementation Checklist

Control	Ready?
Scope determination	☐
3DS2 enabled	☐
UK vs EEA logic understood	☐
Exemption logic	☐
Soft-decline detection	☐
Authentication retry	☐
Idempotency	☐
MIT/recurring tagging	☐
Stored-credential compliance	☐
Webhook processing	☐
Payment reconciliation	☐
Monitoring/dashboard	☐
Customer error messaging	☐

Monitor SCA performance by issuer country, card network, acquiring route, payment method, checkout version, exemption type, subscription status, device type, and transaction amount where useful.

That level of segmentation can reveal issues hidden in aggregate approval rates. For example, a new acquiring route might suddenly produce more SCA soft declines because authentication information is not being forwarded correctly.

Common SCA Implementation Mistakes

The most damaging SCA mistakes usually come from oversimplifying a multi-party payment process.

One common error is assuming every UK or EEA ecommerce purchase must display a challenge. Frictionless 3DS can complete without active cardholder input, and qualifying exemptions can permit some transactions to proceed without SCA.

The opposite error is assuming that an exemption request guarantees no authentication. The issuer retains an important decision-making role and can require SCA.

Other frequent problems include:

• Confusing an exemption with an out-of-scope transaction.
• Retrying SCA soft declines without authentication.
• Automatically retrying hard declines.
• Treating every saved-card payment as an MIT.
• Failing to establish the original recurring mandate correctly.
• Assuming every subscription is exempt.
• Misclassifying ecommerce payments as MOTO.
• Ignoring UK-versus-EEA threshold differences.
• Using outdated PSD2 summaries as implementation specifications.
• Treating a browser return URL as authoritative payment status.
• Failing to use idempotency on authorization and capture calls.
• Not reconciling missing webhooks.
• Assuming successful 3DS guarantees financial authorization.
• Assuming 3DS prevents every chargeback.
• Logging sensitive card or authentication information.
• Failing to measure exemption rejection and soft-decline recovery.

The EU payment-services framework is also evolving. The European Commission identifies an ongoing PSD2 revision process, while PSD2 and its applicable delegated technical standards remain central current references for existing SCA implementation.

Merchants should therefore revalidate regulatory and network assumptions periodically rather than treating an SCA implementation as a permanent one-time project.

Questions to Ask Your Payment Provider

Payment-provider documentation determines how regulatory concepts become actual API fields and payment states. Before launching SCA payments in the UK or EEA, ask your acquirer, gateway, or PSP questions that reveal how its implementation works in production.

Questions should include:

• How do you determine when SCA applies?
• How do you distinguish UK and EEA regulatory treatment?
• Which current EMV 3DS versions do you support?
• Which SCA exemptions can our account request?
• Do you choose exemptions automatically or must we specify them?
• How are issuer exemption rejections surfaced?
• Which response fields identify an authentication-required soft decline?
• Can you automatically invoke 3DS after an SCA soft decline?
• How should we retry the authorization after authentication?
• Which authentication identifiers must be included?
• How should retry calls use idempotency?
• How are customer-initiated and merchant-initiated transactions distinguished?
• Which stored-credential indicators do you require?
• How is an MIT linked to the original transaction or mandate?
• How do you support recurring and installment scenarios?
• Which webhook events represent final authorization and capture status?
• What should we do if the webhook never arrives?
• How do we query unresolved payment states through the API?
• What happens when the shopper abandons the authentication flow?
• Which 3DS liability-shift conditions actually apply to our acquiring setup?
• Which reports expose exemptions, challenges, SCA soft declines, and recovered authorizations?

Providers that cannot answer these questions clearly may make it difficult to diagnose SCA failed authorization patterns later.

Frequently Asked Questions

What is Strong Customer Authentication?

Strong Customer Authentication is a regulatory authentication standard that generally uses at least two independent elements from knowledge, possession, and inherence categories. Its purpose is to strengthen security for electronic payments and certain account-access activities. 

Under EU PSD2, the definition and technical requirements are set out in the directive and SCA regulatory technical standards. The UK maintains its own SCA framework through the Payment Services Regulations and FCA technical standards.

Does SCA apply to sales into both the UK and EU?

Yes, merchants can encounter SCA in both markets, but merchants should not treat the two legal frameworks as one identical regime. 

EEA transactions may fall under PSD2 and EU regulatory technical standards, while UK transactions are governed through UK payment-services legislation and FCA standards. Issuer, acquirer, transaction-initiation, and routing details can affect scope, so customer IP address or shipping destination alone should not decide whether SCA applies.

What is the difference between UK SCA and EU SCA?

Both frameworks share similar core concepts, including multi-factor authentication, exemptions, recurring payments, and transaction risk analysis, but they are legally separate. Numerical differences also exist. 

For example, the EU remote low-value exemption uses €30 with relevant cumulative/count conditions, while the FCA’s UK standard uses £25 and a £85 cumulative threshold. Merchants should therefore use current market-specific PSP configuration rather than one universal rule set.

Does every ecommerce payment require 3-D Secure?

No. Not every ecommerce transaction requires a visible 3DS challenge, and not every transaction necessarily requires SCA. Some payments may qualify for exemptions or different scope treatment. 

When 3DS authentication does occur, the issuer may authenticate frictionlessly using transaction and risk information instead of challenging the customer. EMVCo recognizes both frictionless and challenge flows.

What are the main SCA exemptions?

Important ecommerce-related exemptions include low-value transactions, transaction risk analysis, trusted beneficiaries, qualifying recurring transactions, and certain secure corporate payment processes. Exact eligibility depends on the regulatory framework and payment circumstances. 

An exemption request does not guarantee approval; the issuer or relevant payment service provider may still require SCA. Merchants should distinguish these exemptions from transactions that are outside the SCA requirement for another legal or transactional reason.

What is the transaction-risk-analysis exemption?

TRA allows eligible payment service providers to avoid SCA for remote payments their real-time risk analysis identifies as low risk when regulatory fraud-rate and value requirements are met. 

Under the EU framework, the remote-card reference bands include €100, €250, and €500 with increasingly strict reference fraud rates. It is not a merchant-created fraud score, and a merchant cannot force an issuer to accept the exemption.

Are recurring subscription payments exempt from SCA?

Not automatically. The initial establishment or first transaction in a qualifying recurring series may require SCA, and subsequent payments receive different treatment only when the regulatory and payment-network requirements are actually met. 

Genuine merchant-initiated transactions established under a valid mandate also differ from customer-initiated purchases. A stored card or subscription ID by itself does not make every later payment exempt.

What is a merchant-initiated transaction?

A merchant-initiated transaction is a payment initiated by the merchant under a prior agreement or mandate rather than by the customer actively initiating that specific payment. Subscription renewals can be common examples when correctly established and flagged. 

Network stored-credential rules and appropriate transaction linkage remain important. If the customer returns and actively starts a new purchase with a saved card, that new payment should not automatically be classified as an MIT.

What is an SCA soft decline?

An SCA soft decline is an authorization decline indicating that authentication may be required before the issuer will approve the payment. It frequently occurs when an authorization was submitted without required SCA or when an exemption request was not accepted. 

Exact response codes and fields differ by processor, network, issuer, and gateway. Merchants should therefore rely on their provider’s current decline mapping rather than assuming every generic decline is recoverable with 3DS.

How do you recover a soft-declined payment?

Identify that the decline genuinely requires SCA, initiate the appropriate 3DS authentication flow, obtain the authentication result, and retry the authorization with the required authentication data and transaction linkage. 

The issuer can still decline the second authorization for financial or risk reasons. The application should use idempotency to prevent duplicates and should update the order only after confirming final provider-side payment state.

Should a soft decline be retried without authentication?

Generally, not when the decline specifically says authentication is required. Submitting the same unauthenticated request again does not address the reason for the decline and may simply produce another rejection. 

The appropriate response is to move the payment into an authentication-required state and follow the provider’s 3DS recovery process. Other temporary declines should be handled according to processor-specific guidance rather than automatically treated as SCA failures.

What happens if 3DS authentication succeeds but authorization fails?

The payment still fails unless the issuer subsequently authorizes it. Authentication and authorization are separate decisions. A cardholder may successfully prove control of the payment method while the issuer declines because of insufficient funds, restrictions, fraud controls, account status, or another reason. 

The merchant should display an appropriate payment message and allow a legitimate alternative card or payment method where suitable rather than assuming authentication guarantees approval.

Does 3-D Secure guarantee payment approval?

No. 3DS supplies authentication information; it does not force an issuer to authorize a transaction. The issuer still evaluates financial availability, fraud signals, card restrictions, transaction history, and other authorization criteria. 

Even a successfully authenticated transaction can therefore receive a decline. Merchant analytics should separately measure authentication completion and post-authentication authorization performance.

Does SCA eliminate fraud chargebacks?

No. SCA and 3DS may reduce certain unauthorized-payment risks and can affect liability under specific card-network conditions, but they do not eliminate all disputes. 

Customers can still raise disputes involving delivery, cancellation, duplicate charges, subscription expectations, service quality, refunds, or other issues. Merchants need fulfillment evidence, clear policies, accurate descriptors, good customer service, and broader fraud controls in addition to SCA.

How should merchants measure SCA checkout performance?

Measure initial approvals, exemption requests, exemption acceptance or rejection where available, SCA soft declines, authentication starts, challenge rates, challenge completion, authentication failures, post-SCA authorization approvals, final declines, duplicate attempts, and unresolved states. 

Segmenting by issuer country, network, acquirer, payment type, device, and checkout version can reveal integration problems that an overall authorization rate hides.

Conclusion

Strong Customer Authentication for sales into the UK and EU is not simply a requirement to display a 3-D Secure challenge. It is a payment-control framework involving regulatory scope, exemptions, transaction classification, issuer authentication, authorization decisions, card-network rules, gateway implementation, and reliable payment-state management.

Merchants should begin by determining whether a transaction is within SCA scope. If it is, the payment flow may involve authentication, an eligible exemption request, or another legitimate treatment depending on the transaction. An exemption is not an instruction that binds the issuer, and frictionless 3DS should never be confused with an exemption.

The most important recovery capability is the handling of SCA soft declines. Instead of treating an authentication-required authorization response as an immediate lost sale—or repeatedly resubmitting the same request—a well-designed checkout moves the payment into a 3DS authentication flow and retries authorization using the resulting authentication information.

Recurring billing requires equal discipline. The initial customer interaction, establishment of a mandate, subsequent merchant-initiated transactions, customer-initiated account changes, stored credentials, and failed-renewal recovery should all be classified correctly. A card being saved does not itself create permission to bypass SCA.

From a technical perspective, idempotency, webhooks, server-side payment verification, and reconciliation are as important as the authentication screen. A browser redirect is not payment truth, a successful authentication is not an authorization, and an authorization is not necessarily a capture.

Ultimately, strong SCA compliance is not about maximizing exemptions or challenges. It is about accurately classifying payments, providing issuers with the right authentication context, recovering legitimate transactions when additional verification is required, and preserving a reliable final payment state from checkout through reconciliation.

Disclaimer: This article provides general payments, regulatory, and technical information and is not legal, regulatory, compliance, or card-network advice. SCA requirements, payment-service legislation, network rules, issuer practices, exemption eligibility, and PSP implementations can change. 

Merchants should verify current requirements with the applicable regulator, acquirer, payment service provider, card-network documentation, and qualified advisers before relying on a particular SCA configuration.