Part 1, “Wero is the scheme that never touches the money”, sets out the structural mechanics this piece builds on: the three-plane model behind the European Payments Initiative (EPI), and why control and coordination stay with the scheme whilst settlement is externalised entirely to SEPA Instant and the Eurosystem’s TIPS.
That division of labour is the whole structural case. The EPI keeps the rulebook, the brand and the coordination for Wero, and it orchestrates the transaction without ever holding the money.
That one design choice has a practical twin, and most of the coverage skips it. A scheme that never sits in the money flow cannot reverse a payment either. There is no clawback to pull, because there is no scheme settlement to pull it through.
A Wero refund belongs on the payouts side of the ledger
One word carries this whole argument, so it is worth being precise about it early. The case for a payouts moat only holds together if a Wero refund is genuinely a payout rather than a variant of getting paid.
Merchant settlement is the acquirer moving money to the merchant itself, which is to say the funds a business has just earned from its own sales, netted of interchange and scheme fees, and paid out on a scheduled batch, typically T+1 or T+2, into the same account the acquirer checked once at onboarding. It is a mature and well-understood problem with a single relationship at the centre of it, and most of what an acquirer is built to do sits here.
A payout is a different shape of problem altogether. Here the acquirer, or a platform sitting on top of it, moves money onward to somebody who is not the merchant at all: a marketplace seller, a gig worker, or, in Wero’s case, a shopper getting their money back. Fire.com makes the operational consequence explicit in its analysis of marketplace payouts. Once a platform or a scheme sits between the acquirer and the end recipient, the acquirer’s compliance and monitoring obligations extend outward to a payee it has never underwritten the way it underwrote the merchant. That recipient is often new, occasional, and unverified in a way a merchant’s own settlement account simply is not.
A Wero refund is not the acquirer paying itself back, and it is not an adjustment to what it owes the merchant. In my view it is better framed as the acquirer originating a new payment to a third party, the shopper, who was never its own onboarded customer, and who it has to identify, screen and pay correctly inside a ten-second window. An acquirer’s settlement infrastructure was built for the first of those problems, whilst payouts infrastructure was built for the second, and under Wero only the second one is on offer.
The shopper an acquirer has to pay back is not its customer, and never was.
Wero has two legs, and only the pay-in leg behaves
The first leg is the pay-in, which is gross, settled in seconds and irrevocable, exactly as Part 1 described. The second is the return leg, meaning whatever has to happen when a shopper wants their money back. The pay-in behaves much like settlement, close to instant but still a single known relationship between the shopper’s bank and the merchant’s acceptor PSP. The return leg is a payout in the fullest sense, a new instruction to a recipient the acquirer must re-identify, moving in the opposite direction to everything the acquirer’s existing settlement machinery was built for.
Under cards the return leg is cheap to reason about, since a chargeback unwinds through the same central settlement the scheme already controls. Wero offers no such unwinding, so a refund or a successful dispute has to be re-originated as a fresh credit transfer, sent by the acquiring PSP back upstream to the shopper’s bank.
This is why Owen Strijland and Ellen Straus of Protiviti describe the ultimate financial risk in the Wero model as resting with the acquiring PSP rather than the scheme.
The pay-in leg is the easy half of Wero, and the return leg is where an acquirer’s own operational maturity gets tested, transaction by transaction.
Acquirers with a mature payout engine extend a capability instead of building one
I underweighted this next part in an earlier draft, and it is the actual engine behind the moat rather than a footnote to it. Acquirers that already run mature payout infrastructure (funding marketplace sellers, gig workers, insurance claims and supplier disbursements) have already built the hard part. They run a system that originates outbound payments, prices them, routes them and defends them operationally. Wero refunds are not a new problem for a system like that, but a new use case for it.
That distinction matters because of how acquiring economics actually work. Jonathan Ching’s breakdown of the payments processing value chain makes a point that is easy to forget. Headline acquirer pricing is remarkably uniform and transparent, so the acquirers that have actually grown share have done it by expanding the scope of what they sell into an existing merchant relationship (the PayFac model, the bundling of software and payments) rather than by competing on price. Ching argues that revenue growth “depends not so much on resizing the revenue pool or taking a greater share of the revenue pool, but rather on enhancing the value proposition delivered to merchants.” That is a card-acquiring analysis, written in 2020 about the US market, and I am extending it rather than quoting it as settled fact about Wero. The mechanism underneath it, where shared infrastructure serving a second use case is worth more than the same infrastructure serving only the first, is standard economics of scope rather than a novel claim, and in my view it applies with real force here.
Extend a payout engine so that it also originates Wero refunds and three things happen at once. The acquirer earns a reason to be the merchant’s payout provider for a second workflow and not just the first, which deepens share of wallet rather than merely defending it. The fixed cost of the underlying capability (the routing logic, the compliance stack, the monitoring) gets spread across a larger corpus of transactions, which improves the acquirer’s own unit economics. And the operating leverage compounds, because the marginal cost of serving one more use case on infrastructure that already exists is a fraction of the cost of building that infrastructure from nothing.
Verification of Payee and continuous screening ride the same shared stack
Push the compliance lever past its generic version and it splits into concrete obligations that are separately regulated, which matters because it shows exactly what is being amortised. The EU’s Instant Payments Regulation requires two distinct things of every euro instant transfer, in either direction.
For starters, there is Verification of Payee. From 9 October 2025, PSPs in the euro area must offer a free service that checks a payee’s name against their IBAN (or a VAT or LEI code) before a transfer is authorised, returning a match, no-match or close-match response under a rulebook the European Payments Council maintains. Second, there is sanctions screening. PSPs must move from per-transaction checks to continuous customer-level screening, at least daily, because a ten-second settlement window leaves no room to hold every payment for manual review.
Neither obligation cares whether the euro instant transfer in question is a pay-in or a refund, and that is precisely the point. The VoP integration, the screening engine and the monitoring stack get built once, for the acquirer’s payout book generally, and refunds then ride on top of infrastructure whose cost was mostly sunk elsewhere. An acquirer that already has all of this built is not doing more compliance work per Wero refund than a competitor, but the same compliance work at a lower marginal cost, because the corpus of transactions the fixed cost is spread across is bigger.
The edge case worth naming is what happens when screening cannot resolve cleanly. Real-time payment systems commonly build what the US Treasury’s OFAC calls “exception processing”, which means pulling a transaction out of the automated flow when a sanctions check throws an unresolved name match, or when the data needed to clear it is not yet available. A shopper whose refund is stuck in that state has no idea that the problem is data sufficiency rather than a lost payment. Handling that well at scale is a genuine operational discipline, and a mature payout operator already has a playbook for it whilst a newer entrant does not.
Resilience under Wero shows up as routing options and refund visibility
The same logic carries resilience past the question of whether the rail went down. A capable acquirer serves both batch processing (scheduled and lower-cost, which is fine for a payout that is not time-critical) and real-time settlement (priced at a premium, for the payout or refund that is), and the standard guidance to merchants is to keep both options open rather than commit to one. Layered on top of that choice is quality-of-service routing, where modern orchestration continuously scores partner and rail performance and reroutes automatically when one of them degrades.
The part merchants actually feel is observability. Major PSPs already expose refund and payout status as webhook events, and that is the plumbing that lets a merchant tell a shopper, correctly and immediately, that a refund has been issued and the funds have landed, rather than leaving them to wonder. I would file that as a small technical fact with a large commercial consequence.
Liquidity is the real cost lever on a Wero refund, and FX is not
An earlier version of this argument reached for FX variance as a cost lever. That was wrong for this specific case and worth correcting plainly. Wero rides SEPA Instant, which is euro-denominated throughout, so there is no currency conversion in the base flow and FX optimisation is not a live lever on a Wero refund.
What does move is liquidity. Because TIPS requires participants to be able to fund instant outbound payments round the clock, connecting to it pushes PSPs towards permanently larger central-bank buffers, and not only during banking hours, so that tied-up capital carries a real and ongoing opportunity cost. Treasury analysts covering the regulation’s rollout are direct about it. Liquidity is becoming “a permanent, structural cost item”, and institutions will have to decide whether to absorb it through better efficiency or pass it through to customers.
Helmer’s barrier test is what the reuse mechanism cannot pass on its own
Everything above (the reuse, the shared compliance stack, the batch-and-real-time flexibility, the QoS routing) is a real and defensible mechanism. It is also, on its own, an incomplete answer to the question this series set out to test, because a mechanism any acquirer can buy off a shelf is not by itself a source of durable advantage.
Hamilton Helmer’s 7 Powers framework is a useful check here. Distilled, his point is that a real competitive advantage needs two things at once: a benefit that improves cash flow, and a barrier that stops a rival from simply copying it. A payouts capability that tunes cost, speed, resilience and compliance per transaction clears the benefit test easily, so the question the framework forces is what the barrier actually is. A licensable orchestration layer, bought from a vendor and dropped in, clears the benefit test and fails the barrier test on its own.
Bolt the same payouts capability onto something an acquirer already owns and a rival cannot quickly copy, and it clears both tests at once, because the barrier was already there before the payouts layer arrived. The things that qualify are familiar enough: greater scale to spread the fixed cost of compliance and routing across, higher switching costs once payouts and refunds are unified under one operator, deeper distribution reach into a category of merchant, or software already embedded in the merchant’s own stack.
A mature payouts capability does not build an acquirer’s moat. It deepens whichever moat is already there, by giving an existing structural advantage a new surface to compound across, and it widens that advantage to a use case, Wero refunds, that a rival without the same base cannot profitably follow into.
The pooled book of an orchestration vendor could own the amortisation instead
The commoditisation risk deserves a more precise version, because a sharper thesis attracts a sharper counter-case. Suppose the shared capability behind all four levers (screening, VoP, routing, monitoring) is something an acquirer licenses from an orchestration vendor rather than builds. The amortisation advantage may then not belong to that acquirer at all. It may belong to the vendor, whose corpus is pooled across many acquirers’ payout and refund volume simultaneously, which is a bigger denominator than any single acquirer brings on its own. On that model the durable moat sits with the vendor’s pooled scale, or with whichever acquirer owns the underlying settlement relationships, balance sheet and risk data the licensed layer actually runs on, rather than with the acquirer who has simply bought the capability.
I would treat that as the honest bound on the thesis, and it is also what would falsify it. If the shared capability commoditises through vendors as fast as authorisation orchestration already has, then the advantage of extending rather than rebuilding still holds, but it accrues to the vendor’s pooled book rather than to any individual acquirer’s own volume, and that changes who actually owns the moat.
The direction of travel points at who already owns a moat
Part 1 argued that Wero unbundles control, coordination and settlement. Worked through on the return leg, the consequence is that it also unbundles risk from reversibility, and it rewards whoever has already amortised the machinery that risk requires, provided they had something worth amortising it onto in the first place.
For two decades the competitive question in acquiring was who owned the rails. Under a scheme built never to touch the money, the sharper question is who already has a moat worth deepening, and who has separately paid for the return leg’s machinery on somebody else’s use case, so that machinery can be pointed at this one for close to nothing extra. Payouts do not hand anyone a new moat, but they do hand an existing one a longer reach.