Pay-by-Bank Is Live in the UAE. Merchants Need Tooling.

Picture the finance controller at a mid-sized Dubai property-management firm. Every month she collects rent and service charges from a few thousand tenants. Roughly two to three percent of each card payment disappears into processing fees, a slice of cards get declined for no obvious reason, and chargebacks trickle in for weeks. Worse, her mornings vanish into a spreadsheet, matching incoming transfers against invoices by hand because half her tenants just wire the money with a vague reference line. She doesn't want a new payment "rail." She wants the fees lower, the money to arrive faster, and the reconciliation to do itself. Until recently, in her market, she had no real alternative. That just changed.

The real problem: merchants pay too much and reconcile by hand

The pain here isn't exotic. Across the UAE and the wider Gulf, merchants in high-value, repeat-billing categories — utilities and telecom, tuition, subscriptions, online marketplaces, B2B invoicing — typically eat card processing costs in the range of one-and-a-half to three percent or more per transaction. On a large or recurring bill, that adds up fast. Layer on declined cards, chargeback risk, and settlement that can take days, and "accepting a card" starts to look like an expensive habit rather than a convenience.

The people who feel this most acutely aren't the growth teams. They're the controllers, finance-ops staff, and accounts-receivable clerks — the ones reconciling statements against invoices, chasing mismatched references, and explaining to a CFO why a chunk of revenue evaporated in fees. That's the audience here: not consumers, but the back office that lives with how money comes in.

Why now: the rail finally went live

For years, "pay by bank" — letting a customer pay a merchant directly from their bank account, no card network in the middle — has been a mature, everyday option in the UK and parts of Europe under open banking rules. In the Gulf it was mostly a promise. That promise recently turned concrete: under the UAE's regulated Open Finance framework, infrastructure provider Lean and the payments app Ziina executed what they described as the country's first live, customer-initiated open-finance payment, including a one-tap "connect once, then top up with a single tap" experience.

That matters more than a single press milestone suggests. When a category moves from "theoretically allowed" to "a real customer just did it," a short window tends to open: standards aren't locked in, merchant integrations don't exist yet, and the UX conventions everyone will copy haven't been set. In markets like the UK, the rail came first and the merchant tooling — refunds, dispute flows, accounting plugins — got built afterward, often by focused independents rather than the rail operators. The Gulf is now at that "rail first, tooling missing" moment. The merchant problems are nearly identical to the ones already solved elsewhere; mainly the local bank and regulatory adapters differ. That portability is the opening.

How big, and where it's heading

Treat this as directional, not precise. The UAE is a multi-billion-dollar digital-payments market, and the slice that could plausibly shift toward account-to-account payments — bill pay, wallet top-ups, recurring and high-value commerce — is large and growing. Even a thin take on that volume, plus software fees, points to a revenue pool in the hundreds of millions of dollars a year in the UAE alone, with the broader Gulf and MENA region a multiple of that over time as coverage spreads.

You don't need the headline number to be exact for the logic to hold. A merchant doing several million dirhams a year in eligible volume at card-level fees has a concrete, recurring reason to switch part of it to a cheaper method — if, and only if, the switch doesn't make their finance team's life harder. The prize is real; capturing it is an execution problem, not a demand problem.

The realistic landscape: the rail exists, the merchant layer doesn't

Be clear-eyed about who's already here. Lean is positioned as a leading regional financial-infrastructure provider — bank connectivity and payment initiation. Ziina is a consumer and SME payments app with transfers, card acceptance, and invoicing, and it threw the first live punch. Around them sit the usual suspects you'd expect to move in: traditional payment processors and acquirers that could bolt on a "pay by bank" button, large wallets and super-apps that might build their own closed version, and global open-banking-payments vendors that tend to enter the Gulf once the volume justifies the trip.

Here's the catch, and it's the whole thesis: most of these players treat pay-by-bank as "just a rail," assuming that if the plumbing works, merchants adopt on their own and the infrastructure owners capture the value. In practice, adoption tends to stall without the unglamorous workflow layer — saved consent so repeat customers pay in one tap, clean refund handling, settlement reporting a controller can actually use, and automatic matching of payments against invoices in tools like QuickBooks or Xero. Infrastructure companies often underinvest in that verticalized tooling; processors can be slow to push a method that undercuts their own card economics. The whitespace isn't the rail. It's making the rail operationally easier for a finance team than cards already are.

How you could start

If you wanted to test this without becoming a regulated bank, a realistic path looks something like:

• Stay a software layer, not a money handler. The heavy regulation lands on whoever initiates payments or touches customer funds. You can often sit above that by partnering with a licensed open-finance provider and an existing wallet, orchestrating consent and reporting while never taking custody. Get a real legal opinion in your specific market before you write a line of production code — this is the make-or-break gate, not an afterthought.
• Pick two or three beachhead verticals, not "all merchants." Categories like property management, education/tuition, telecom and subscriptions, or B2B invoicing share high transaction values and painful card costs. Tolerance for asynchronous confirmation (an invoice that clears in a few minutes is fine) makes them more forgiving than impulse retail.
• Lead with reconciliation, not the checkout button. The button is easy and everyone will have one. The defensible value is the finance-ops automation behind it: statement import, matching rules, refund orchestration, and accounting-tool connectors. That's what a controller will switch for and won't want to rip out.
• Run a concierge pilot before building much. Try to sign a handful of merchants on a "free for sixty days in exchange for a case study" basis, even via a simple hosted payment page. Watch two numbers: how many of their eligible customers choose pay-by-bank when shown next to a card, and the payment success rate. If a meaningful share opt in and success holds up, you have signal.
• Manufacture distribution through partners. There's no consumer audience to ride here. Co-sell with the infrastructure providers and wallets that need merchant acceptance, and build channel relationships with accounting firms and ERP implementers who already advise these finance teams.

On pricing, stay illustrative and let pilots correct you: a model here might pair a modest monthly software fee with a small per-volume charge that still lands well under typical card costs — say, a starter plan in the low hundreds of dollars a month, scaling to custom enterprise arrangements with deeper reconciliation. Treat those as hypotheses, not promises.

What to watch for

This is a high-regulation, high-trust category, so respect the failure modes. Licensing comes first: if a legal review says your "software only" structure still requires a payment license, the economics change and you should be willing to stop. Bank coverage and reliability comes second — if payments fail or confirmations lag for the banks your merchants actually use, the experience loses to cards and no dashboard polish saves it; start with use cases that tolerate retries. Third, incumbents can bundle a pay-by-bank option into existing contracts at near-zero added cost, so your defensibility has to live in finance-ops depth they won't bother to build. And account-takeover and dispute handling differ from cards; you'll need real fraud controls and auditable logs from day one.

Who is this not for? Anyone hoping for a quick consumer-app hit, or a founder without patience for enterprise sales cycles and compliance conversations. This is a back-office, B2B, trust-heavy build. But for an operator who enjoys making a controller's month-end easier, the timing is unusually good.

Key takeaways

• A regulated pay-by-bank rail is now live in the UAE; the missing piece is merchant-grade tooling, not connectivity.
• The real buyer is the finance team drowning in card fees and manual reconciliation — sell to them, not to consumers.
• Win on the unglamorous layer: saved consent, refunds, settlement reporting, and accounting-tool matching.
• Structure as non-custodial software on top of licensed partners, and get the legal read before building.
• Treat all market and pricing figures as directional; validate with a small concierge pilot before scaling.

Tools that help

• Lean — regional open-finance infrastructure for bank connectivity and payment initiation you'd build on top of rather than replicate.
• Stripe Billing — recurring software fees and usage-based charges for a merchant SaaS layer.
• QuickBooks / Xero — the accounting tools your reconciliation connectors need to plug into to win finance teams.
• Shopify / WooCommerce — common storefront platforms to ship checkout plugins for early merchant distribution.

_Some links may be affiliate links._

FAQ

Do I need a payment license to build this?

It depends entirely on your structure and market. If you initiate payments or hold customer funds, you very likely do. Many builders aim to stay a non-custodial software layer on top of a licensed partner — but that's a question for a qualified local lawyer before you build, not a detail to settle later.

Why would a merchant switch from cards if cards already work?

Cards work but often cost one-and-a-half to three percent or more, suffer declines, and carry chargeback risk. For high-value or recurring bills, a cheaper, faster, lower-dispute method is attractive — provided it doesn't make reconciliation harder. That last condition is the whole game.