Wero decoded: From P2P to POS – an overview of the key features

Teaser

Wero is gaining momentum and is poised to become the most widely used digital payment solution in Europe. For banks, the question is no longer whether to offer Wero, but how to implement it.

This article provides a concise overview of Wero’s key functional areas and highlights what banks need to consider at the product, architecture, and operational levels. It kicks off a series of articles that will explore selected topics related to Wero in greater depth in future posts.

The status quo

The European payments landscape is undergoing change. With Wero, the European Payments Initiative (EPI) has created a multinational payments brand that already supports person-to-person (P2P) and e-commerce payments in Germany, France and Belgium – with the Netherlands, Luxembourg and Austria set to follow shortly.

In future, Wero is also set to enable mobile payments at the point of sale (POS). National solutions are being brought together under a single umbrella; at the same time, connectivity to established national payment solutions in Spain (Bizum), Italy (Bancomat), Portugal (MB Way) and Greece (IRIS) will be established in the course of this year (2026) through the development of a central interoperability hub. Looking ahead, Norway and Sweden (Vipps Mobile Pay) as well as Poland (Blik) will follow. The aim is to provide a consistent payment experience for consumers and a standardised infrastructure for banks, merchants and payment service providers.¹

EPI deliberately launched Wero as a P2P solution in 2024 and is now allowing it to grow into a complete payments ecosystem with extensive platform infrastructure that goes far beyond the initial use case – now with over 50 million registered users across Europe. For banks, Wero readiness is therefore not an isolated product decision, but a fundamental strategic and technological issue that affects product management, architecture, operations and compliance in equal measure.

P2P payments – the gateway to the Wero ecosystem

P2P payments form the gateway to the Wero ecosystem. EPI deliberately launched P2P first, as this use case is highly relevant to everyday life and fosters a stronger connection to the payment brand than any transaction with a retailer. For banks, P2P is therefore a key lever for user activation and wallet penetration.

The user journey is designed to minimise friction: instead of an IBAN, which is the conventional form of identification in account-based payment transactions, the recipient’s telephone number or email address suffices as so-called proxies, which are linked to a payment account within the system. The payment is executed in real time via SCT Inst – SEPA Instant Credit Transfer; the payer selects the contact, enters the amount and confirms via biometrics. In addition to traditional P2P transfers, Wero also supports targeted payment requests as well as open payment requests via a link or QR code, for example for group payments.²

The use of telephone numbers and email addresses as payment aliases is a key architectural decision: it abstracts away from account numbers and makes paying as simple as sending a message. This presents banks with new challenges throughout the entire alias lifecycle. They must enable their customers to register, verify and amend aliases, and link them to accounts – where customers have multiple accounts or telephone numbers, a clear standard mapping is required.

The onboarding process, including the associated alias linking, is a key success factor for Wero. EPI recommends an automated, as unobtrusive as possible registration process directly within the banking app; if this onboarding pathway is not implemented properly, there is a risk of low activation rates.

E-commerce and m-commerce payments

E-commerce and m-commerce represent the next stage of expansion: this is where it will be decided whether Wero is perceived by consumers and merchants as an alternative to PayPal, credit cards or Klarna. Unlike with P2P, the focus here is on integration into merchant processes – from checkout and payment processing through to refunds and disputes. To this end, Wero provides a coordinated set of services that is closely integrated with P2P, wallet management and the generic core services.

The payment process is structured around a four-stage payment flow:

• First, the user gives their consent to a payment request in the wallet.
• The consumer PSP then verifies and authorises the payment.
• The subsequent capture – the request for payment of the authorised amount by the merchant via its PSP – can take place immediately or at a later stage, for example upon dispatch or partial delivery.
• The process concludes with settlement, the booking between the parties involved as a real-time transfer (see Figure 1).

As the communication of these messages runs via EPI Central Services, this creates an additional interface for banks that must be integrated.

Building on this, Wero supports several payment models: Single Immediate Payment for traditional one-off purchases; Event-Based Payment, where consent is given in advance and the amount is only debited upon a defined event such as dispatch; and Subscription Payments for recurring payments, including price changes and switches between payment methods. Split-payment and split-bill models for platform and marketplace transactions are also provided for.³

In the checkout process for traditional online retail, a QR code linking to a Wero landing page connects the shop with the wallet; in mobile commerce, the wallet launches directly from the app. To foster trust and ensure low dispute rates, Wero deliberately distinguishes between the legal payee name and the brand or shop name visible to customers. Refund and dispute processes are an integral part of the payment lifecycle and are handled by the system; users are notified of every relevant status – from the consent request through authorisation and settlement to the refund.

POS payments

For Wero, the high street retail sector is the most challenging market segment. Unlike in P2P or e-commerce, Wero encounters an established infrastructure of card terminals and till systems here, as well as existing agreements between merchants, acquirers, payment service providers (PSPs) and network operators. POS integration therefore follows a phased roadmap, staggered both technologically and geographically.

In the short term, the QR code serves as an entry point: the customer scans the code displayed on the terminal, the till display or in the retailer’s app, checks the amount and the payee, and confirms the payment. ¹ This works well for the hospitality sector, click-and-collect or retailer apps; however, at busier checkouts such as those in the food retail sector, it remains a compromise, as it requires more user interaction and a stable smartphone connection.⁴ Added to this is the technical effort involved in integrating new payment methods into existing, often inflexible till systems.

For widespread adoption, Wero needs a payment process similar to contactless payment: hold a card or smartphone up to the terminal, trigger authorisation, and report the result back to the till and terminal. Two approaches are at the forefront here: the storage of a tokenised wallet ID as a reference value, or ‘tap-to-pay’, as is familiar from Apple Pay, Google Pay and cards such as girocard or Cartes Bancaires. A more detailed description and specification for both methods is still pending.⁵

Undoubtedly of greater strategic significance is the NFC method, familiar from cards and ‘traditional’ mobile payments. The technology is available on the market; the challenge lies in standardised integration with the EPI infrastructure, the certification of terminal and network operator connections, and viable acquirer agreements. According to the EPI roadmap, NFC-enabled POS payments are planned for 2027.⁶

Strategically, for Wero, POS is not an isolated channel, but the final step towards a seamless omnichannel payment experience. The wallet identity is used across online, mobile and brick-and-mortar retail – including refund, dispute and subscription functions, which are also becoming increasingly important at the POS.

Generic functions and core services

Wero is more than just a new payment method. Behind the visible payment functions lies a set of core services that must be available regardless of the use case – as a prerequisite for stable, secure and regulatory-compliant operations, which affect IT, product management, compliance, operations and customer service in equal measure.

Wallet management forms the organisational backbone of this: Each wallet is linked to one or more payment accounts; accounts and devices can be added, amended or deactivated; and the wallet supports the entire user lifecycle from activation through to deletion or migration when changing banks. It also handles tasks such as strong customer authentication (SCA) and the approval of consent requests. To achieve this, banks require a robust interface between their core banking system and EPI Central Services to ensure that account structures, customer data and device linkages remain consistent.

Push notifications are the key tool for informing users in real time about incoming payments, enquiries or status changes – without a reliable, cross-platform push infrastructure, Wero loses its added value compared to traditional bank transfers.

As Wero is based on SCT Inst – the availability of which is now mandatory for banks under the EU Instant Payments Regulation – there is an increased focus on ensuring 24/7 availability and the scalability of the systems to cope with future peak loads. Furthermore, banks are also involved in refund and dispute processes and act as the first point of contact for escalating a dispute. The necessary structures and internal processes must be defined at an early stage.

When it comes to fraud and risk management, real-time payments leave little room for manual verification, particularly as transactions are generally irreversible. ⁷ Alias-based identification creates additional vulnerabilities, for example to social engineering. Using the Fraud Score optionally provided by EPI, banks and PSPs serving end customers and merchants can decide whether to process or authorise a transaction. To utilise this functionality effectively, banks must support these interfaces and integrate the Fraud Score into the relevant decision-making logic.

Context and Outlook

Wero cannot be viewed in isolation within a product roadmap: P2P forms the entry point, e-commerce the stage already being expanded, and POS the channel of greatest strategic importance, but also the most demanding. These are linked by an infrastructure with high requirements in terms of availability, security and operational maturity.

For banks, this means:

• Wero readiness is more than just the technical integration
• Automate alias registration
• Establish internal structures to support refund and dispute processes
• Further strengthen scalability and 24/7 availability
• Manage Wero as a platform project rather than as an individual initiative

Otherwise, there is a risk of low activation rates, an avoidable support burden and a loss of oversight regarding the impact on IT, compliance, operations and customer service.

In the following issues, this series of articles will address the key areas of focus, including the technical architecture of a Wero integration, the requirements for robust fraud management in a real-time context, the fees and revenue model, and the decision on the operational model – whether to operate in-house, outsource or adopt a hybrid approach.