PSD2 Compliance Guide for Payment Developers

What PSD2 Actually Requires From Your Code

The Revised Payment Services Directive (PSD2) reshaped how payments work across the European Economic Area. If you build or maintain payment systems that serve European customers, PSD2 compliance is not optional. It touches authentication flows, data access, and the relationship between banks, merchants, and third-party providers.

This guide covers what matters from an implementation perspective, not the legal theory.

The Three Pillars of PSD2

1. Strong Customer Authentication (SCA)

SCA requires two-factor authentication for electronic payments. The two factors must come from different categories:

• Knowledge - something the customer knows (password, PIN)
• Possession - something the customer has (phone, hardware token)
• Inherence - something the customer is (fingerprint, face recognition)

Your payment flow must support SCA for all customer-initiated transactions unless an exemption applies. In practice, this means integrating 3D Secure 2 for card payments and supporting bank-side authentication for direct debits and transfers.

SCA exemptions you can request:

• Transactions under 30 EUR (up to a cumulative limit)
• Recurring payments of the same amount to the same payee (after the first authenticated payment)
• Trusted beneficiaries whitelisted by the customer
• Low-risk transactions based on the acquirer's fraud rate (Transaction Risk Analysis)
• Merchant-initiated transactions where the customer is not present

Your PSP handles most exemption signaling, but your system needs to pass the right flags and handle soft declines when an exemption is rejected.

2. Open Banking and Third-Party Access

PSD2 created two new regulated roles:

• AISP (Account Information Service Provider) - can read account data with customer consent
• PISP (Payment Initiation Service Provider) - can initiate payments from customer accounts

Banks must provide APIs for these services. If you are building an AISP or PISP, you need to:

• Register with your national financial authority
• Obtain an eIDAS certificate for identification
• Implement the bank APIs (most follow the Berlin Group NextGenPSD2 spec, though implementations vary wildly)
• Manage customer consent with explicit opt-in and revocation

3. Consumer Protection and Transparency

PSD2 tightened rules around surcharging, refund rights, and transaction transparency. For developers, the key impact is:

• No surcharging on consumer debit and credit cards within the EEA
• Clear communication of all fees before payment confirmation
• Immediate refund rights for unauthorized transactions

Practical Implementation Steps

Handling SCA in Your Payment Flow

The most common approach is delegating SCA to your PSP through 3D Secure 2. Here is a typical flow:

1. Customer submits payment details on your checkout page
2. Your server creates a payment with your PSP, indicating SCA is required
3. The PSP returns a redirect URL or an embeddable authentication challenge
4. The customer completes authentication (biometric, SMS code, banking app)
5. Your server receives a webhook confirming the payment status
6. You fulfill the order

Critical detail: Always handle the pending state. SCA introduces asynchronous authentication, meaning payments are not instant. Your system must support:

• Holding orders in a pending state while authentication completes
• Processing webhook callbacks that arrive minutes or even hours later
• Handling expired authentication attempts gracefully

Managing Consent for Open Banking

If you access bank accounts through PSD2 APIs, consent management is central:

// Consent lifecycle
1. Request consent -> Customer authorizes at their bank
2. Store consent reference + expiry
3. Use consent to fetch data (90-day access window typical)
4. Re-request consent before expiry
5. Handle revocation callbacks from the bank

Store consent tokens securely and track their expiration. Most PSD2 consents last 90 days, after which the customer must re-authenticate. Design your UX to handle re-consent smoothly rather than surprising users with a broken flow.

Soft Declines and Fallback

When a payment is declined because SCA was not performed (a soft decline), your system needs a retry path:

1. Detect the soft decline from the PSP response or webhook
2. Redirect the customer to the SCA challenge
3. Retry the payment after successful authentication

Do not simply fail the transaction. Soft declines are expected and recoverable.

Testing PSD2 Flows

Testing SCA flows is tricky because they involve bank-side authentication:

• Use your PSP's test/sandbox environment with simulated SCA challenges
• Test all three outcomes: success, failure, and timeout/abandonment
• Test exemption flows to verify correct behavior when exemptions are granted or rejected
• Simulate webhook delays to ensure your system handles async completion

Common PSD2 Mistakes

• Assuming all transactions need SCA. Apply exemptions where appropriate to reduce friction.
• Not handling the async nature of SCA. Your checkout must work when authentication takes time.
• Ignoring soft declines. These are recoverable, treat them as retryable events.
• Storing consent tokens without expiry tracking. Stale consents cause silent failures.
• Hardcoding bank API specifics. Each bank implements PSD2 APIs slightly differently. Abstract your integration layer.

PSD2 compliance is not a one-time checkbox. As banks update their implementations and the regulatory landscape evolves toward PSD3, your payment system needs to be adaptable. Build for flexibility, test thoroughly, and keep your PSP integration layer clean.