Is Your Payment Stack PSD2-Ready? What Still Catches Teams Off Guard in 2026

Most payment teams believe they solved PSD2 SCA compliance payments when they turned on 3DS2. They did not. What they did was shift the complexity one layer deeper, into exemption logic, MIT sequencing, and issuer-side authentication behavior that no single PSP dashboard surfaces clearly. We see the consequences every week: approval rate drops no one can explain, conversion losses attributed to "issuer behavior," and SCA audit findings that only appear when a new market is added.

Key Takeaways

• Turning on 3DS2 satisfies the technical SCA requirement, but misconfigured exemption logic is where merchants actually lose approval-rate points.
• Merchant-initiated transactions are out of SCA scope, but the initial mandate authentication must clear SCA — otherwise issuers will decline subsequent charges.
• TRA (Transaction Risk Analysis) exemptions sit at the acquirer level and depend on holding fraud rates below EBA thresholds. Your routing decisions directly affect the exemptions you can claim.
• PSD3 and the Payment Services Regulation push more fraud liability toward PSPs and introduce tighter Verification of Payee obligations. Merchants using payment initiation services should start their gap assessments now.
• Multi-PSP routing is an under-used lever for SCA optimization: different acquirers have different TRA thresholds, meaning the same transaction routed through a different provider can unlock a frictionless flow.

What PSD2 SCA Compliance Actually Requires in 2026

PSD2 Strong Customer Authentication (SCA) requires that remote electronic card payments in the EU and UK use at least two independent authentication factors: something the customer knows, has, or is. EMV 3DS2 is the primary technical mechanism for card-not-present transactions, and when an issuer ACS presents a multi-factor challenge, the transaction meets the SCA standard.

That is the baseline. The operational complexity sits in everything built on top of it: which transactions are in scope, which qualify for exemptions, and what happens when an issuer disagrees with your exemption request.

SCA applies to card-not-present transactions where both the payer and the payment service provider are based in the European Economic Area or the UK. One-leg-out transactions, where only one party is in scope, sit in a grey zone that issuers handle inconsistently. We see this regularly with merchants who have EU-domiciled entities but serve customers across markets with mixed issuer geography.

The Four SCA Mistakes That Keep Appearing in Production

The most common SCA failures in production are not technical failures; they are configuration failures in exemption logic, MIT sequencing, and fallback routing. Each one is preventable with the right infrastructure, but each one also requires visibility across your entire PSP stack, not just one acquirer's dashboard.

Treating SCA Exemptions as Set-and-Forget Rules

SCA exemptions are not static. Transaction risk analysis (TRA) exemptions require your acquirer to maintain fraud rates below thresholds set by the European Banking Authority. If your fraud rate drifts above threshold in a given period, TRA exemptions become unavailable for that acquirer, and every transaction that relied on them will now trigger a challenge or a soft decline.

From our integrations across e-commerce and marketplace verticals, we see merchants discover this only when conversion drops unexpectedly after a fraud spike. By the time the drop is noticed, the exemption window has already been lost for days. Exemption eligibility needs active monitoring, not a quarterly review.

The main exemptions available under PSD2 and their scope are worth keeping in one place:

• Low-value transactions under €30, subject to cumulative limits of five transactions or €100 before SCA is required.
• Trusted beneficiary lists, where the customer has explicitly whitelisted a merchant with their issuer.
• Corporate payments using dedicated payment processes and protocols confirmed as low-risk.
• TRA exemptions across low, medium, and high transaction-value thresholds, each requiring fraud rates below 0.13%, 0.06%, and 0.01% respectively.
• Recurring transactions after the first SCA-authenticated mandate.

Misconfiguring Merchant-Initiated Transactions

Merchant-initiated transactions are outside SCA scope. Subscriptions, deferred charges, and installment collections after the first payment all qualify as MITs, and applying 3DS to them wastes friction and sometimes breaks the flow entirely. The error we see most often runs in the opposite direction: merchants skip the SCA authentication on the initial mandate setup, then wonder why issuers reject subsequent MIT charges.

The mandate establishment payment must pass SCA. That first transaction anchors every future charge in the series. If it is skipped, soft-declined, or routed through a PSP that does not correctly flag it as a recurring agreement, the MIT chain breaks at the issuer level. This is especially common when merchants migrate to a new acquirer mid-subscription lifecycle and fail to re-authenticate existing mandates.

Applying 3DS Uniformly Across All Transactions

Applying 3DS to every transaction is not conservative risk management. It is a conversion tax on your best customers. Trusted, repeat buyers in low-risk categories do not need a challenge. Adding one reduces completion rates and signals to the issuer that you do not have transaction-level risk intelligence.

Based on our infrastructure, the right approach layers Risk Conditions on top of 3DS logic. Transactions from known devices, low-velocity patterns, and trusted customer profiles should flow without a 3DS challenge. Suspicious signals, new devices, high-value outliers, and geographic mismatches should trigger it. Yuno's 3DS product supports custom condition logic that routes transactions through challenge or frictionless paths based on real signals rather than blanket rules.

Ignoring Issuer Soft-Decline Handling

When an issuer refuses an exemption request, they return a soft decline with an authentication required flag. Merchants who are not set up to handle this response lose the transaction entirely. The correct response is to re-present the transaction through 3DS challenge. Without automated fallback logic, that recovery never happens.

This is a particularly sharp problem in multi-PSP environments where each provider handles soft declines differently. We have seen cases where one acquirer retries automatically, another drops the transaction, and a third raises an error that goes unhandled for hours. Centralized orchestration closes that gap by applying consistent fallback logic across every acquirer in the stack.

How Multi-PSP Routing Affects SCA Outcomes

Routing decisions and SCA outcomes are directly connected because TRA exemption eligibility is acquirer-specific, not merchant-specific. An acquirer with a consistently low fraud rate has access to higher-value TRA exemptions that another acquirer in your stack may not.

This means the same transaction routed through different acquirers can have materially different authentication outcomes. One path triggers a frictionless flow. Another triggers a challenge. A third soft-declines and requires a retry. Yuno's platform data shows that exemption-aware routing, directing transactions to the acquirer best positioned to claim a given exemption, improves frictionless rates across EU markets without any change to the merchant's checkout UX.

This is an insight that only surfaces when you have multi-PSP visibility in a single place. A single acquirer cannot compare its own exemption eligibility against a competitor. Yuno can, because we see the full picture across every provider in your stack. Payment Concierge surfaces these acquirer-level differences in real time, so payment operations teams can act on them rather than discover them in a post-mortem.

What PSD3 and the PSR Change for Merchants Already Running PSD2-Compliant Stacks

PSD3 is not a renamed version of PSD2; it is a structural expansion that shifts fraud liability, broadens SCA scope in specific scenarios, and introduces new obligations for payment initiation service users. Merchants who treat PSD3 as an incremental update will be caught off guard when the transition timelines tighten.

The most operationally significant changes include:

• Greater fraud-liability shift toward PSPs, with more explicit accountability when authorized push payment scams occur through payment-initiation channels.
• Verification of Payee becomes mandatory for account-to-account flows, with euro-area member states already required to support it from October 2025.
• Stricter requirements around social-engineering scenarios, where merchants and PSPs must demonstrate due diligence when customers are manipulated into authorizing fraudulent payments.
• Clearer SCA rules for non-card payment methods, closing the gaps PSD2 left open for wallets and account-based payments.
• Expanded rights for PSPs to share fraud intelligence across institutions, which changes the dynamics of fraud-prevention tool selection.

For merchants currently using payment initiation services alongside card rails, the liability framework is the most urgent thing to review. PSD3's fraud accountability provisions create exposure that did not exist under PSD2 for certain transaction types.

How Yuno Handles SCA Compliance Infrastructure

Yuno's 3DS product gives merchants full control over when and how authentication is applied, without requiring custom engineering for each market or acquirer. Custom condition logic routes transactions based on risk score, geography, customer status, and velocity patterns.

Trusted customers bypass friction. Suspicious signals trigger layered checks. And soft-decline fallback is handled automatically across every acquirer in the stack, so a rejected exemption request does not become a lost transaction. Yuno's Risk Conditions layer sits upstream of 3DS, filtering known-good transactions before they reach the authentication step and blocking known-bad actors before they consume PSP resources.

The result is a layered approach that does what blanket 3DS cannot: protect conversion for legitimate customers while maintaining the fraud rates that keep TRA exemptions available. Yuno's platform data shows a 29% fraud reduction for merchants using Risk Conditions in combination with intelligent 3DS routing.

For the PSD3 transition, Yuno's infrastructure is already scoped to handle the Verification of Payee obligations and the expanded SCA conditions the regulation introduces. Merchants on Yuno do not need to re-architect their authentication stack when PSD3 enters force. The configuration layer absorbs the change.

The Practical Audit Every Payment Leader Should Run Now

Before PSD3 timelines compress further, three audits are worth completing on your current stack.

• Map every transaction type against the SCA exemption and exclusion taxonomy. Confirm MIT mandates are correctly authenticated at setup. Identify any transaction flow where exemption flags are missing or incorrectly applied.
• Check acquirer-level fraud rates against current EBA TRA thresholds. If any acquirer in your stack is approaching a threshold ceiling, build the routing logic to shift volume before exemption eligibility is lost.
• Test your soft-decline fallback routes. Trigger a deliberate soft-decline in staging and confirm that the automated retry through 3DS challenge runs correctly across every acquirer. If it does not, you are losing transactions in production right now.

These three checks take less than a week with the right tooling. Without centralized visibility across your PSP stack, each one requires pulling data from separate dashboards, reconciling formats, and making decisions with incomplete information. That is where most teams lose time, and where most SCA gaps stay hidden longest.