Europe's banking sector has long tried to dethrone PayPal. Germany's Giropay and PayDirekt already vanished as both were unable to gain sufficient market share. The Dutch iDEAL payment system has reportedly reached 70% market share in the Netherlands. With the new Wero system, Europe wants to achieve the breakthrough now. Although largely in its infancy, I crawled down the rabbit hole and took a deep dive into Wero for you. Something that took me months of research.
Online payments in the EU are dominated by Visa, MasterCard, American Express and PayPal today. Swedish Klarna, a "Buy Now Pay Later" (BNPL) solution, has gained an 8.35% market share for online payments and 35% market share for BNPL payments. Europe is always considered to be technically behind U.S. in payment processing technology. However, the EU's SEPA system is technically more advanced than the U.S. ACH and the Canadian EFT systems. A funds transfer through ACH and EFT usually takes around 1–2 bank days while SEPA Instant Transfers are completed within 10 seconds, 24/7 and around the clock.
With SEPA, the Eurozone already has the world's most advanced payment system. The friction of very long bank account numbers (IBANs) and European banks' reluctance to allow easy programmatic access have hindered SEPAs application for E-commerce payments until today. Through the introduction of Wero, which utilizes SEPA Instant, the European Payments Initiative (EPI) wants to break these barriers.
How Wero is different to PayPal
PayPal is a platform that allows users to create accounts that hold a balance with which they can pay online. Credit cards and bank accounts can be added to a PayPal account to transfer funds in and out of the account. If a PayPal account does not hold any funds, payments through PayPal will use the connected bank accounts or credit cards. However, these connected accounts aren't required for a PayPal account to work. Merchants on the other side can use PayPals various tools, APIs and SDKs to easily integrate payment processing in their apps and websites.
Wero is different. Users cannot create a Wero account, but use their existing European bank account. If you want to use Wero, you need to have a current account with a European bank that supports Wero. With German Sparkasse, Volksbanken, Raiffeisenbanken, and Revolut all supporting Wero already, it's generally available to everyone. Even if you're main bank doesn't support it, you can always just setup a Revolut account.
For merchants, the situation is similar. There's no publicly documented Wero API for developers. Wero payments are exclusively made through the payment service providers that Wero partnered and integrated with. The most prominent are the Dutch Mollie, which will launch Wero by the end of 2026, and German VR-Payment which already has merchants operating Wero. The implementations with Wero's partners are currently relatively simple and are often just a hosted payment page. Your website, shop or app sends the user to a payment link within the browser. Native apps have to use the system's in-app browser options as there's currently no native SDK offered by any of Wero's payment processing partners.
This approach is very different to PayPal and almost identical to how iDEAL, GiroPay and PayDirekt worked. Such an approach also comes with the caveat that international travellers and tourists will be left out entirely. Wero will only work for European merchants with European customers. Local payment initiatives such as the Danish MobilePay and the Swiss Twint both also suffer from these limitations. Even if Wero can capture all European banks and all European merchants, the Total Addressable Market (TAM) for Wero is much smaller than that of credit cards or PayPal.
The Wero Payment Flow
Wero's existing acquirers only provide simple hosted payment pages. In the example of Mollie, the merchant's app creates a payment link which will then initiate the flow, and return the user once the payment is finished. The merchant's process is the same with acquirers VR Payment and Unzer.
curl -X POST https://api.mollie.com/v2/payment-links \
-H "Authorization: Bearer live_abcdefg" \
-d "description=Bicycle tires" \
-d "amount[currency]=EUR" \
-d "amount[value]=24.95" \
-d "minimumAmount[currency]=null" \
-d "minimumAmount[value]=null" \
-d "redirectUrl=https://webshop.example.org/thanks" \
-d "webhookUrl=https://webshop.example.org/payment-links/webhook" \
-d "expiresAt=2023-06-06T11:00:00+00:00"
-d "reusable=false"
-d "allowedMethods[]=wero"
-d "sequenceType=first"
-d "customerId=cst_abcdefg"Once the user is redirected to the payment link, the wero launch page pops up. If it's on desktop, the user is shown the Wero QR code which needs to be scanned with his mobile banking app. The QR code contains the same Wero payment URL under pay.weropay.eu. When scanned with the iPhone camera, it'll open the payment page in Safari. If used for the first time, that payment page offers a list of all available banks for which it then opens the respective app. A process that contains about the same friction as PayPal, but is far away from the simplicity of Apple Pay.
Available banking or MFA apps are retrieved by the payment page through a small API that contains all banking networks, banking institutions and their respective app. There are banks that use Wero's own app, such as Deutsche Bank. Then there are banks that bring their own, such as my local bank Volksbank Köln/Bonn.
# url with all currently active networks, banks, and apps
https://pay.weropay.eu/api/brands?fieldTest=falseIf you set the fieldTest parameter to true you can see the banks that are likely to become available in the future. This is somewhat interesting as this data feed would theoretically allow both the acquirer and the merchant (e.g., your app) to shorten the process of finding the respective app. However, such a shortcut is currently not supported by any of the payment service providers. These require developers to follow a very strict process.
Once the user selects the app and hits the "Open the app" button on the wero payment page, it'll trigger the respective app for approval. In my case this is the VR SecureGo plus app, the same I also approve wire transfers and credit card transactions with. For most banks, that app is the same as the one used for Visa Secure and MasterCard Identity Check.
The Wero payment flow is simple and straightforward for me, but not for my wife. She uses Apple Pay for everything, which I set up on her iPhone for her Amex card. Although she has the "VR SecureGo plus" app, the additional steps required are just too much hassle for her. My wife is probably not alone on this one. There's a number of friends and family that too struggle with their bank's MFA app.
URL scheme handling approach by the apps
The handling of the various apps' URL schemes is quite conservative. Wero's entire flow, at the time of writing, is designed around an external payment page. A quick "Pay with Wero" button that opens the respective app directly would be technically possible, but depends on the capability of the acquirer and the actual implementation of the merchant.
{
"applinks": {
"details": [{
"appIDs": [
"9QMC9FXZ4F.eu.epicompany.wero.wallet.debug",
"9QMC9FXZ4F.eu.epicompany.wero.wallet.int",
"9QMC9FXZ4F.eu.epicompany.wero.wallet.qa",
"9QMC9FXZ4F.eu.epicompany.wero.wallet",
"9QMC9FXZ4F.eu.epicompany.wero.wallet.uat",
"HM7Q3C74QA.de.bbbank.securego",
"8X2LHH32H6.de.sparda.securego",
"45QHT6G9L6.de.fiduciagad.securego.vr",
"45QHT6G9L6.de.fiduciagad.securego.wl"
],
"paths": ["/*"]
}]
}
}The apple-app-site-association (AASA) file on pay.weropay.eu already lists the various MFA apps. However, it seems that the Secure Go app does not have the correct entitlement or does not properly handle the URLs. When correctly implemented, my bank's Secure Go app (i.e. my bank's MFA app) should launch when opening a link to the pay.weropay.eu domain in Safari. Doing this properly would reduce friction in the process.
Security challenges of Wero
I activated Wero in both the VR Banking app as well as the Revolut app. In hindsight, I was lucky to first enable it in the VR Banking app and the Revolut app. You can not use a phone number or email address with multiple bank accounts. It's a one-to-one relationship.
Risky phone number association
When I first signed up for Wero with my Volksbank, I provided my phone number. When I signed up through Revolut, I provided both the phone number and the email address. My phone number however is not assigned to the Revolut account, it's stuck with the Volksbank account. Weirdly though, my e-mail address is associated with Revolut as Volksbank does not support adding an email address. So if someone sends money through Wero to my phone number, it ends up on the Volksbank account. When sent to my email address, it lands on the Revolut account.
Reassociating phone numbers to different accounts can only be done through the Wero customer support. This is a consequence of the fact that users don't really have a Wero account. As soon as multiple banks are involved, Wero's FAQs revert you to the Wero support which is essentially just a chatbox on the website. Phone or email support do not seem to exist. So if you're switching banks or phone numbers, make some preparations.
If Wero grows, this will likely backfire in the future. While it doesn't affect e-commerce and app payments, it can create frustration and turn users away from Wero. Allowing banks to reassign phone numbers would easily fix the issue. Until now, Wero's identity management has a flawed design.
Phone number and name probing
SEPA VoP (Verification Of Payee) was introduced in October 2025 and already allowed name probing of bank account numbers (IBAN). If you enter an IBAN into your online banking, without authorising the transfer, you will see the full registered, and KYC verified, name of the account holder. While IBANs aren't generally floating around freely, phone numbers and email addresses do.
If someone enters my phone number into his Wero app, it'll show my and my wifes name indicating that the Wero account is linked with our joint bank account, and that we have a joint account. The VR Banking App also seems to be plagued with bugs regarding Wero, as the names on the account and Wero transactions mismatch. Something that is prohibited by the European Payment Service Directive (PSD2) amongst a number of other banking regulations. It indicates that something is not quite right, yet.
The prevention of such name probing attempts, and thus information leakage vulnerabilities, relies on the banks running proper security monitoring. If a user probes dozens of phone numbers, they hopefully shut that user down. Otherwise anyone can create a huge database of phone numbers with KYC validated full names.
Unclear dispute process
The terms and conditions of my bank indicate that there is some form of dispute process with Wero. Since Wero uses SEPA Instant Transfer, which you can technically not charge back, one has to assume that it is some form of agreement between the banks to create a return transfer.
Conditions of disputes are relatively vague, but the fact that my banking app has a section for pending Wero disputes and settled ones indicates there must be some form of process. Yet, funds aren't held in escrow and thus the protection that PayPal offers, including withholding of funds, does not exist with Wero, or is done solely by the acquirers. Wero and the banks need to be way more transparent on the dispute process. Wero's website and my bank's terms and conditions contradict each other.
Friction and One Tap Payment
If Wero wants to succeed, it needs to be an entirely frictionless one tap payment method, in the browser and within apps. Apple Pay and Google Pay have already eaten into PayPal's market share by essentially reducing the entire checkout process to a single button tap. Entering delivery and billing addresses isn't required, and neither is entering any payment details. PayPal introduced One Touch approach to E-Commerce in 2016, and significantly increased checkout conversion rates.
Wero will likely remain an alternative niche payment method for a couple of years, due to its conservative technical integration and the slow time to market. Both is caused by the necessity of relying on hundreds of banking partners and acquirers for changes. Something that neither PayPal, nor Apple Pay or Google Pay have to rely on. Wero is currently at the technical integration level of what PayPal was around 15 years ago. It's success further heavily relies on the technical capability and willingness of its acquiring and banking partners to innovate. Something their banking partners have constantly struggled with in the past decades.
Wero already has over 1,000 different user experiences designed by each individual bank, their software vendor and the acquirers. Apple Pay, Google Pay and PayPal each have a single very strict user experience. If Wero wants to keep up with them, it'll have to convince all its 9 different MFA app developers to integrate billing and delivery address management, shipping selection, and at least browser extensions for Safari and Chrome on iOS and Android. Otherwise most people won't even see Wero, because they've rushed through the express checkout before Wero even appears.
Developer tooling leaves a lot to be desired
Successful payment services are driven by thousands of developers implementing them. Even the most niche and awkward web apps can easily implement PayPal overnight. PayPal's public APIs and the self service onboarding are available around the clock. It's easy, it's fast and comes with a ton of SDKs. Anyone who wants to compete with PayPal, Google Pay and Apple Pay has to do so not just in customer experience, but also in developer experience. The current conservative approach to will hardly get any developer excited to implement Wero in any applications.
Stripe conquered the payment world by storm, through really well documented, really deep and innovative payment APIs and SDKs. It's the world's first choice for payment, and the Apple Pay integration is the deepest you can imagine. With full self service onboarding and full native development integration, like in Xcode for example. Wero is lightyears away from even remotely matching that. Not to mention the hottest topic in payment technology right now: Agentic Payment. Wero's technical approach would be ideal for payments done by AI agents, but it's highly unlikely that Wero and its banking partners will ever consider it.
DYI your own Wero clone
If you like the idea of using SEPA Instant Transfer with QR codes, but would like to have full control over the process and roll your own, you can do so with Stripe for years already. The EPC QR specification from the European Payments Council defines how QR codes for SEPA are structured.
The contents of the EPC QR code are simply the payee, the IBAN, the amount, and the payment reference. When the user scans the QR code with his banking app, it'll automatically insert all the details for a SEPA transfer. Some banking apps don't yet, even after 9 years, support the instant transfer (INST instead of SCT), but users can activate that manually. Most banks will do it by default anyway.
BCD
002
1
INST
Max Mustermann GmbH
DE62370400440532013001
EUR50.00
SausagesSince Stripe provides you with your own bank details alongside the option for customers to pay by bank transfer, you can combine EPC QR with the bank transfer payment from Stripe. The following Node.js example code does that in a handful lines of code that you can use in your apps. Since Stripe supports SEPA Instant Transfer the funds are in your Stripe account within just seconds.
const stripe = require('stripe')('sk_test_your_key_here');
const QRCode = require('qrcode'); // npm install qrcode
async function createSepaWithQRCode() {
try {
const paymentIntent = await stripe.paymentIntents.create({
amount: 1050, // €10.50
currency: 'eur',
customer: 'cus_123456789',
payment_method_types: ['customer_balance'],
payment_method_data: { type: 'customer_balance' },
payment_method_options: {
customer_balance: {
funding_type: 'bank_transfer',
bank_transfer: {
type: 'eu_bank_transfer',
eu_bank_transfer: { country: 'DE' },
},
},
},
confirm: true,
});
const instructions = paymentIntent.next_action
.display_bank_transfer_instructions;
const bank = instructions.financial_addresses[0].iban;
const amountInEur = (paymentIntent.amount / 100).toFixed(2);
// --- EPC QR Code Standard Format ---
// Service: BCD (Business Case Data)
// Version: 002
// Character Set: 1 (UTF-8)
// Identification: SCT (SEPA Credit Transfer)
const epcData = [
'BCD',
'002',
'1',
'INST',
bank.bic,
bank.bank_name,
bank.iban,
`EUR${amountInEur}`,
'', // Purpose code (optional)
instructions.reference, // UNSTRUCTURED REFERENCE (Critical!)
'Payment for Order', // Visible hint
''
].join('\n');
// Generate a Data URI for an <img> tag or save to file
const qrCodeDataUrl = await QRCode.toDataURL(epcData);
console.log('EPC QR Code String:', epcData);
console.log('QR Code Data URL generated.');
} catch (error) {
console.error(error);
}
}
createSepaWithQRCode();This is all you need to create a transaction in Stripe and an EPC QR code. It even covers absolutely all banks in the SEPA region, and not just those who participate in Wero. If you dream really big, Stripe Connect and a really good one tap JavaScript snippet with a QR code generator of your choice will create you a fully blown Wero clone.
Conclusion
Wero is solid and robust, but certainly not exciting or innovative. The payment page on pay.weropay.eu is resolving to AWS in Frankfut. This raises questions on Wero's European roots statements. Open APIs, SDKs and agentic payment are left to the payment processing partners to figure out. Wero itself chose a conservative route, not an innovative one. It chose the route not of a payment platform, but rather a closed network that orchestrates SEPA instant transfer across banks and their customers.
As the merchant side already looks a bit boring, the users aren't expected to get overly excited either. When you Apple Pay your way to airport lounge buffets with American Express, there's very very little incentive to waste time with that whimsical banking app of yours. People don't pick payment methods as political statements, but merely for personal benefit.
If the European banking sector would be as good with software development as it is with lobbying in Brussels, we may not be paying everything with Apple Pay today. Merchants didn't introduce PayPal, Apple Pay, Google Pay and American Express because they liked the fees, but because customers demanded it. Wero will have to prove that it has more to offer than a 0.77% transaction fee for merchants, while Stripe charges 1.5% for cards and 0.8% for SEPA direct debit.
Wero has already limited its total addressable market, doesn't provide seamless integration for merchants, and is lightyears away from offering the convenience of Apple Pay. Comparing Wero to its failed predecessors Giropay and PayDirekt feels a little like "Same, same, but different". It's design flaws in identity management also indicate early mishaps in its architecture that'll likely be costly further down the road.
Unless the banks hand over development authority to Wero, it'll be forever plagued by its slow time to market. It'll stay the quirky niche payment method that it is today, regardless of however many billboards it buys. Digital payment is a technology game that relies on a convenience triangle of users, merchants and developers alike. Something that Wero in its early stages still struggles with. Let's hope they get it solved this time, and don't end up like Giropay and PayDirekt.
Thank you for reading. Jan
I'm a software business owner from Germany, worked in various CTO roles, an active programmer in C++, Go, Swift and passionate technology enthusiast. My programming career started at a young age and I later acquired a professional institutional education in software engineering. My journey on Medium started out as note taking and documenting my projects. Over time, it became more and more popular with you, my beloved readers. Not because I am someone special, but because people crave for thoroughly researched technical articles. Following me, clapping and subscribing is one step forward in keeping technical writing and its community alive.