PSD3 and PSR: What Merchants Actually Need to Change

Under PSD2, the day-to-day conduct rules — refund timing, fraud liability, complaint handling — were set by a directive. Directives don't apply directly. Each of the 27 member states had to transpose PSD2 into its own national law, and each did so with its own timing, its own gaps, and its own local interpretation. A merchant operating in five EU countries was, in effect, operating under five slightly different rulebooks even though they all claimed to implement "the same" directive.

The new package splits the work differently. PSD3 remains a directive and mainly covers licensing, supervision, and market access for payment institutions — the kind of thing that affects your PSP's regulatory status, not your checkout. The conduct rules that actually touch merchants — fraud liability, refund obligations, authentication requirements, complaint handling — move into the PSR, a regulation. Regulations apply directly and identically in every member state, with no national transposition step and no room for local drafting quirks.

According to legal analysis of the agreed texts, this is a deliberate response to the fragmentation problem PSD2 created — the PSR is designed to give merchants and PSPs one uniform rulebook rather than 27 local variants (Freshfields' overview of the agreed texts). For merchants, that means the compliance review you run for your German entity should, once the PSR applies, produce the same answers as the review for your Irish or Portuguese entity. That's a genuine simplification, but it also means there's no longer a "the local regulator is lenient about this" argument to fall back on.

PSD2's liability rules were built around a fairly narrow idea of an "unauthorized" transaction — one the customer didn't approve. Fraud has moved on since then. Social engineering scams, where a fraudster impersonates a bank employee or convinces a customer to authorize a transfer directly, technically produce an "authorized" transaction under the old framework, which historically left the customer (and by extension, the merchant relying on that payment) with less recourse.

The PSR expands liability in a few directions that matter to merchants:

• Spoofing-based fraud — where a fraudster impersonates a PSP's staff or brand — shifts more liability onto payment service providers, rather than leaving the customer to absorb the loss.
• Failures to offer or correctly apply strong customer authentication (SCA) put liability on whichever party in the chain failed to apply it properly, which includes acquirers and, in some flows, merchants who circumvent authentication.
• Slow fraud reporting handling by a PSP can itself create liability, which is meant to push banks and PSPs toward faster fraud-report turnaround rather than treating every claim as a lengthy investigation.

For a merchant, the practical effect is that fraud disputes will increasingly turn on evidence of what happened during authentication, not just on whether the customer says they didn't authorize the payment. That makes your authentication logs and SCA outcome data part of your dispute evidence, not just a compliance record you keep and forget about.

One of the most concrete changes for checkout flows involves verifying that the name on an account actually matches who the payer thinks they're sending money to. This builds on the Verification of Payee (VoP) mechanism already required for instant credit transfers under the EU's Instant Payments Regulation, and the new payments package extends that logic further across payment services.

In practice, VoP means a payer's bank checks the account holder name against the IBAN before a transfer completes, and flags a mismatch — a "no match" or "close match" — back to the payer before they confirm the payment. That's aimed squarely at authorized push payment fraud, where a customer is tricked into transferring money to an account that isn't who they think it is.

For merchants, this affects any flow where a customer initiates a bank transfer to pay you — account-to-account payment methods, open banking-initiated payments, or any checkout step where you display your own payee details for a customer to complete a transfer:

• The legal name registered on your merchant bank account needs to exactly match the trading name customers see on your checkout page, or customers will start seeing mismatch warnings that look like fraud signals even when nothing is wrong.
• If you operate under a trading name different from your legal entity name, now is the time to either align them or make sure your checkout clearly explains the discrepancy before a customer hits a VoP warning mid-payment.
• Any internal documentation that lists your settlement account details for reconciliation purposes should be checked against what's actually registered with your bank, since a stale record will surface as a mismatch to every customer using a transfer-based method.

This is a case where a five-minute administrative check — confirming your bank account's registered name matches your storefront branding — avoids a wave of customer-facing confusion once VoP-style checks are broadly in force.

PSD2 gave account-servicing banks two options for exposing account data to third parties: a dedicated API, or a fallback interface built on their existing customer-facing online banking screens. In practice, fallback interfaces were often slower, less reliable, and inconsistently maintained, which made open banking-based checkout flows — pay-by-bank options, account information for risk scoring, and similar features — less dependable than card payments.

The new framework tightens this. Banks will face clearer, more enforceable obligations around dedicated interface performance — closer to parity with the reliability of their own customer-facing channels, with defined expectations around uptime and response times rather than the loosely enforced "reasonable effort" standard that characterized parts of PSD2 implementation (MoFo's analysis of the PSD3/PSR developments).

For merchants who offer or are considering pay-by-bank or other account-to-account checkout options, this matters in two ways:

• Fewer failed or timed-out authorization attempts should mean fewer abandoned carts on transfer-based payment methods, which historically underperformed cards on completion rate partly because of interface reliability.
• If you rely on account information services for risk decisions — verifying account ownership or checking balances before shipping high-value orders — those data feeds should become more consistent to build workflows around, rather than something you have to build retry logic and fallback handling for.

None of this removes the need to test your integration against real bank behavior once the rules are in force. It does mean the baseline reliability you're testing against should improve.

This is the part that gets skipped in most legal summaries. Here's what moves on your side of the desk.

Your PSP and acquirer contracts. Review the liability allocation clauses in your existing payment services agreements. Under PSD2-era contracts, liability language often assumed the old, narrower definition of "unauthorized transaction" and the old SCA exemption rules. Once the PSR's liability provisions apply, contracts that haven't been updated may reference standards that no longer match the law, which creates ambiguity exactly when you need clarity — mid-dispute. Ask your PSP directly whether their standard merchant terms will be updated to reflect PSR liability allocation, and get the answer in writing rather than assuming it's handled.

• Your checkout flow. Three concrete changes to check:
• Confirm the legal name tied to your settlement account matches your storefront branding, to avoid unnecessary VoP mismatch warnings on transfer-based payment methods.
• Make sure your SCA challenge flow (3DS or equivalent) degrades gracefully — a customer abandoning a purchase because an authentication step failed technically, rather than because they declined it, is exactly the scenario the new liability rules are designed to catch, and you don't want to be on the wrong side of that when a dispute is reviewed.
• If you offer pay-by-bank or other account-to-account options, plan to re-test completion rates once the new API performance obligations are in force — the reliability assumptions you built your fallback logic around may no longer be the binding constraint.

• Your dispute process. The evidence that decides a fraud or chargeback dispute is shifting. Where PSD2-era disputes often turned on whether SCA was applied at all, PSR-era disputes will more often turn on how it was applied, whether a VoP check ran and what result it returned, and how quickly a fraud report was escalated. That means:
• Your support team needs access to authentication outcome logs, not just transaction status, when responding to a dispute.
• Your documentation for evidence submission should be updated to include VoP match/no-match results as a standard field, once that data exists in your transaction records.
• Internal SLAs for escalating suspected fraud reports to your PSP should tighten, since delay is itself becoming a liability factor rather than a neutral administrative step.

The shift from PSD2 to PSR is less about new obligations appearing out of nowhere and more about existing gaps closing.

Merchants who treated fraud liability, SCA, and dispute evidence as "whatever the local bank says" will find that answer no longer holds once the same regulation text applies in every member state. The work is administrative — updating contracts, checkout copy, and evidence templates — but it has to happen before general application, not after the first dispute under the new rules exposes the gap.

None of this requires re-platforming your checkout. It requires treating your PSP contract, your registered account details, and your dispute evidence templates as living documents that need a review pass on a specific timeline — which is the point of the checklist below.

The exact general application date depends on when the Official Journal publishes the final text, but the sequencing is fixed. Use this as a working timeline rather than a fixed deadline, and confirm dates once the Official Journal publication is confirmed.

• By Q4 2026 — Official Journal publication is expected (June–July 2026). Once published, calculate your firm 21-month general application date and put it on your compliance calendar. Start the PSP contract review now rather than waiting for the deadline.
• Through 2027 — Confirm your PSP's plan for updating merchant terms to reflect PSR liability allocation. Audit your settlement account's registered legal name against your checkout branding. Map which of your checkout flows use SCA and document current exemption logic so you can compare it against the finalized PSR requirements.
• Early 2028 — Test your dispute evidence process end to end: can your support team actually retrieve SCA outcome and VoP match data for a transaction on request, or does that require an engineering ticket? Fix that gap before it's tested by a live dispute.
• At general application (estimated March–April 2028) — Confirm updated PSP contracts are signed, checkout copy reflects any payee-name requirements, and your dispute documentation includes the new evidence fields. Treat the general application date as the point by which all of the above should already be running, not the point at which you start.

Cost+ runs on IC++ (Interchange Plus Plus) pricing precisely because we think merchants make better decisions when the components of a payment — interchange, scheme fee, and our markup — are visible rather than bundled. The same principle applies to regulatory change: the earlier you can see what's actually shifting in liability and evidence requirements, the less disruptive the transition. If you want to talk through how your current checkout and dispute setup lines up against the PSR timeline, contact our team or check your current fee structure against the published low-risk pricing on our site while you're reviewing contracts. </content> <tags>["Compliance", "Chargebacks", "Onboarding", "Interchange"]</tags> <cover_image_prompt>A fragmented mosaic of differently shaped tiles, each in a slightly different shade, slowly aligning and merging into one uniform seamless panel of matching geometric tiles, viewed from above.</cover_image_prompt> <inline_images>[{"id": "fraud-liability-evidence", "alt": "A single fraud dispute case file splitting into three separate evidence trails for authentication, payee verification, and PSP correspondence", "prompt": "A folder or document icon splitting into three distinct glowing geometric trails representing separate evidence records, no text or labels, abstract layout on a dark background."}, {"id": "checkout-convergence", "alt": "Two parallel checkout pathways, one for card authorization and one for bank transfer, converging into a single consistent completion point", "prompt": "Two separate winding abstract pathways made of geometric nodes, one associated with a card shape and one with a bank/arrow shape, merging into a single glowing endpoint."}]</inline_images>