Wero is being sold to merchants as the low-fee alternative to cards. But for the PSPs and acquirers who have to operate it, the real cost is about to show up somewhere else: reconciliation.
Cards have 20 years of standardised settlement flows, chargeback rules, and exception handling. Wero brings separate settlement cycles, a different refund path, and exception management that doesn’t map cleanly onto the rails you already run. That is not a feature. That is a new operational burden.
The pitch is lower interchange. The reality is your finance team will be manually matching files that don’t align, chasing refunds that don’t follow card logic, and explaining to merchants why their cash is “in transit” for longer than expected.
As Frederic Yves Michel NOEL highlights, many PSPs underestimate that Wero support is not just another payment method toggle. It is a parallel reconciliation framework. If you bolt it on without rethinking your settlement architecture, you are not saving margin. You are just moving the cost from the scheme fee line to your ops headcount.
For merchants, the key point is simple: the cheapest transaction is the one that doesn’t require a support ticket to figure out where the money went.
For PSPs, the question is whether you build the Wero reconciliation layer properly now, or you pay for it in exception handling later.
For payment teams already running Wero pilots, where is the reconciliation friction actually hurting: settlement matching, refunds, or exception handling?
#Wero #Reconciliation #PSP #Fintech #MerchantPayments #PaymentOperations #OpenBanking

Comments are closed