The payment service provider is accountable for implementing the required controls, including strong customer authentication, secure APIs, and monitoring for unusual behaviour. Merchants and processors should also align their integration and fraud controls so they do not create gaps at the point of authentication. Compliance is a shared operational outcome, but regulatory duty sits with the provider.
Why This Matters for Security Teams
PSD2 strong customer authentication is not just a checkout control. It is a regulated trust boundary that affects payment flows, fraud response, customer experience, and incident accountability. The payment service provider must implement the authentication mechanism, but merchants and processors can still create gaps through weak redirects, broken API integrations, or poor step-up handling. Current guidance suggests treating SCA as a shared operating model, while preserving a single accountable party.
That distinction matters because regulators do not evaluate intent, they evaluate whether the required control existed and worked under real conditions. Control owners should map the authentication journey against NIST SP 800-53 Rev 5 Security and Privacy Controls for traceability, and then test whether integrations preserve challenge, exemption, and fallback logic. NHIMG research on JetBrains GitHub plugin token exposure shows how quickly exposed credentials and weak trust boundaries can become operational failures, even when the original issue seems isolated.
In practice, many security teams encounter PSD2 gaps only after a dispute, failed audit, or fraud spike has already exposed the control weakness.
How It Works in Practice
Accountability under PSD2 follows the entity that owns the regulated payment service, not the party that merely touches the transaction. The payment service provider must ensure SCA is implemented, monitored, and evidenced. That includes authenticating the customer, protecting APIs, managing exemption logic, and making sure exceptions do not become silent bypasses. Merchants and processors remain operationally relevant because they can influence how the journey is triggered, what data is passed, and whether the user experience causes abandonment or unsafe workarounds.
A useful way to operationalise this is to separate responsibility into three layers:
-
Policy layer: define when SCA is mandatory, when exemptions are allowed, and who approves exception use.
-
Integration layer: verify redirect flows, API handoffs, and error handling so that authentication cannot be skipped accidentally.
-
Assurance layer: log authentication outcomes, monitor unusual behaviour, and test for regressions after payment changes.
This is where evidence matters. Teams should align control design with ISO/IEC 27001:2022 Information Security Management for governance discipline, while using practical breach lessons from DeepSeek breach to reinforce how exposed secrets, weak segmentation, and poor oversight can compound quickly across dependent systems. The point is not to shift blame downstream, but to ensure every party knows which controls they own and which signals prove those controls worked.
These controls tend to break down when payment journeys span multiple providers and the authentication state is lost between redirect, token exchange, and final authorisation.
Common Variations and Edge Cases
Tighter authentication controls often increase checkout friction, requiring organisations to balance fraud reduction against conversion loss and operational support burden. That tradeoff becomes more pronounced in recurring payments, low-value transactions, and delegated authentication models, where the legal and technical responsibilities are not always obvious.
Best practice is evolving, but current guidance suggests three common edge cases deserve explicit ownership mapping:
-
Merchant-initiated transactions: the provider still owns the PSD2 duty, but the merchant must preserve the correct transaction context.
-
Outsourced processors: service delegation does not transfer regulatory accountability unless the law explicitly says so.
-
Fraud tooling and exception engines: if these systems suppress challenge flows, they must be reviewed as part of the SCA control set.
NHIMG analysis of credential abuse patterns in Code Formatting Tools Credential Leaks and Hard-Coded Secrets in VSCode Extensions reinforces a broader point: delegated ecosystems fail when owners assume someone else is guarding the boundary. For PSD2, the provider remains accountable even when the customer journey is fragmented across vendors, because fragmented responsibility is not fragmented regulatory duty.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 | Clarifies who owns and is accountable for security outcomes. |
| NIST SP 800-63 | AAL2 | SCA maps to stronger authentication assurance for customer access. |
| NIST AI RMF | GOVERN | Supports accountability, oversight, and traceability for regulated outcomes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential handling failures often create authentication and API control gaps. |
Use assurance-level requirements to validate PSD2 authentication strength and step-up logic.
Related resources from NHI Mgmt Group
- Who is accountable when a business fails to meet Dutch customer identification and due diligence requirements?
- Who is accountable when remote customer verification fails to meet AML requirements?
- Who is accountable for enforcing stronger authentication controls when regulations and zero-trust requirements tighten?
- Who is accountable when a passwordless rollout fails to meet required identity assurance levels?
