PSD2 compliance and passwordless authentication for payment access

At a glance

What this is: This is a PSD2 compliance explainer showing how passwordless authentication can satisfy strong customer authentication and dynamic linking requirements for EU payment access.

Why it matters: It matters because payment, IAM, and CIAM teams need controls that meet regulatory authentication rules while keeping checkout flows usable and limiting account takeover risk.

Context

PSD2 is the EU payments rule set that raises the bar for online payment authentication, especially where customer data, third-party access, and transaction approval intersect. For identity teams, the practical issue is how to prove possession, inherence, and transaction-specific approval without relying on passwords as the primary trust signal.

The compliance problem is not limited to banks. eCommerce merchants, payment service providers, and any business that touches EU payment flows need authentication that survives regulatory scrutiny and still fits real checkout behaviour. Passwordless designs shift the discussion from whether MFA exists to whether the identity proof and transaction binding are strong enough for PSD2.

Key questions

Q: How should payment organisations implement strong customer authentication without creating unnecessary checkout friction?

A: Use at least two independent factors from knowledge, possession, and inherence, then apply them only when the transaction risk justifies it. Pair authentication with device and transaction monitoring, and keep the customer informed about what is being authorised. The goal is to reduce fraud while preserving a workable payment journey, especially for mobile and cross-border transactions.

Q: Why do payment flows need dynamic linking when strong customer authentication is used?

A: Dynamic linking binds the authentication code to the exact payment amount and recipient, which prevents attackers from altering a transaction after approval. If either the amount or the payee changes, the payment should fail. This matters because authentication alone does not protect the integrity of the transaction details that the customer intended to authorise.

Q: What breaks when payment access still depends on reusable passwords?

A: Reusable passwords keep the account takeover path open, especially when attackers can phish, reuse, or recover credentials through weak fallback processes. In regulated payment flows, that weakens the ability to show possession and inherence, and it makes the checkout path easier to abuse. Password removal only helps if recovery is also redesigned.

Q: What is the difference between MFA and PSD2 dynamic linking?

A: MFA proves the user at login, while dynamic linking proves that the user approved this specific amount for this specific payee. A payment flow can have strong authentication and still fail PSD2 if the approval is not bound to the transaction details. The two controls solve different problems and should not be treated as interchangeable.

Technical breakdown

Strong customer authentication and the factor model

PSD2 strong customer authentication requires at least two of three factor types: knowledge, possession, and inherence. The article maps passwordless authentication to this model by replacing the password with a device-bound private key for possession and a local biometric check for inherence. That matters because the compliance question is not whether a second factor exists, but whether the factors are independent enough to resist the common failure modes of password-centric checkout flows. In payment contexts, the authentication event must also be tied to the transaction, not just the user session.

Practical implication: Treat checkout authentication as a proofing and transaction-binding problem, not a simple MFA checkbox.

Dynamic linking in transaction approval

Dynamic linking requires the authentication code to be specific to both the payment amount and the payee, and any change must invalidate that code. This prevents replay or substitution after approval, because the user is authorising a particular transaction rather than a generic session. In practical identity terms, this is closer to per-transaction authorisation than ordinary login assurance. The control reduces the value of stolen credentials if the attacker cannot reuse an approval token for a different amount or recipient.

Practical implication: Make payment approval stateful to the amount and recipient, not just the authenticated user.

Passwordless checkout flows and account takeover exposure

The article argues that passwordless login can reduce checkout friction while also removing a common attack path: password-based account takeover. That is an identity and fraud issue, not just a user-experience issue, because the absence of reusable passwords removes one of the easiest ways attackers persist across payment journeys. Device-bound credentials and local biometric confirmation also narrow recovery abuse, which is often where fraud teams lose assurance. For payments, the architectural question becomes whether the identity boundary is anchored to a controllable device and a verifiable local action.

Practical implication: Design payment access so the credential cannot be copied, replayed, or recovered through weak fallback paths.

Threat narrative

Attacker objective: The attacker wants to take over payment access and authorise transactions without being forced through strong, transaction-bound verification.

1. Entry occurs through password-based account takeover attempts against payment or checkout accounts, where reusable credentials remain the easiest initial access path.
2. Credential access succeeds when attackers obtain or reuse login secrets that are not tied to a specific device or transaction context.
3. Impact follows when a compromised session can approve purchases or payment flows without transaction-specific binding, increasing fraud exposure and non-compliant authentication risk.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PSD2 turns payment login into a transaction-integrity control, not just an authentication control. The article is really about where checkout identity proves the legitimacy of a payment, not merely the legitimacy of a session. That distinction matters because payment risk is created when approval and identity drift apart. Practitioners should treat the payment flow as part of the identity plane, not a downstream UI step.

Device-bound possession changes the trust boundary for consumer payments. A private key tied to a device is materially different from a shared secret that can be phished, reused, or replayed. In PSD2 programmes, that shifts assurance from something the user remembers to something the user physically controls. The implication is that payment access governance increasingly depends on device trust and local confirmation, not password policy.

Dynamic linking is the control that prevents generic authentication from becoming generic payment approval. If the amount or payee can change after authorisation, the original approval loses meaning. That is why transaction binding deserves the same design attention as login assurance. Practitioners should view dynamic linking as a core anti-fraud control, not a compliance footnote.

Passwordless adoption in payments is also an anti-recovery strategy. Many identity programmes improve the primary login path but leave recovery weak enough to undo the gain. The article correctly points to eliminating passwords even from recovery, because recovery often becomes the easiest path back into high-value accounts. For payment and CIAM teams, recovery governance is part of the payment trust model.

PSD2 compliance exposes the gap between consumer convenience and regulated assurance. The market temptation is to treat friction reduction and strong authentication as opposites. In practice, well-designed passwordless flows can reduce both password exposure and checkout abandonment. The lesson for identity programmes is that usability only becomes a security compromise when the architecture still depends on reusable secrets.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Transaction-bound identity is the real PSD2 lesson. Payment teams should assume that generic login assurance is insufficient once money movement is involved. The governing question is whether approval is anchored to the transaction itself, not whether a second factor appeared somewhere in the flow.

Passwordless design changes the economics of checkout abuse because it removes the most reusable credential class from high-value payment journeys. For practitioners, that means recovery, device trust, and transaction binding must be designed as one control surface, not separate projects.

For practitioners

• Map checkout flows to PSD2 factor requirements Document where possession, inherence, and transaction-specific approval are proven in the payment journey. Identify any step that still relies on a password or generic session trust.
• Bind payment approval to amount and payee Require dynamic linking so any change to the recipient or amount invalidates the approval code and forces reauthorisation.
• Replace reusable passwords in payment access Use device-bound credentials with local user verification so the primary login path cannot be replayed or phished like a shared secret.
• Harden recovery for high-value payment accounts Review fallback and recovery paths separately from the primary login flow so password removal is not undone by weak reset or support processes.
• Test non-compliant transaction handling Verify that checkout flows fail safely when PSD2 checks are not met and that the user experience makes the reason for reauthentication clear.

Key takeaways

• PSD2 is not just a compliance checkbox, because it changes how identity must be proven inside payment flows.
• The strongest control pattern in the article is device-bound, passwordless authentication combined with dynamic linking to the amount and payee.
• For practitioners, the decisive question is whether checkout and recovery paths can prevent reusable credential abuse without creating avoidable friction.

Key terms

• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Dynamic Linking: A transaction integrity control that binds authentication to the payment amount and payee. If either changes, the authentication code is no longer valid, which helps stop substitution attacks and prevents a legitimate approval from being reused for a different transfer.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Transaction Integrity: The assurance that a banking transaction cannot be altered, redirected, or replaced after the customer or system has approved it. It depends on device trust, session protection, and monitoring across the full payment path, not only on successful login.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.