top of page

Best Authentication Methods for PSD2 Compliance

  • Writer: David Pop
    David Pop
  • 17 hours ago
  • 22 min read
Best Authentication Methods for PSD2 Compliance: Elixir/Erlang Guide Cover

Strong Customer Authentication (SCA) under the Payment Services Directive 2 (PSD2) has fundamentally changed how payment systems must verify user identity in the European Economic Area. For companies building real-time payment systems, especially those using Erlang/Elixir for high-throughput, fault-tolerant architectures, implementing PSD2-compliant authentication requires careful consideration of security, performance, and user experience.


This guide explores the technical architecture and implementation patterns for PSD2-compliant authentication methods, with a focus on building scalable, reliable systems that meet regulatory requirements without sacrificing performance. We'll examine cryptographic authentication using FIDO2/WebAuthn, biometric verification, 3D Secure 2.0 integration, and the critical concept of dynamic linking that separates compliant from non-compliant implementations.


What is PSD2 Strong Customer Authentication?

The Payment Services Directive 2 (PSD2) is European regulation designed to increase security in electronic payments and protect consumers from fraud. The centerpiece of PSD2's security framework is Strong Customer Authentication (SCA), which took effect on September 14, 2019, with enforcement ramping up through 2021.


SCA Core Requirements:

1. Knowledge (Something the user knows)

  • Password or passphrase

  • PIN code

  • Answers to security questions

  • Secret patterns

2. Possession (Something the user has)

  • Mobile phone (for app-based approval or OTP)

  • Hardware tokens or smart cards

  • A trusted, registered device

  • Chip-enabled payment card

3. Inherence (Something the user is)

  • Fingerprint

  • Face ID

  • Iris/retina scan

  • Voice recognition

  • Behavioral biometrics (typing style, device behavior)


PSD2 doesn’t just ask for “two factors.” It requires that those factors don’t depend on each other. If one gets compromised, it shouldn’t automatically weaken the other. For example:

  • Valid combo: Mobile device (possession) + fingerprint (inherence)

  • Not valid: Password + security question (both “knowledge”)

  • Risky: SMS OTP if the phone number can be hijacked via SIM swap


This independence requirement is meant to stop attackers from bypassing SCA by exploiting a single weak point.


Dynamic Linking: The Critical Component

For payment transactions, SCA must also include dynamic linking, a mechanism that cryptographically binds the authentication to a specific transaction. In simple terms, when a user approves a payment:

  • The authentication can only be used for that exact transaction

  • The amount and recipient can’t be changed afterward

  • The user sees the transaction details when authenticating


This is what makes PSD2-compliant SCA stronger than typical 2FA. A basic fingerprint prompt alone isn’t enough, unless the fingerprint verification is tied directly to the specific transaction details, the system does not meet PSD2 requirements.


Why Your Authentication Layer Can Make or Break a Distributed Payment System

For companies building payment infrastructure on Erlang/Elixir, platforms designed for massive concurrency, fault tolerance, and real-time responsiveness, PSD2 authentication introduces specific architectural challenges:


Latency Constraints: Authentication flows must complete in milliseconds, not seconds. Every 100ms delay in checkout reduces conversion by approximately 1%. Your authentication layer cannot add perceptible lag to payment processing.

Fault Tolerance: Authentication services must maintain availability even during partial system failures. Using Erlang's supervision trees and OTP patterns, you can design authentication modules that gracefully degrade rather than fail completely.

Concurrency: Payment systems handle thousands of concurrent authentication requests. Erlang's lightweight processes and message-passing model make it ideal for managing isolated authentication sessions without resource contention.

Transaction Integrity: Dynamic linking requires cryptographic operations that must remain atomic with transaction creation—a perfect use case for Erlang's ACID-compliant database transactions and process isolation.

Regulatory Compliance: Audit logging, consent management, and authentication factor tracking must be built into the system architecture from day one, not bolted on later.


Core Authentication Methods for PSD2 Compliance



1. FIDO2/WebAuthn Passkeys: The Gold Standard for PSD2-Compliant Authentication

Passkeys based on the FIDO2/WebAuthn standards are becoming the default choice for modern payment authentication. Instead of relying on passwords or vulnerable SMS codes, passkeys use public-key cryptography tied to the user’s device. The private key never leaves the device (Secure Enclave, TPM, or TEE), while only the public key is stored on your backend.

For distributed, high-throughput payment systems, this creates a secure, fast, and PSD2-aligned authentication layer that scales without introducing friction.


Why Passkeys Are the Best-fit for PSD2 + Modern Payment Architecture

  • Meets two independent factors: Possession (device) + either inherence (biometric) or knowledge (PIN)

  • Phishing-resistant by design — credentials cannot be intercepted or reused

  • Eliminates password overhead — no resets, no password storage, no credential stuffing

  • Supports PSD2 dynamic linking through signed, transaction-bound challenges

  • Fast UX — users authenticate in 1–2 seconds

  • Fully supported across major browsers, OSes, and device ecosystems


Passkeys solve both sides of the PSD2 problem: high security + low friction.


How the Technical Flow Works

Registration

  • Device generates a key pair

    • Private key: stored securely on device

    • Public key: saved on your server

  • No secrets ever travel over the network


Authentication

  1. Your server creates a unique challenge + embeds transaction details (amount, payee)

  2. The device signs the challenge using the private key, gated by biometric/PIN

  3. Server verifies the signature using its stored public key

  4. Server confirms that the signed challenge matches the transaction — ensuring dynamic linking

This flow satisfies SCA, independence, and dynamic linking in a clean, standardized way.


How Passkeys Meet PSD2 Requirements

  • Possession: Device contains the private key

  • Inherence/Knowledge: Biometric or PIN required to unlock the private key

  • Dynamic Linking: Transaction details included in the signed challenge

  • Independence:

    • Private key compromise ≠ biometric/PIN compromise

    • Biometric compromise ≠ private key access

This is why regulators consistently view FIDO2 passkeys as a robust SCA method.


Implementation Notes for High-Throughput Systems

To keep authentication under 100ms end-to-end:

  • Use EdDSA (Ed25519) for fast signature verification

  • Cache public keys in Redis for 1h to avoid database hits

  • Set challenge expiration (~5 minutes) to block replay attacks

  • Store challenge metadata with transaction IDs for audit requirements


These optimizations keep auth lightweight even under heavy concurrency.

For a deeper dive into passkey implementation, including key storage, cross-device synchronization, and fallback mechanisms, see our comprehensive guide: Passkey Authentication in Payment Systems: A Practical Guide for 2026.


2. Biometric Authentication with Device Possession

Biometric authentication paired with a trusted device is one of the most widely adopted approaches to meeting Strong Customer Authentication (SCA) requirements. Instead of sending sensitive data to your servers, the biometric check happens entirely on the device. The only thing your backend receives is a cryptographic proof that the user unlocked the secure element.

For payment systems handling thousands of concurrent transactions, this model provides strong security, low friction, and a clean path to PSD2 compliance without slowing down the checkout flow.


Why This Method Works So Well in Payment Flows

  • Two independent PSD2 factors: Inherence (biometric) + possession (the hardware)

  • Fast UX — usually under 1 second

  • High security — biometrics stored and verified locally in the Secure Enclave/TEE

  • Natively supported across iOS, Android, macOS, Windows

  • Compatible with passkeys — biometrics can unlock the private key for WebAuthn


This approach gives consumers a familiar, frictionless authentication experience while maintaining regulatory integrity.


How It Satisfies PSD2 Requirements

  • Inherence: fingerprint, face scan, iris

  • Possession: the registered device (phone, laptop, tablet)

  • Dynamic Linking: transaction details must be displayed and cryptographically bound to the authentication

  • Independence:

    • Compromised biometric ≠ compromised device

    • Lost device ≠ access to user biometrics


This setup makes biometric flows one of the most intuitive ways to implement compliant SCA for mobile-first payments.


Typical Technical Architecture for Biometric Payments

1. Enrollment The user registers their biometric on their own device.

  • The biometric template stays in the Secure Enclave/TEE

  • Your server receives only:

    • Device identifier

    • Public key

    • Biometric type (face, fingerprint, iris)


2. Authentication Request Your server sends a request containing the payment details:

  • Amount

  • Currency

  • Payee information These details must be shown to the user before biometric capture.


3. Local Biometric Verification The device checks the user’s biometric locally — nothing leaves the device.


4. Signed Response The device signs:

  • The transaction hash

  • The nonce

  • Timestamp And returns the signature + device ID.


5. Server Validation Your backend checks:

  • The signature (using the device’s public key)

  • Transaction match

  • Timestamp freshness

  • Whether the device is still trusted


Implementation Example:


Security Considerations:

  1. Biometric Capture Must Be On-Device: Never transmit biometric data over the network. Verification happens locally; only authentication results are sent.

  2. Transaction Display Required: PSD2 requires the user to see transaction details during authentication. Display amount, currency, and payee on the device screen before biometric capture.

  3. Liveness Detection: Implement anti-spoofing measures to prevent photo/video replay attacks. Most modern devices include hardware-based liveness detection.

  4. Device Binding: Each device must have unique credentials. Device compromise should not compromise other user devices.

  5. Fallback Authentication: Always provide fallback methods (password + OTP, hardware token) for when biometric fails or device is lost.


For an in-depth exploration of facial biometric authentication, including liveness detection, GDPR considerations, and implementation patterns, see: Biometric Face Authentication in Payments: A Practical Guide.


3. 3D Secure 2.0 for Card Payments

3D Secure 2.0 (3DS2) is the standard way card issuers authenticate online payments in Europe. It replaces the old 3D Secure 1.0 flow and was rebuilt specifically to support PSD2’s Strong Customer Authentication (SCA) requirements. Unlike the old version, 3DS2 can approve low-risk payments without interrupting the user, while still enforcing multi-factor authentication when necessary.


Why 3DS2 Actually Matters in Real Systems

  • Required for European card payments (Visa, Mastercard, Amex, all of them)

  • Supports frictionless approvals for low-risk transactions

  • Handles SCA automatically via the issuer

  • Built-in dynamic linking for amount + merchant

  • Shifts fraud liability to the issuer when authentication succeeds


For card payments, 3DS2 isn’t optional — it’s the backbone of modern payment authentication and risk reduction.


How It Meets PSD2 Requirements

  • Multi-factor authentication: The issuer performs SCA using their own factors — typically SMS OTP, banking app biometric, or password + device.

  • Dynamic Linking: The issuer cryptographically binds the:

    • amount

    • currency

    • merchant

  • Independence of factors: Since the issuer controls the whole authentication process, factor independence is enforced by design.


Technical Architecture:

3DS2 involves multiple parties in a coordinated flow:

Customer → Merchant → 3DS Server → Directory Server → Issuer ACS → Customer

  1. Customer initiates payment on merchant checkout

  2. Merchant sends card details to their 3DS Server

  3. 3DS Server queries Directory Server (Visa/Mastercard) to check if card is enrolled

  4. Directory Server routes request to Issuer's Access Control Server (ACS)

  5. Issuer ACS performs risk assessment

    • Low risk → Frictionless approval (no customer interaction)

    • High risk → Challenge flow (customer must authenticate)

  6. Customer completes authentication if challenged (app notification, OTP, biometric)

  7. Issuer returns authentication result and cryptogram

  8. Merchant includes authentication data in authorization request to acquirer


Integration with Payment Orchestration:

For payment orchestration engines, 3DS2 must be integrated as a pre-authorization step:


3DS2 Provider Integration:

Most payment gateways provide 3DS2 as an integrated service. Here's how to integrate with multiple providers:


Performance and Latency Considerations

3DS2 can slow things down if you don’t engineer for it:

  • Frictionless: 300–800ms

  • Challenge: 30–300s depending on user interaction


To keep checkout fast:

  • Parallelize all pre-auth checks where possible

  • Set strict timeouts (fast for frictionless, long for challenge)

  • Cache enrollment status to avoid unnecessary DS lookups

  • Use webhooks instead of polling for challenge completion


With proper orchestration, 3DS2 adds minimal friction to the overall flow.


4. Hardware Tokens and App-Based MFA

Hardware tokens (like FIDO security keys, smart cards, or OTP generators) and mobile authenticator apps (e.g., Google Authenticator, Authy) are tools for “possession-based” authentication. Essentially, the user must physically have a device to prove their identity. These methods are often combined with something the user knows (password or PIN) to meet PSD2 security requirements.


Using hardware tokens or app-based MFA adds a strong layer of security beyond passwords:

  • Extremely high security – Physical tokens are resistant to remote attacks like phishing.

  • Offline usability – Hardware OTP generators work without a mobile network, which is useful in low-connectivity areas.

  • High-value transactions & corporate accounts – These methods are particularly suitable for sensitive operations.

  • Phishing resistance with FIDO keys – Modern FIDO2 keys authenticate websites and services in a way that makes phishing nearly impossible.


PSD2 Compliance:To satisfy PSD2, multi-factor authentication (MFA) typically requires:

  • Possession Factor: A physical token or a mobile device with an authenticator app.

  • Knowledge Factor: A PIN or password entered alongside the token.

  • Dynamic Linking: Transaction details can be linked to the authentication process, either displayed on the token or app, so the confirmation is transaction-specific.


Hardware Security Keys (FIDO U2F/FIDO2)

FIDO security keys, such as YubiKey, provide very strong MFA because authentication relies on the physical presence of the key and cryptographic signatures.


5. Risk-Based Authentication (RBA)

Risk-Based Authentication evaluates each transaction using contextual signals, such as device fingerprinting, customer behavior, location, velocity checks, and historical fraud patterns—to determine how risky a payment is. Instead of treating every transaction as equal, the system decides in real time whether strong authentication is necessary. When a transaction is judged to be low risk, PSD2 allows it to go through without additional friction. When it’s high risk, the user is prompted for extra authentication.


RBA is the mechanism that allows modern payment systems to stay both secure and user-friendly. It helps merchants reduce unnecessary authentication steps for legitimate customers, which improves conversion rates and reduces checkout abandonment. At the same time, it focuses additional security measures only on transactions that show signs of fraud. PSD2 explicitly supports this approach by allowing exemptions when risk is demonstrably low.


PSD2 Exemptions Supported by RBA: Risk-Based Authentication enables several PSD2 exemptions, including:

  • Low-Value Transactions: Payments under €30, as long as cumulative thresholds aren’t exceeded.

  • Transaction Risk Analysis (TRA): If the real-time fraud risk is proven to be low, SCA may be skipped.

  • Recurring Payments: After the first authenticated payment, subsequent charges for the same subscription can be exempt.

  • Trusted Beneficiaries: Customers can whitelist merchants, allowing future payments without repeated SCA.

  • Corporate Payments: Certain B2B payments using secure, regulated corporate instruments may qualify.

  • Secure Corporate Processes: Businesses with strong internal authentication flows can apply SCA exemptions at the process level.

6. Dynamic Linking: Technical Deep Dive

Dynamic linking is the mechanism that binds a user’s authentication to the exact transaction they are approving. Instead of just proving their identity, the customer is authorizing a specific payment—including the amount, currency, and the recipient. This cryptographic binding is a core PSD2 requirement for SCA-compliant payment authentication.


Without dynamic linking, an attacker who intercepts or replays an authentication response could alter the payment details without the customer noticing. That means they could change the amount, the recipient account, or reuse the authentication for a different transaction. Dynamic linking prevents these attack vectors by ensuring the authentication is mathematically tied to the exact transaction being processed.


What PSD2 Requires: To meet PSD2 requirements, an implementation must ensure:

  • The user sees the final transaction details at the moment of authentication.

  • The signed authentication data contains a hash of those details.

  • The server verifies that what the user approved matches the original transaction request.

  • The authentication cannot be reused for any other payment, even if intercepted.


Technical Implementation Summary: The core idea is simple: generate a nonce and a transaction hash, present the details to the user, have the device or authenticator sign the hash, and then verify it on the server. This ensures that the authentication and the payment are inseparable.

Your Elixir example already shows this flow: generate canonical transaction data, hash it, associate it with a unique challenge, and enforce that the signed response matches the original hash. On the client side, the transaction hash is passed into the authentication request (for example, as a WebAuthn extension) so the authenticator signs a value that the server can later verify against.


This is what makes SCA not just about identity, but about authorizing the exact payment being executed.

7. Authentication Methods to Avoid

Not all authentication approaches meet PSD2 standards or provide sufficient protection for payment flows. Some methods are outdated, easily compromised, or fail to satisfy the two-factor requirement. These should be avoided or used only with additional safeguards.


SMS OTP as the Only Possession Factor

SMS codes are highly vulnerable to modern attack techniques, SIM swapping, SS7 interception, phishing, and phone number spoofing. Delivery delays also create unnecessary friction for users. SMS cannot cryptographically link an OTP to a transaction, which makes it incompatible with dynamic linking requirements.


PSD2 Position: While regulators technically allow SMS OTP, it is broadly discouraged for high-risk or high-value transactions.


If You Cannot Avoid It: It must be paired with another factor (for example, a password), used with short validity windows, rate-limited, and monitored for SIM-swap patterns.


Email OTP

Email inboxes are compromised frequently, and access to an email address does not prove possession of the user’s current device. Emails can be opened from any location or device, often without strong authentication. Delivery delays further weaken the method.


PSD2 Position: Email OTP cannot serve as a possession factor and generally fails SCA requirements on its own.


Static Passwords Alone

A password provides only a single knowledge factor. PSD2 requires two independent factors, and passwords alone remain vulnerable to phishing, credential stuffing, and brute-force attacks.


PSD2 Position: Non-compliant. Passwords must be combined with a possession or inherence factor.

Security Questions

Security questions rely on the same factor type as a password—knowledge. Answers are often publicly available, easy to guess, or exposed through data breaches. They do not add meaningful security.

PSD2 Position: Not considered a valid second factor.


Browser Fingerprinting Alone

Fingerprinting can help identify a device, but it does not prove that the user possesses the device at authentication time. Fingerprints are also reproducible and spoofable.


Usage Recommendation: Acceptable as an additional risk signal for RBA, but not as part of SCA and not as a possession factor.


Implementation Architecture:

Graceful Degradation:

Always implement fallback paths:

8. Recommended Implementation Strategy

This section explains how to actually put everything together into a PSD2-compliant authentication architecture. Instead of simply listing methods, this gives you a structured rollout plan that developers and product teams can apply directly.


Tier 1: Primary Methods (Implement First)


Passkeys (FIDO2/WebAuthn)

Passkeys should be your default authentication method for both web and mobile payments. They’re fast, cryptographically secure, and satisfy PSD2’s requirement for two independent factors (possession + inherence/knowledge). They also support dynamic linking natively, which is critical for payment approval flows.


3D Secure 2.0

If you process card payments, 3DS2 must be part of your infrastructure. All European issuers use it, and it’s the standard way to shift liability and ensure SCA compliance for card transactions. Even if you rely on passkeys in your own ecosystem, card rails still need 3DS2 for authentication.


Tier 2: Supplementary Methods (Broaden Device and User Coverage)


Biometric + Device Registration

Ideal for mobile-first environments. Users approve payments using their fingerprint or face, backed by a registered device. This delivers excellent UX without sacrificing security, and it’s easy to integrate into iOS/Android SDKs.


Hardware Security Keys (FIDO U2F/FIDO2)

This is a high-security option meant for corporate users, administrators, and high-value accounts. Keys like YubiKeys provide phishing-resistant authentication and work well in regulated environments.


Tier 3: Fallback Methods (Edge Cases Only)


Authenticator App (TOTP)

You need at least one universal fallback for users without biometrics, incompatible devices, or legacy browsers. TOTP covers that gap. It’s not the best UX, but it's reliable and meets the “possession” requirement when combined with another factor.


Backup Codes

A final recovery layer for users who lose access to all other methods. They should be used sparingly, but they prevent lockout scenarios.


Implementation Architecture

Your Elixir strategy module shows how to orchestrate method selection in real time based on the user, device, and transaction. The idea is to:

  1. Detect which authentication methods a customer has configured.

  2. Select the strongest available option.

  3. Fall back to lower tiers if needed.

  4. For card payments, wrap the method with 3DS2 automatically.


This approach ensures consistency across all payment flows and prevents insecure fallbacks from being used when SCA is required.


The code blocks you included already illustrate this logic well, and the comments make the decision flow easy to follow.


Graceful Degradation

If the strongest available method can't be used (missing device, browser incompatibility, hardware failure), your orchestration layer needs an automatic fallback path.

The key principle is:

  • If the user failed authentication legitimately → don’t fallback.

  • If the method is unavailable because of technical issues → fallback is allowed.

Your Orchestrator module captures this idea cleanly. It first tries the optimal method, and if the method isn’t available, it switches to another method without breaking SCA rules. This preserves security without damaging real-world usability.


9. Performance Optimization for High-Throughput Systems

For systems that process thousands of authentications per second—banks, PSPs, large merchants, performance matters as much as security. This section explains how to optimize cryptographic verification, device lookups, dynamic linking checks, and risk scoring.


Multi-Layer Caching

Your caching module is designed around a three-tier structure:

  • L1 (ETS): microsecond lookups

  • L2 (Redis): millisecond lookups

  • L3 (PostgreSQL): persistent storage

This pattern ensures that the most requested data (like public keys) rarely hits the database. It also reduces overall latency and improves P95 time, which is crucial for payment authorization.


Connection Pooling

High authentication throughput requires large and well-tuned database and Redis pools. Your application setup includes aggressive pool sizing and queue parameters, which is exactly what high-load systems need to avoid timeouts under sudden transaction spikes.


Parallel Processing

Signature verification, timestamp validation, transaction binding checks, and device trust checks can be processed concurrently. Your ParallelVerifier module demonstrates this approach by running independent checks asynchronously and joining results with a low timeout.

This is critical when a single authentication must complete within 150–200ms.


Precomputation

Your Precompute module uses idle time to warm up caches and refresh risk models. This is effective for improving P95 performance because the expensive cryptographic or ML operations happen before the user starts the flow.


Performance Targets

A realistic performance budget for European payment flows is something like:

  • Passkey verification: < 50ms

  • Biometric/device authentication: < 100ms

  • 3DS2: < 800ms (issuer-dependent)

  • Risk scoring: < 20ms

  • Database writes: < 10ms

  • End-to-end P95 target: ~200ms


Your table reflects these targets well and matches what regulated PSPs use.


10. Regulatory Compliance and Audit Logging

PSD2 requires a complete audit trail for every authentication event. The goal is not only to store logs but to be able to reconstruct the entire SCA flow, demonstrate dynamic linking, show the factors used, and justify exemptions.


Audit Logging Requirements

Your AuditLog module covers all important fields:

  • customer identifiers (hashed for privacy)

  • transaction details

  • method used

  • factors used

  • exemption information

  • dynamic linking verification

  • risk score

  • device context

  • final result

It also writes to:

  • an append-only datastore

  • a SIEM or monitoring pipeline

This satisfies PSD2 auditability requirements and supports incident response.


Regulatory Reporting

Your reporting module aggregates the logs to create compliance metrics:

  • SCA rates

  • exemption usage

  • authentication success/failure breakdown

  • dynamic linking verification

  • method usage distribution

  • compliance rate

This is the type of reporting regulators expect during audits, and it also helps internal security teams detect suspicious authentication patterns.


Data Retention

PSD2 requires retaining authentication logs for 5 years. Your retention module:

  • archives logs older than 1 year

  • moves them to cold storage

  • deletes logs older than 5 years

  • logs all deletion events for compliance

This is exactly the pattern financial institutions use.


11. Migration Path: Moving to PSD2-Compliant Authentication

If your system currently relies on password-only or SMS OTP flows, you need a phased migration plan. Your migration path is structured the right way:


Phase 1 — Assessment

Map your current flows and identify all PSD2 gaps. This helps estimate the technical and regulatory work ahead.


Phase 2 — Infrastructure Setup

Deploy WebAuthn/FIDO2, 3DS2, audit logging, and risk scoring components. These systems form the backbone of PSD2 compliance.


Phase 3 — Parallel Deployment

Introduce compliant methods as opt-in for new and existing users. Maintain the old system while testing the new one at scale.


Phase 4 — Gradual Migration

Encourage and eventually require migration to compliant methods. High-value accounts should migrate earlier.


Phase 5 — Hard Cutover

Disable non-compliant methods and enforce SCA for all transactions. After this point, the old system is removed or left only for non-payment flows.


Your Migration module correctly handles:

  • checking compliance status

  • computing urgency based on deadlines

  • prompting upgrades with severity levels

  • recommending the best method (passkeys)

This is a realistic migration strategy used by PSPs and banks when moving to strong customer authentication.


Conclusion

PSD2 Strong Customer Authentication represents a fundamental shift in how payment systems verify user identity and authorize transactions. For companies building high-performance payment infrastructure, especially those leveraging Erlang/Elixir for distributed, real-time systems, implementing PSD2 compliance is both a regulatory requirement and an opportunity to build genuinely better authentication experiences.


For new systems, building compliance from the ground up is the most efficient path. For legacy systems, a phased migration—running compliant methods in parallel and gradually prompting users to upgrade, allows a smooth transition without disrupting operations. High-performance environments benefit from architectural optimizations such as multi-layer caching, parallel verification, and precomputation, which make sub-200ms authentication achievable even under heavy load.


Looking ahead, PSD2 principles are becoming a global standard. Organizations that invest in strong, scalable authentication today not only meet regulatory requirements but also improve conversion rates, reduce fraud, and gain customer trust. The Erlang/Elixir-based patterns in this guide, dynamic linking, orchestration, caching, and parallel verification, provide a solid foundation for building payment systems capable of handling millions of secure transactions while delivering a seamless user experience.


PSD2 Authentication Implementation FAQ


1. Can I use passwordless authentication (passkeys only) and still be PSD2 compliant?

Yes, passkeys are one of the strongest PSD2-compliant authentication methods. When using FIDO2/WebAuthn passkeys, you satisfy two independent factors: possession (the device holding the private key) and inherence or knowledge (biometric or device PIN required to unlock the key). This meets PSD2's requirement for two independent authentication factors. Additionally, passkeys support dynamic linking natively when properly implemented—the authentication is cryptographically bound to the specific transaction details, satisfying PSD2's transaction binding requirement.


2. How do I implement dynamic linking for mobile biometric authentication where the user is authenticating on their phone?

For mobile biometric authentication with dynamic linking: (1) Display the transaction details (amount, currency, payee) on the phone screen before requesting biometric authentication, (2) Include a hash of the transaction details in the authentication challenge, (3) After the user completes biometric verification, the device signs a response that includes both the transaction hash and a timestamp, (4) Your server verifies that the transaction hash in the signed response matches the original transaction. This ensures the biometric authentication is cryptographically bound to that specific transaction. The key is that the user must see the transaction details on the device screen before authentication, and the signed response must prove they authenticated for that specific transaction.


3. What's the minimum latency I can achieve for passkey authentication in a high-throughput Erlang/Elixir payment system?

With proper optimization, you can achieve sub-50ms server-side passkey verification latency. The breakdown: challenge generation <5ms, public key retrieval from cache <2ms (ETS/Redis), signature verification 10-20ms (Ed25519), transaction binding verification <5ms, audit logging (async) 0ms. The total comes to 20-30ms in ideal conditions, 50-100ms at P95. Client-side operations (biometric capture, signing) add another 500-1500ms but happen in parallel with your backend processing. The keys to achieving this performance are: (1) cache public keys aggressively (>95% hit rate), (2) use Ed25519 signatures rather than RSA for faster verification, (3) run independent verification steps in parallel using Task.async_many, (4) implement multi-layer caching (ETS → Redis → PostgreSQL), and (5) pre-warm caches during idle periods.


4. How do I handle the scenario where a customer's phone is lost or broken and they can't complete biometric authentication?

Implement multiple recovery mechanisms: (1) Backup authentication methods: Allow customers to register multiple devices or methods (passkey on phone + passkey on laptop + TOTP app as fallback), (2) Recovery codes: Generate one-time-use backup codes during account setup that customers can print and store securely, (3) Account recovery flow: Verified email/SMS recovery combined with identity verification questions and mandatory delay period (24-48 hours) before granting access, (4) Customer support escalation: For high-value accounts, offer verified customer support that can reset authentication after confirming identity through multiple channels. The critical principle is that recovery mechanisms should be nearly as secure as primary authentication—don't undermine strong authentication with weak recovery paths. For payment systems, consider requiring in-person verification at a physical location for high-risk recovery scenarios.


5. Are there any PSD2 exemptions that allow skipping SCA for certain types of transactions?

Yes, PSD2 defines several SCA exemptions: (1) Low-value payments: Transactions under €30 (with limits: cumulative €100 or 5 transactions since last SCA), (2) Transaction Risk Analysis (TRA): Real-time risk assessment showing fraud probability below thresholds (€100/€250/€500 depending on PSP fraud rates), (3) Recurring payments: Subsequent charges in a subscription after initial SCA, (4) Trusted beneficiaries: Payments to recipients the customer has whitelisted, (5) Corporate payment instruments: B2B dedicated payment instruments, (6) Unattended terminals: Parking meters, toll booths where SCA isn't practical. However, exemptions are requested by merchants/PSPs but decided by issuers—the card issuer can reject exemption requests and require SCA anyway. You must track exemption usage (especially low-value cumulative limits) and be prepared to trigger SCA when limits are exceeded or issuers decline exemptions.


6. How should I store and manage customer public keys for passkey authentication in a distributed Erlang cluster?

Use a multi-layer caching strategy with PostgreSQL as the source of truth: (1) PostgreSQL stores all public keys permanently with indexes on user_id and credential_id, (2) Redis caches frequently accessed keys with 1-hour TTL for cross-instance sharing, (3) ETS provides per-instance in-memory cache for sub-millisecond access with 10-15 minute TTL, (4) Mnesia (optional) for distributed cache across Erlang nodes if you don't want Redis dependency. The lookup flow is: check ETS → check Redis → query PostgreSQL → populate caches on the way back. For writes (registering new passkeys), use the outbox pattern to ensure atomic database writes with event publishing. Public keys are not sensitive (unlike private keys), so aggressive caching is safe. The main consideration is cache invalidation when keys are revoked—use pub/sub (Postgres NOTIFY/LISTEN or Redis pub/sub) to propagate revocations across all instances immediately.


7. What's the recommended approach for implementing 3D Secure 2.0 when I'm already using a payment gateway like Stripe or Adyen?

Modern payment gateways provide 3DS2 as an integrated service, making implementation straightforward: (1) Enable 3DS2 in gateway settings: Configure your gateway account to use 3DS2 for applicable transactions, (2) Pass additional context: Send device/browser information (IP address, user agent, screen resolution, timezone) to improve frictionless approval rates, (3) Handle challenge flows: When the issuer requires a challenge, redirect the customer to the authentication page and handle the callback, (4) Include authentication data: After successful 3DS authentication, include the cryptogram (ECI, CAVV, XID) in your payment authorization request, (5) Implement liability shift verification: Confirm that liability has shifted to the issuer by checking the authentication response. Most gateways provide SDKs that abstract away the complexity—for example, Stripe's Payment Intents API handles 3DS2 automatically when required. The main work is on the frontend to handle the challenge flow and on the backend to properly configure and verify the authentication results.


8. How do I balance security and user experience when implementing PSD2 authentication—when should I require SCA vs. use exemptions?

Use a risk-based decision matrix: (1) Always require SCA: First transaction with a new card, high-value transactions (>€250), suspicious risk signals (VPN, velocity anomalies, geographic mismatches), customer requests additional security, (2) Consider exemptions: Returning customers with established history, low-value transactions (<€30), low risk scores (<0.1), trusted devices, transactions matching normal patterns, (3) Monitor and adjust: Track exemption approval rates by issuer (some issuers reject most exemptions), measure impact on conversion rates (exemptions should increase conversion by 15-25%), A/B test exemption thresholds, continuously refine risk models. The key insight is that SCA isn't always friction—modern methods like passkeys and biometrics complete in 1-2 seconds and customers often prefer the additional security assurance. The real friction comes from clunky implementations (SMS OTP delays, confusing redirects), not from SCA itself. Focus on implementing elegant SCA flows rather than maximizing exemptions.


9. What are the implications of PSD2 authentication for cross-border payments between EU and non-EU countries?

PSD2 SCA applies to payment service providers (PSPs) established in the European Economic Area and transactions involving EU cardholders or accounts. The implications: (1) EU cardholder, EU merchant: Full PSD2 compliance required regardless of PSP location, (2) EU cardholder, non-EU merchant: If the acquiring PSP is in the EU, SCA is required; if not, it's recommended but enforcement varies, (3) Non-EU cardholder, EU merchant: SCA is recommended as best practice but not legally required, (4) Card network rules: Visa and Mastercard require 3DS2 for European transactions regardless of PSD2 legal applicability—so effectively you need SCA-equivalent authentication for any European card transaction. For non-card payments (bank transfers, wallets), jurisdiction of the PSP and customer account determine applicability. Best practice: implement PSD2-compliant authentication for all European transactions and offer it as an option for all customers globally—it's becoming the de facto standard for secure digital payments worldwide.


10. Can I use behavioral biometrics (typing patterns, mouse movements) as one of the two PSD2 authentication factors?

Behavioral biometrics are not currently recognized as a standalone PSD2 authentication factor. While they provide valuable risk signals for fraud detection and can strengthen your overall security posture, they don't satisfy the inherence factor requirement under PSD2. The reasons: (1) Continuous verification vs. discrete authentication: Behavioral biometrics work best as continuous background verification, not as a discrete authentication event, (2) Lower reliability: Typing patterns and mouse movements have higher false rejection rates than physiological biometrics, (3) Regulatory uncertainty: No clear guidance that behavioral biometrics meet the "inherence" factor requirement. However, you should absolutely use behavioral biometrics as part of your risk assessment engine—they're excellent for detecting anomalies and can inform when to step up authentication or flag potentially fraudulent sessions. Use them to feed your Transaction Risk Analysis (TRA) model, which can then justify SCA exemptions for low-risk transactions. But don't rely on them as one of your two primary PSD2 factors—use physiological biometrics (fingerprint, face), possession (device/token), and knowledge (password/PIN) instead.


11. Which companies are recognized as top PSD2 compliance implementation service providers, and what solutions do they offer?

The top PSD2 compliance implementation providers include Crafting Software, alongside payment platforms and specialized PSD2 API providers such as Stripe, Adyen, Finexer, and Finologee. Crafting Software offers modular PSD2 solutions with strong API management, developer SDKs, and end-to-end compliance support, including SCA, consent management, and transaction monitoring. Their platform is designed to integrate quickly into existing banking or fintech systems while maintaining regulatory compliance. Stripe and Adyen handle PSD2 compliance internally, integrating 3D Secure 2 (SCA), transaction risk analysis, and exemption handling directly into payment workflows. Finexer and Finologee provide PSD2-compliant API platforms for banks and fintechs, offering extensive bank coverage, real-time account data access, instant payment initiation, white-label integrations, modular XS2A functionality, API management, data aggregation, sandbox environments, and full compliance with PSD2, RTS, and GDPR, all on high-performance, scalable infrastructure supporting multiple third-party providers (TPPs).




bottom of page