3DS standardization is unfinished business for enterprise multi-PSP operators

An enterprise payments lead recently asked a vendor a question that gives away the whole problem: "Do you support standalone 3DS, or does it have to run inside the PSP?" That question only gets asked by someone who has discovered that their three PSPs are running three different authentication policies, and that the variance is now visible in the authorization data. The Paypers published an explainer on EMV 3DS authentication on April 29, 2026, walking through the protocol at a level appropriate for someone learning it for the first time. The same week, in private conversations, payments leads at multi-PSP merchants were asking a more advanced question. They had read the spec years ago. What they wanted to know was whether anything could be done about the fact that their PSPs were each implementing the spec differently.

EMV 3DS is a standardized protocol. The authentication policy that gets executed on top of it is not, because policy lives at the PSP, and every PSP has its own. That gap was an operational annoyance two years ago. It is becoming an architectural deadline now, because two converging pressures meet in the same place: regulatory clocks that redraw who owns Strong Customer Authentication, and operational variance that grows worse with every PSP added. Both pressures resolve to the same question: where the 3DS Server lives? And most enterprises answered it by default three years ago without thinking.

‍

The protocol is standardized. The policy is not.

EMV 3DS 2.x defines the wire format: how the merchant's 3DS Server talks to the scheme's Directory Server, how the Directory Server routes to the issuer's Access Control Server, what data fields move between them, and how the result, the ECI value and the Cardholder Authentication Verification Value, comes back. That part is standardized. Every certified implementation handles the same protocol.

What is not standardized is the decision-making layer that sits on top: when to request a Transaction Risk Analysis exemption, when to flag a payment as low-value, when to use the merchant-initiated transaction indicator, how to populate the optional risk fields, what to do with a soft decline. Those decisions are configured per PSP. The merchant who plugs into three PSPs inherits three configurations, three default exemption strategies, and three soft-decline handlers. The protocol behind them is identical. The policy is not.

‍

Why the regulatory clock matters now

The "unfinished" framing has a calendar attached. Three deadlines arrive in the same window, and each one raises the cost of leaving 3DS policy inside the PSP.

Visa's Digital Authentication Framework sunsets in September 2026, after which every Visa Secure implementation runs on the highest EMV 3DS protocol version supported by the issuer, negotiated per transaction through the PReq/PRes flow. A merchant whose three PSPs each negotiate that version independently with each issuer produces inconsistent outcomes by design.

The PSR, the directly applicable half of the PSD3 package, was politically agreed in November 2025 and is expected to enter into force in 2027 after a 21-month transition. Its delegated authentication clause lets the issuer outsource SCA to a technical service provider under a written agreement, with the authenticating party carrying fraud liability. Under PSD2, SCA was implicitly the issuer's job, executed via 3DS. Under the PSR, the merchant or its orchestrator can become the authenticating party. But only if the merchant owns the 3DS Server. A merchant whose 3DS lives inside three PSPs has no path to accept delegated authentication; it can only consume whatever its PSPs produce.

Visa's AES migration target, signaled for completion by end of 2030, means the cryptographic primitives underneath 3DS change at the same time the regulatory perimeter is being redrawn. The variance problem has existed for years. The regulatory clock changes what the variance costs: from operationally inconvenient to structurally expensive, on a 12-to-18 month horizon.

‍

Exemption logic: where the operational variance starts

The PSD2 Regulatory Technical Standards permit several exemptions from SCA: Transaction Risk Analysis for transactions deemed low-risk and below a value band, Low-Value Payments under thirty euros (subject to a cumulative limit of one hundred euros or five consecutive transactions), Merchant-Initiated Transactions after an authenticated setup, trusted-beneficiary whitelisting, and Secure Corporate Payments. Visa Europe has estimated that 40 to 50 percent of e-commerce transactions by volume could qualify for SCA exemption if the criteria are met.

The structural source of multi-PSP variance is the TRA exemption mechanic. Under the European Banking Authority's RTS, the fraud rate that determines TRA eligibility is calculated at the PSP level on a rolling quarterly basis. Three PSPs serving the same merchant will each have a different fraud rate, sitting in a different value band, with different exemption eligibility. The acquirer at 0.11 percent fraud rate qualifies for the exemption up to a higher threshold; the acquirer at 0.14 percent does not qualify at all above the lowest band. Layer on the implementation choices each PSP makes, request the TRA flag aggressively, request it only above a configured risk score, never request it because the merchant did not configure the integration; and the merchant doing nothing differently across three PSPs gets three different SCA outcomes on identical transactions. The authorization rate hit is invisible in any single PSP's dashboard, because each PSP only sees the transactions it routed.

Normalizing exemption logic across PSPs means making the exemption decision in one place, before routing, against the merchant's own risk policy rather than each PSP's defaults. The decision is then communicated to whichever PSP processes the authorization.

‍

Challenge rate behavior: the invisible part of the spread

The frictionless rate is the percentage of 3DS transactions that complete without a cardholder challenge. It depends on three inputs the merchant does not directly control: the issuer's risk model in its Access Control Server, the data quality that arrived at the issuer, and the PSP's exemption signaling.

The second input is where the multi-PSP merchant pays the most. EMV 3DS 2.x supports more than 170 data elements that the merchant 3DS Server can populate for risk-based authentication. Issuers use that data to decide whether to challenge. PSPs vary in how much of it they populate from the merchant's checkout: device fingerprint quality, browser data, prior transaction history, merchant risk indicators, address verification fields, account age, cardholder behavior signals. A PSP that populates 40 data fields will produce a different challenge rate than a PSP that populates 110, on the same card, in the same session, with the same issuer.

The Paypers published a separate interview on April 21, 2026, on the psychology of checkout friction, noting that challenge rates affect conversion in ways that vary by market and device context. The implication for multi-PSP operators is that conversion-rate measurement at the aggregate level masks the issuer-by-PSP variance that is actually driving the spread. Benchmarking requires BIN-level data joined to PSP routing data. Without it, the analytics layer cannot see which PSP is dragging the issuer's challenge rate up.

Operational mechanics for normalizing challenge rate behavior: capture the full set of available 3DS 2.x data elements at the orchestration layer, before the PSP-specific 3DS Server is invoked, so data quality is set once rather than per integration; track challenge rate per issuer BIN per PSP, not just per PSP or per market, to surface the variance the per-PSP dashboard cannot show; and treat challenge rate as a tunable PSP-routing input, not a per-PSP black box.

‍

Fallback handling: the cost that compounds with every PSP added

A soft decline is an issuer response indicating that the transaction would be approved if SCA were performed. EMV 3DS 2.x and the PSD2 framework expect the merchant to retry with a full SCA challenge. The Visa soft decline code for this is 20154, with parallel Mastercard codes. Handling soft declines correctly is the difference between recovering the transaction and losing it; merchants that do not implement the retry path lose those transactions entirely.

In a multi-PSP architecture where 3DS lives inside each PSP, soft-decline handling has a hidden failure mode. When a transaction is routed to PSP A, soft-declined for SCA, and then cascaded to PSP B for retry, the 3DS authentication from PSP A cannot be reused at PSP B. The cardholder, who has just completed an SCA challenge moments earlier, is asked to complete another one. In PSD2 markets, the operator is now asking the customer to authenticate twice within the same payment attempt. The drop-off rate on the second challenge is substantially worse than the first.

The structural cause is the same as the exemption logic problem. The 3DS authentication result is bound to the PSP that produced it. There is no portable authentication artifact that survives a routing decision. Industry guidance for solving this is consistent: the merchant owns the 3DS Server, becomes PCI-L1 compliant where required, and runs authentication once before the PSP is selected. The authentication result, ECI and CAVV included, is then passed to whichever PSP authorizes the transaction.

This is the architecture the practitioner asking about "standalone 3DS" had read enough to know exists. It is not a product gap. It is a deployment-pattern question. Whether the merchant's 3DS Server is independent of the PSP routing layer is the question that determines whether soft-decline cascading works without re-authenticating the customer, whether the merchant can accept delegated authentication under the PSR when it enters into force, and whether the AES migration in 2028 is a single project or three.

‍

A scenario that should look familiar

A high-volume marketplace operating across the US and Europe integrates three PSPs eighteen months ago to expand acquiring coverage. Each PSP handles 3DS its own way, and each hits its individual SLA. In month nine, the team builds a BIN-level dashboard joining authentication outcomes to PSP routing data, and discovers a six-to-eight point spread in frictionless rate across the three PSPs on overlapping issuer BINs. The PSP with the lowest frictionless rate is also the cheapest on acquiring fees, so the routing rules send the most volume there. The conversion drag, annualized, exceeds the acquiring savings by an order of magnitude.

The fix is not a routing rule change. The fix is moving the 3DS Server out of the three PSPs and into the orchestration layer, so the same exemption flagging, the same data population, and the same fallback handling apply regardless of which PSP authorizes. The team that does this in 2026 has clean BIN-level data going into the PSR enforcement window. The team that defers rebuilds the same architecture under deadline pressure in 2027.

‍

The acknowledged cost

Owning the 3DS Server at the orchestration layer is not the lowest-effort path. It requires direct certification work against EMV 3DS, ongoing maintenance as protocol versions advance, and operational responsibility for a component that used to be inside the PSP. The first quarter of running it produces less time-to-launch than handing the same job to a PSP. The math has flipped because the per-PSP variance compounds every month the architecture is wrong, and the regulatory window for converting that variance from cost to capability closes between late 2026 and 2027.

The cost of running fragmented 3DS is paid every month in lost authorizations and lost conversions. The cost of unifying it is paid once.

‍

What multi-PSP operators should evaluate before adding the next PSP

The diagnostic is short. Where does the 3DS Server live for each integrated PSP? If the answer is "inside the PSP," exemption logic, challenge rate behavior, and soft-decline handling are configured per PSP rather than per merchant. Which exemption flags are being requested on which transactions, and by which PSP's default policy? If the merchant cannot answer this without opening each PSP's configuration UI, the policy is fragmented. What happens when a soft decline at PSP A cascades to PSP B? If the customer faces a second SCA challenge, fallback handling is the next thing that needs to move into the orchestration layer. Who carries the SCA liability when the PSR enters into force? If the answer is "the PSP," the merchant has no path to optimize conversion economics at the authentication layer.

EMV 3DS standardized the message format. The standardization that matters for the multi-PSP operator - the part where exemptions, challenges, and fallbacks behave the same regardless of which PSP authorized - was left as an exercise for the merchant. Three years ago, that exercise was easy to defer because the variance was small and the regulatory liability lived with the issuer. The next twelve months are about whether it gets done by the operators who choose to own it, or deferred by the operators who continue to assume their PSPs are doing it for them. Whoever owns the 3DS Server, owns the policy. That is the part that is still unfinished.