Lean and Ziina Turn UAE Pay by Bank Into a Checkout Test

Open Finance in the UAE will not be judged in a regulator deck.

It will be judged on a checkout screen.

Finextra reported that Lean Technologies and Ziina launched what they describe as the UAE's first one-tap Pay by Bank experience under the Open Finance framework. The signal is narrow enough to be practical and big enough to matter: account-to-account payment is moving from "connect your bank account" infrastructure into a merchant-facing checkout moment.

That changes the product question.

The question is no longer whether Open Finance APIs exist. The question is whether a customer who already understands cards, wallets, Apple Pay, and cash-on-delivery will trust a bank-to-bank checkout enough to complete the payment.

That is where Pay by Bank either becomes a real rail or stays a clever alternative payment method.

One Tap Is The Product Promise

"One tap" sounds like a UX claim. In payments, it is an operating claim.

It means consent, bank selection, account access, payment initiation, confirmation, settlement evidence, refunds, reconciliation, support, and risk controls have to disappear behind a simple action. The customer should not feel the stack.

This is exactly why open banking product architecture is harder than API access. The API is table stakes. The conversion surface decides whether merchants care.

Cards have decades of customer trust behind them. Customers know the symbols, rewards, chargebacks, issuer alerts, stored credentials, and failed-payment behaviours. Merchants understand authorization, capture, settlement, disputes, interchange, and acquirer reporting. Even when card rails are expensive, they are familiar.

Pay by Bank has a different value proposition: lower cost, potentially faster settlement, direct bank account funding, less card-data exposure, and cleaner account-to-account movement. But if the user flow feels uncertain, the theoretical economics will not save it.

That is the checkout trade-off.

Gulf Payments Are Ready For A Better Local Rail

The UAE is a good market for this test because merchants already operate in a mixed payment environment: cards, wallets, bank transfers, cash, remittance-linked flows, QR-based experiences, and platform-specific stored value. The Gulf also has a dense mix of SMEs, marketplaces, service businesses, cross-border consumers, and digitally active bank customers.

That makes local payment method design more important than generic card processing.

For a merchant, Pay by Bank can become attractive if it improves total payment economics without damaging conversion. Lower cost alone is not enough. The rail has to be fast, familiar, and explainable at the moment of payment.

That is the lesson from local payment methods and developer experience. Merchants do not adopt rails because the infrastructure is elegant. They adopt rails when the integration is clear, the dashboard explains what happened, the reconciliation file matches the finance workflow, and support teams can answer customer questions.

Lean and Ziina are testing that full chain.

The Real Competition Is Trust

Pay by Bank is not only competing with cards on cost. It is competing with cards on trust.

A customer at checkout asks practical questions, even if they never say them out loud:

Will this work? Is my bank account safe? Can I reverse a mistake? Will the merchant know I paid? Will I get the product now? What happens if the payment is pending? Why am I being sent to my bank?

Those questions are product requirements.

If the checkout copy is vague, conversion drops. If the bank handoff is slow, conversion drops. If confirmation is delayed, merchant support gets hit. If refunds are clumsy, the finance team resists the rail. If settlement evidence is weak, operations loses confidence.

The strongest Pay by Bank product teams will design for those fears directly. They will not describe the rail as "Open Finance." They will describe the outcome: secure bank payment, instant confirmation, no card needed, clear refund path, and a trusted local payment method.

Settlement Is The Merchant Proof Point

For merchants, the economics only matter when they show up in working capital and operations.

If Pay by Bank reduces processing cost but creates manual reconciliation work, the CFO will not love it. If settlement is faster but refunds and exceptions are unclear, support will push back. If the rail improves cash timing but finance cannot tie payments to orders, the benefit gets lost.

That is why settlement windows and merchant trust should be part of the product story from day one.

The rail needs a merchant-facing operating model:

Payment state, settlement state, refund state, failed-payment reason, customer evidence, reconciliation reference, support workflow, and escalation path.

A2A rails often talk about speed. Merchants remember ambiguity.

What I Would Measure First

If I were running this launch, I would not only measure payment volume.

I would measure Pay by Bank display rate, selection rate, bank-handoff completion, payment success, time to confirmation, fallback to card, refund cycle time, support contact rate, and merchant reconciliation defects.

Then I would segment by merchant category. Food delivery, invoices, retail checkout, subscriptions, professional services, and marketplace payments will not behave the same way.

I would also watch the language. "Open Finance" may work for regulators and banks. It rarely works for customers. The winning label may be "Pay from bank," "bank payment," "instant bank pay," or something else entirely.

That naming decision will matter more than most teams expect.

Actionable Takeaway

For UAE and Gulf payment teams, this launch is a reminder that Open Finance adoption is a product design problem, not only a regulatory implementation problem.

Build the checkout around customer trust. Build the merchant back office around settlement clarity. Build the developer experience around low-friction integration and clean operational evidence.

If Pay by Bank can do those three things, it becomes a serious local rail. If it cannot, it becomes another payment option merchants turn on, watch underperform, and quietly de-prioritize.

The operator question: when your merchant sees Pay by Bank in the dashboard, does it look like a cheaper experiment or a rail they can confidently run at scale?

For payment teams that need help turning rails into commercial product systems, start with the operating model behind the checkout: work with Rizwan or review the proof points on product work.

FAQ

What did Lean and Ziina announce?

Lean Technologies and Ziina announced a one-tap Pay by Bank experience in the UAE under the Open Finance framework, positioning account-to-account payment as a checkout option.

Why does Pay by Bank matter for merchants?

It can reduce card dependency, support direct bank-funded payments, and improve payment economics if conversion, settlement evidence, refunds, and reconciliation are strong.

What should product teams measure first?

Measure selection rate, bank-handoff completion, payment success, confirmation time, fallback behaviour, refund cycle time, support contact rate, and reconciliation defects.