PSD2 explained for merchants: mandatory rules, exemptions and why issuers still challenge payments

For any business collecting card payments online within the European Union, the second Payment Services Directive (PSD2) fundamentally altered checkout operations. Its primary objective is curtailing remote card fraud through Strong Customer Authentication (SCA). However, for everyday e-commerce, this legal framework often creates an operational tension: ensuring strict compliance without driving up cart abandonment due to unnecessary authentication screens.

Understanding how the underlying regulatory mechanisms work allows merchants to balance frictionless purchases with the requirements of payment regulations.

The two mandatory factors of Strong Customer Authentication

PSD2 mandates that to authenticate an electronic payment initiated by the payer, the card issuer must verify at least two independent elements categorized across three distinct factors:

• Knowledge: something only the customer knows, such as a password, PIN, or pre-configured security passphrase.
• Possession: something only the customer holds, such as a registered mobile device receiving a cryptographically secured push notification, a hardware token, or an authentication app.
• Inherence: something the customer is, verified through biometrics such as fingerprint scanning, facial recognition, or iris capture.

Across European payment processing, the standard technical implementation for cards is the 3D Secure protocol. The most common banking flow pairs possession with inherence (unlocking a banking app with biometric authentication after receiving a notification) or possession with knowledge (a one-time passcode delivered via SMS paired with online banking credentials).

The exemption catalog: minimizing checkout friction

The directive does not demand that every single transaction undergo a full two-factor challenge. To preserve smooth checkout flows in online payments, the Regulatory Technical Standards (RTS) establish specific exemptions that merchants and payment gateways can request during authorization:

• Low-value transactions: purchases under €30. However, the issuing bank must prompt a two-factor challenge if the cumulative total of unauthenticated charges on that card reaches €100 or once five consecutive low-value exemptions have been granted.
• Transaction Risk Analysis (TRA): allows bypassing two-factor checks on transactions up to €100, €250, or €500, provided that the overall fraud rate of the acquirer or issuer remains below the strict thresholds defined by the European Banking Authority (EBA). Acquirers maintaining exceptionally low fraud rates can leverage this exemption more frequently.
• Trusted beneficiaries (whitelisting): a cardholder can designate an online store as a trusted merchant inside their banking app after completing an initial authenticated transaction. Subsequent purchases at that store may proceed without a challenge.
• Fixed recurring transactions: in subscription models where the billing amount and recipient stay consistent, SCA is mandatory only on the initial transaction or when storing the card credential. Subsequent renewals qualify as Merchant-Initiated Transactions (MIT) and fall outside the SCA scope.

Why issuing banks still request a verification code

A common point of confusion for sales teams is why customers still face authentication prompts even when the checkout requested an exemption. The reason stems from the regulatory hierarchy: the merchant or acquirer can only request an exemption, but the issuing bank retains ultimate authorization authority.

The issuer may override the exemption request and trigger a step-up challenge (technically known as a *soft decline*) for several structural reasons:

• The issuer's internal fraud engine detects elevated risk signals, such as an unfamiliar IP subnet, suspicious device fingerprints, or atypical spending velocity.
• The cardholder has reached cumulative exemption velocity limits that only the issuing bank tracks internally.
• The issuer's internal risk policy chooses not to permit frictionless routing for specific high-risk merchant categories or specific time windows.

When a soft decline occurs, the merchant payment gateway must instantly catch the response code and seamlessly invoke the 3D Secure challenge flow without forcing the customer to restart the checkout process.

Who absorbs fraud losses across payment routes

Beyond checkout conversion, PSD2 directly dictates who bears financial liability when an unauthorized transaction or fraud dispute occurs.

When an order completes a successful two-factor authentication, a liability shift occurs. If the cardholder later submits an unauthorized charge dispute, the financial loss from the chargeback rests with the card-issuing bank, barring exceptional, documented cases of cardholder collusion.

Conversely, when a merchant successfully routes a transaction under an acquirer-backed Transaction Risk Analysis (TRA) exemption without customer authentication, the liability shift does not apply. If the transaction turns out to be fraudulent, the merchant and its acquiring partner bear the direct financial loss of the chargeback.

Practical conclusion

PSD2 should not be viewed merely as an administrative hurdle, but as an operational framework governing payment infrastructure. Enforcing full authentication across all orders completely eliminates chargeback fraud liability, yet it introduces measurable friction that dampens conversion rates. Conversely, requesting exemptions blindly can lead to elevated declines from cautious issuers or unhedged dispute costs. Regularly auditing gateway configurations to correctly process soft declines and selectively deploying TRA exemptions represents the most reliable path to safeguarding revenue while maintaining a smooth buying experience.