How PSD3 and PSR affect marketplaces and SaaS platforms

If you run a marketplace, or you're a SaaS platform (ISV) embedding payments for your customers, there's a straightforward question behind all the regulatory noise: will my checkout or payouts actually change, and what do I need to do about it? Short answer: yes, some things will change. It's just not landing tomorrow; you've got until around 2027 to 2028 to get ready.

We covered the basics in What is PSD3 and PSR, and how do they affect your business?. This blog goes further into what it means if you're running a marketplace or a SaaS platform embedding payments, rather than a single online shop.

Where PSD3 and the PSR stand right now

As of 2026, the EU institutions have reached a provisional political agreement on PSD3 and the PSR, with technical finalisation underway. Full application across the EEA is expected around 2027 to 2028. We break the full timeline down in What is PSD3 and PSR, and how do they affect your business?

So nothing changes for your checkout tomorrow. But if you're a founder running a marketplace or a SaaS platform, this is the year to understand what's coming and start preparing, not the year to panic.

What PSD3 and PSR mean if you're a marketplace

Most marketplaces feel PSD3 through one core mechanism: how you're currently allowed to move money between buyers and sellers without holding a licence yourself.

• The commercial agent exemption is getting narrower. In some cases, depending on the local view of the regulator, this exemption currently lets a marketplace move money between buyers and sellers without its own payment licence, but only if it's genuinely representing one side. A typical marketplace doesn't do that; it treats every buyer and seller the same way and just processes whatever price they already agreed on, so most marketplaces won't qualify. And with the new update, the possibilities to use this exemption get smaller. If you don't qualify, you'll need to route payments through a regulated partner instead of holding the funds yourself. If you're already working with a regulated partner like OPP, this doesn't change anything for you.

• Fraud accountability across every seller. If one of your sellers scams a buyer and the bank has to refund them, liability shifts away from the victim and toward whoever missed an obvious warning sign. If your platform's own fraud monitoring didn't catch it, that scrutiny lands on you, and your payment partner may raise fees, tighten your contract, or restrict your account if it keeps happening.

• Liability for fraudulent content you don't remove. If a fraudulent seller or listing on your marketplace scams a customer, and you are informed that the content is fraudulent but fail to remove it, the new PSR can make your platform liable to the payment provider for the amount it reimbursed to the customer. Very large online platforms and search engines will also have to verify that advertisers offering financial services are authorised or exempt in the relevant market, or are advertising on behalf of an authorised or exempt provider.

What PSD3 and PSR mean if you're a SaaS platform (ISV)

Marketplaces and SaaS platforms hit PSD3 from different angles, but the underlying pressure is the same: tighter scrutiny on who's actually handling the money.

SaaS platforms that embed payments typically do so through a payment facilitation (PayFac) model, meaning a licensed payment institution (PI) or e-money institution (EMI) handles the regulatory heavy lifting while you handle the product, rather than holding a licence yourself.

What's changing: PSD3 and the PSR introduce clearer rules and stronger oversight around the different parties involved in providing payment services. What this means for a SaaS platform depends on how its payment setup is structured and what responsibilities sit with the platform versus its licensed payment partner. 

In practice, that may mean tighter oversight, registration, and contractual requirements from your licensed partner, so it's worth confirming how the new rules apply to your specific setup rather than assuming it remains unchanged.

• Merchant onboarding and KYC. This depends on who actually runs onboarding. If your licensed partner onboards your merchants directly, this mostly isn't your problem. If you run onboarding yourself under your partner's oversight, expect them to ask for a more robust, better-documented KYC as supervisory scrutiny increases, without slowing down how fast your merchants can sign up.

• Fraud accountability. If one of your merchants scams a customer through your embedded checkout and the bank has to refund them, liability shifts away from the victim and toward whoever missed an obvious warning sign. If your platform's own fraud monitoring didn't catch it, that scrutiny lands on you, and your payment partner may raise fees, tighten your contract, or restrict your account if it keeps happening.

• Choosing the right payment partner matters more, not less. Choose one that's already built for PSD3 and the PSR, like OPP, so your merchant onboarding, KYC, and payout flows don't need reworking when the rules formally land.

How PSD3 changes fraud liability

If a bank or payment provider misses an obvious spoofing attempt (a scammer impersonating a trusted source, like a bank or supplier, to trick someone into paying), and a customer, seller, or merchant gets defrauded as a result, liability can shift away from the person who was scammed. 

For marketplaces and SaaS platforms alike, this raises the bar on the fraud signals your payment stack needs to catch and act on, with the European Banking Authority (EBA) expected to finalise the technical standards behind this.

How PSD3 changes Strong Customer Authentication (SCA)

PSD2 already lets banks skip the extra two-factor check at checkout when a transaction is rated low-risk, known as risk-based exemptions from Strong Customer Authentication. This covers things like low-value transactions, trusted beneficiaries, and transaction risk analysis based on real-time fraud scoring, among others. 

The problem has been consistency: how strictly these are applied varies a lot between countries and providers. The PSR aims to fix that, with updated EBA technical standards (detailed rulebooks the European Banking Authority writes to spell out exactly how a law like this works in practice) on when authentication can be skipped, applied consistently EU-wide, plus new requirements ensuring authentication doesn't assume every customer has a smartphone. 

For a marketplace or SaaS platform operating across several EU countries, this should mean a returning customer making the same low-value purchase gets treated the same way regardless of whether their bank is in the Netherlands or Germany, rather than sailing through checkout in one country and getting stopped for extra verification in another. That consistency matters commercially too: less unpredictable friction means fewer abandoned checkouts and fewer confused customers wondering why they suddenly needed extra verification this time.

How PSD3 improves open banking APIs

Since 2018, banks have often been allowed to rely on slow or unreliable connections instead of fixing them. As a result, open banking APIs can still fail or time out when customers need them most.

PSD2 already required these connections to deliver the same level of availability and performance as the bank’s own customer-facing interface. The new PSD3/PSR framework strengthens this by removing the need for a permanent fallback interface, while introducing stronger requirements for dedicated APIs and contingency measures when they fail.

If your marketplace or SaaS platform supports pay-by-bank as a payment method across multiple markets, this should mean fewer dropped transactions and steadier conversion.

How to prepare for PSD3: a checklist for marketplaces and SaaS platforms

If you're a marketplace, you sit between buyers and sellers, so your exposure is mainly the commercial agent exemption and seller payouts. 

If you're a SaaS platform embedding payments, your exposure is mainly your payment facilitation setup and merchant onboarding. Either way, a few things to work through between now and 2028:

1. Marketplaces: don't assume the commercial agent exemption covers you. The exemption only applies if you act exclusively for one side of the transaction with genuine room to negotiate; a standard automated checkout matching many buyers and sellers doesn't meet that bar. If you've been relying on the exemption, start the conversation with a regulated payment partner now rather than finding out the hard way.

2. SaaS platforms (ISVs) embedding payments: review your merchant onboarding and KYC. Make sure it's robust enough to hold up under tighter supervisory expectations, without slowing down how fast your merchants can go live.

3. Both: start the conversation with your payment provider or facilitator now, not after the rules land. The technical detail, like the EBA's updated authentication standards, is still being finalised industry-wide, so nobody has every answer yet. What matters is finding a partner who's actively tracking it and keeps you in the loop, rather than leaving you to find out on your own.

4. Both: don't wait for the deadline. Treat 2026 to 2028 as a runway, not a cliff edge, so you're not scrambling to catch up later.

How OPP fits in

This is exactly where OPP can help, whether you're running a marketplace or a SaaS platform embedding payments. 

Omnichannel payments mean you're not left piecing together a fragmented setup as PSD3 tightens who's allowed to hold funds; one licensed structure covers your sellers or merchants online, in person, or across borders, without rebuilding logic for every market. 

Onboarding means new sellers or merchants are verified against the same KYC standards PSD3 and the PSR now expect from licensed partners, without slowing down how fast they can go live. 

And support means that when a fraud report, a content liability question, or a distributor registration requirement comes up, you're working through it with a team already built for PSD3 and the PSR, not reading EU legislative texts alone. For marketplaces specifically, that also includes in-house buyer-seller dispute handling, directly relevant given the fraud accountability and content liability rules above.

Regulatory change is rarely the headline founders want to deal with. Our job is to make sure it doesn't have to be. If you'd like to talk through what this means for your setup specifically, you can reach our team here.