> For the complete documentation index, see [llms.txt](https://doc.ecomm.api.tietoevry.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.ecomm.api.tietoevry.com/e-commerce-payment-gateway/knowledge-base/psd3-psr-and-the-future-of-e-commerce-payment-gateways.md). # PSD3, PSR and the Future of E-commerce Payment Gateways ### Building PSD3-ready payment infrastructure for banks, merchants and digital commerce European payments regulation is entering a new phase. With the Third Payment Services Directive, PSD3, and the new Payment Services Regulation, PSR, the EU is moving from the PSD2 era into a more harmonised, fraud-resilient and operationally demanding payments framework. For banks, payment institutions and electronic money institutions, PSD3 and PSR will reshape the way payment services are authorised, supervised, secured and delivered across the EU. For e-commerce payment gateways acting as Technical Service Providers on behalf of banks, the message is equally clear: regulatory readiness is no longer only a matter for the licensed institution. It must be built into the technology layer. As of May 2026, the PSD3/PSR package has moved from policy debate into implementation planning. The Council of the EU published final compromise texts in April 2026, giving the market much clearer visibility on the future framework. This creates a strategic opportunity for bank-facing payment gateways. A TSP that can help a bank meet PSD3 and PSR expectations will not simply process transactions. It will become part of the bank’s regulated payment capability. ### Where the regulation stands in 2026 The EU payment services package consists of two complementary instruments. PSD3 will replace PSD2 as the new directive for authorisation, licensing, prudential supervision and institutional requirements for payment service providers and electronic money institutions. PSR will introduce a directly applicable regulation for many conduct-of-business and operational payment rules, including transparency, fraud prevention, open banking, authentication and customer protection. This split matters. PSD3 will still require national transposition by Member States, while PSR is designed to create a more harmonised EU rulebook that applies directly. For payment gateways acting as TSPs, the practical consequence is that banks will expect technology providers to support a more consistent set of controls across EU markets. Banks will need evidence that their payment journeys, fraud controls, authentication flows and reporting capabilities can meet the new framework. ### The EBA’s role: why the 2026 mandate pipeline matters The European Banking Authority will be central to PSD3 and PSR implementation. The EBA already develops requirements aimed at reducing payment fraud, supporting consistent authorisation and supervision of payment service providers, promoting competition and facilitating innovation in retail payments. Under PSD3 and PSR, the EBA is expected to receive a significant number of mandates. Market commentary indicates the EBA anticipates around 40 mandates and is expected to begin work on these in 2026, including a roadmap for implementation of the EU payment package. For a bank-facing e-commerce payment gateway, this is critical. The high-level legal texts will be followed by Regulatory Technical Standards, Implementing Technical Standards, guidelines, opinions and supervisory expectations. These will likely define the practical requirements for areas such as: * strong customer authentication; * secure communication; * transaction monitoring; * fraud reporting; * open banking interfaces; * access-to-account reporting; * onboarding and offboarding of third-party providers; * technical interface exemptions; * supervisory reporting; * authorisation and reauthorisation evidence. In other words, the future compliance burden will be highly operational and highly technical. A TSP should not wait until every final EBA technical standard is published. The right approach is to build a flexible control framework now, so the gateway can adapt as the EBA’s detailed mandates become final. ### The TSP position: not the regulated bank, but part of the regulated delivery chain A Technical Service Provider usually supports a regulated payment service provider without independently holding customer funds or acting as the licensed PSP. In an e-commerce gateway model, the bank may remain the regulated institution, while the TSP provides the technical infrastructure behind checkout, payment routing, authentication, fraud controls, reconciliation, reporting and merchant connectivity. This distinction remains important, but it is no longer enough to say: “We are only the technology provider.” Under PSD3 and PSR, the bank will need to demonstrate that its payment services are secure, transparent, properly authenticated, monitored and auditable. If the bank relies on a TSP to deliver these capabilities, the TSP’s systems become part of the bank’s control environment. That means the TSP should be able to support the bank with: * documented payment flow mapping; * clear allocation of responsibilities; * auditable authentication events; * transaction monitoring evidence; * fraud prevention controls; * incident and escalation procedures; * data protection controls; * operational resilience alignment; * reporting outputs for the bank and supervisors; * readiness to support EBA-driven technical requirements. The strongest TSPs will position themselves not as outsourced technology vendors, but as bank-grade payment infrastructure partners. ### Fraud prevention: from feature to regulatory control Fraud prevention is one of the strongest themes in the PSD3/PSR package. The EBA has already identified new types and patterns of payment fraud and proposed further measures to mitigate risks and protect consumers. Its 2024 opinion was specifically intended to strengthen the forthcoming PSD3 and PSR framework so that anti-fraud requirements remain future-proof. The final PSD3/PSR direction points to a more demanding fraud environment for banks and PSPs. This includes stronger transaction monitoring, fraud data sharing, user protection measures and liability rules where PSPs fail to apply adequate fraud-prevention mechanisms. For an e-commerce payment gateway working on behalf of a bank, fraud prevention must therefore become a core regulated capability. A PSD3-ready TSP platform should support: * real-time transaction risk scoring; * behavioural analytics; * device and session intelligence; * velocity rules; * merchant risk profiling; * suspicious transaction detection; * step-up authentication triggers; * transaction blocking; * configurable limits; * fraud event logging; * escalation to bank fraud teams; * evidence for investigation and reimbursement decisions; * structured fraud reporting. The bank will not only ask whether the gateway can detect fraud. It will ask whether the gateway can prove what happened, when it happened, which controls were applied, and why a transaction was allowed, challenged or blocked. ### Strong Customer Authentication: a renewed technical focus Strong Customer Authentication remains a central pillar of EU payment security. PSD3 and PSR are expected to refine the PSD2 framework and address implementation weaknesses that emerged across the market. For a TSP, SCA is not just a compliance function. It is a customer journey, a risk decision and an evidence trail. A bank-facing e-commerce gateway should therefore be ready to support: * SCA orchestration across payment methods; * 3-D Secure and equivalent authentication flows where relevant; * step-up authentication for higher-risk transactions; * exemption handling where permitted; * dynamic linking; * audit logs for authentication decisions; * fallback and retry logic; * fraud-driven authentication triggers; * customer journey monitoring; * reporting to the bank on authentication outcomes. The future EBA mandate work is expected to include authentication, secure communication and transaction monitoring mechanisms. For a TSP, this means SCA architecture should be modular and configurable, so that changes in RTS or guidelines can be implemented without redesigning the whole payment platform. ### Transaction monitoring: the gateway as the bank’s real-time risk engine PSD3 and PSR will push payment providers toward stronger, more continuous monitoring. For e-commerce gateways, this is especially relevant because gateway systems often see transaction data earlier than many back-office banking systems. A TSP should help the bank monitor payments in real time, not only after settlement. This includes: * payer and merchant behaviour monitoring; * abnormal transaction pattern detection; * device, IP and session risk signals; * payment method risk scoring; * recurring transaction analysis; * high-risk merchant category controls; * refund and chargeback anomaly monitoring; * account-to-account transaction controls; * instant payment risk controls; * dashboards for bank operations teams. The aim is to move from static rule checking to continuous risk intelligence. ### Payee verification and misdirected payment protection PSD3 and PSR also respond to the growing risk of misdirected payments and authorised push payment fraud. The framework is expected to expand verification-of-payee type obligations for credit transfers, with specific attention to matching the payee’s name and account identifier. For an e-commerce gateway, this is highly relevant where the platform supports: * account-to-account checkout; * instant payments; * bank transfer payments; * marketplace payouts; * merchant settlement; * customer refunds; * pay-by-bank flows. A TSP should therefore prepare for: * payee name and account identifier verification; * mismatch detection; * customer warning messages; * bank-configurable risk responses; * transaction refusal or review workflows; * logging of verification outcomes; * API integration with bank-side verification services. This will be especially important for gateways supporting bank-led alternative payment methods, instant payments and open banking-based e-commerce payments. ### Open banking: from access obligation to performance obligation PSD2 opened the door to account information and payment initiation services. PSD3 and PSR aim to make open banking more effective, more reliable and less fragmented across the EU. The EBA’s current payment services work already includes open banking-related technical standards, secure communication, API work and Q\&A activity. Under PSD3 and PSR, further EBA mandates are expected around access-to-account reporting, dedicated interfaces, secure communication and onboarding or offboarding of third-party providers. For a TSP, this matters in two directions. First, if the gateway supports pay-by-bank or payment initiation flows on behalf of a bank, it must be able to deliver reliable API connectivity, consent handling, transaction status visibility and secure data exchange. Second, if the bank exposes interfaces to third-party providers, the TSP may need to support the technical interface, monitoring, availability, error handling and reporting. A PSD3-ready gateway should be able to support: * API-based payment initiation; * consent and permission lifecycle support; * secure communication controls; * interface availability monitoring; * error reporting; * performance dashboards; * TPP onboarding and offboarding support; * customer-facing permission transparency; * operational evidence for the bank. Open banking under PSD3/PSR will not only be about providing access. It will be about providing reliable, secure and measurable access. ### Transparency at checkout: clear information before the payment The PSR framework is designed to strengthen transparency for users of payment services. For e-commerce, this has direct impact on checkout design. Customers should clearly understand: * who they are paying; * the amount they are paying; * the payment method used; * applicable fees; * currency conversion where relevant; * refund expectations; * payment status; * authentication requirements; * merchant identity; * support and complaint routes. A TSP operating a hosted checkout, payment page, API or embedded merchant component should make transparency configurable and auditable. This is important because the bank may be accountable for disclosures even where the customer-facing screen is technically delivered by the gateway. ### Safeguarding, authorisation and bank due diligence PSD3 is also expected to strengthen authorisation and supervisory requirements for payment institutions and electronic money institutions. The final texts are expected to bring payment institutions and e-money institutions closer together under a more unified framework. A TSP working for a bank may not need its own PSD3 authorisation if it remains within the technical service provider role. However, the bank will likely increase due diligence on critical providers. The bank may ask the TSP to demonstrate: * governance and accountability; * outsourcing and third-party risk controls; * operational resilience; * DORA alignment; * incident management; * data security; * business continuity; * service-level controls; * subcontractor management; * audit rights; * exit planning; * evidence retention. This means PSD3/PSR readiness should be aligned with the bank’s broader operational resilience and third-party risk framework. ### What banks will expect from a PSD3-ready payment gateway TSP Banks will increasingly expect their TSP partners to provide compliance-supporting capabilities by design. A PSD3-ready e-commerce gateway should offer the bank: #### 1. Control-by-design architecture The platform should embed fraud controls, SCA support, transaction monitoring, logging and reporting directly into the payment flow. #### 2. Configurable compliance rules Banks should be able to configure limits, rules, risk responses, authentication triggers and merchant controls according to their risk appetite and regulatory interpretation. #### 3. Evidence-ready operations Every relevant payment decision should be traceable through timestamps, logs, risk scores, authentication events, customer messages and system actions. #### 4. Bank-grade reporting The gateway should provide structured reports that support fraud monitoring, operational oversight, incident management, audit reviews and supervisory engagement. #### 5. Secure API and open banking support Where account-to-account or payment initiation services are involved, the gateway should support secure communication, API performance monitoring and consent lifecycle controls. #### 6. Customer transparency tooling The platform should make it easy for banks and merchants to deliver clear, consistent payment information to customers before, during and after checkout. #### 7. Regulatory adaptability The gateway should be designed to absorb future EBA RTS, ITS and guideline changes without requiring major platform redesign. ### Practical PSD3/PSR readiness checklist for a TSP A bank-facing e-commerce payment gateway should start now with the following readiness programme. #### Map your regulatory role Confirm whether you act purely as a TSP, whether any regulated payment services are performed by you, and where the bank’s responsibilities begin and end. #### Map payment flows end to end Document every payment journey, including checkout, authentication, routing, authorisation, clearing, settlement, refunds, chargebacks and reconciliation. #### Assess fraud controls Review whether your platform supports real-time risk scoring, monitoring, blocking, alerts, case evidence and reporting. #### Review SCA architecture Check whether authentication flows are modular, auditable, configurable and ready for future EBA technical standards. #### Prepare for verification of payee Identify all account-to-account, payout, refund and settlement flows where payee verification may become relevant. #### Strengthen open banking readiness Review API security, consent management, TPP connectivity, availability monitoring and error reporting. #### Improve audit evidence Ensure the bank can reconstruct the full payment decision chain from your logs and reports. #### Align contracts with operational reality Update agreements with banks and merchants to reflect responsibilities for fraud, authentication, incidents, data, reporting, support and regulatory change. #### Create an EBA mandate tracker Track the EBA’s PSD3/PSR roadmap, consultations, RTS, ITS, guidelines and opinions from 2026 onward. ### Strategic positioning: from payment gateway to bank enablement platform PSD3 and PSR will raise the bar for payment infrastructure. This creates a strong opportunity for TSPs that serve banks. A gateway that only provides technical connectivity will be easier to replace. A gateway that helps a bank reduce fraud, prove compliance, improve checkout conversion, support open banking and satisfy supervisory expectations becomes strategically valuable. The future positioning should be: “We enable banks to deliver secure, transparent and PSD3-ready e-commerce payments through bank-grade gateway infrastructure, real-time fraud controls, strong authentication support, open banking connectivity and audit-ready reporting.” ### Conclusion PSD3 and PSR are not just legal updates. They are a new operating model for European payments. For an e-commerce payment gateway acting as a Technical Service Provider on behalf of a bank, the core challenge is to translate regulatory expectations into technical capabilities. Fraud prevention, strong customer authentication, transaction monitoring, open banking access, customer transparency and reporting must become part of the platform design. As of May 2026, the direction is clear. The final compromise texts have been published, the EBA’s implementation work is expected to accelerate, and banks will begin preparing for the new framework well before the main application dates. The TSPs that act early will be best positioned to become trusted bank partners in the next generation of European digital payments. ### How Tieto can help As PSD3 and PSR move from policy into implementation, banks will need trusted technology partners that can turn regulatory expectations into secure, scalable payment capabilities. This is where Tieto can make a real difference. By supporting banks with modern e-commerce payment gateway capabilities, secure integration, fraud-aware transaction flows, strong authentication support, and audit-ready operational controls, Tieto can help ensure that payment services are not only compliant, but also resilient, customer-friendly and ready for the next generation of European payments. In a market where regulation, security and customer experience are becoming inseparable, Tieto can be the partner that helps banks deliver PSD3-ready payments with confidence. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.ecomm.api.tietoevry.com/e-commerce-payment-gateway/knowledge-base/psd3-psr-and-the-future-of-e-commerce-payment-gateways.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.