Payment Gateway or Merchant Acquirer? UAE Setup Guide

CBUAE's Retail Payment Services and Card Schemes Regulation sets the perimeter for retail payment services in the UAE, and it tests function rather than brand name. Calling a product a "gateway" does not place it outside scope, and calling it a "facilitator" does not place it inside. The questions that move a business across that line:

A hit on any of these does not automatically mean the company itself needs authorisation: a licensed sponsor institution may lawfully carry that function under contract. It does mean the position has to be written down and tested against the facts, not assumed from the software the product resembles. A platform that in fact holds value or arranges credit is regulated regardless of what the app is called.

CBUAE's Retail Payment Services and Card Schemes Regulation licenses nine retail payment services in four categories. Merchant acquiring and payment aggregation fall in Categories I, II and III under Article (3). Initial capital under Article (6) runs from 100,000 Dirhams for Category IV up to 3 million Dirhams for Category I where monthly payment value reaches 10 million Dirhams. Category IV covers payment initiation and payment account information services. CBUAE alone confirms which category a given model falls into, so check the current figures against its published rulebook before relying on any number quoted elsewhere.

Banks and sponsor institutions each run their own diligence before onboarding a payments business, and both start from the same question: whose authorisation covers each flow of money. Before approaching either, have ready:

A facilitator that nets settlement before paying merchants carries different exposure than a gateway that never touches funds, and a bank reads the file accordingly. A clean banking readiness file, built before a sponsor or bank conversation starts, removes the questions that stall onboarding; it does not replace the authorisation decision itself. Velarozone's work on corporate bank account readiness sits alongside that decision, not instead of it.

The entity that contracts with the merchant has to be able to answer for the product, either on its own authorisation or a sponsor's. A technology vendor, an agent and a principal carry different obligations even inside the same product, and a sponsor contract has to name which role each party plays. Group structures can put technology, intellectual property and the authorised function in separate entities, but each entity needs a genuine role: a shell that exists only to look cheap on a formation invoice surfaces later as a sponsor-diligence failure or a bank-onboarding delay. The management, compliance and risk roles a model needs are set by whichever authorisation or sponsor tier applies, not by the founders' preference.

Comparing incorporation fees is the most common mistake of all. Compare complete routes instead: year-one and renewal cost, capital and safeguarding, sponsor economics, permitted functions, banking implications and the cost of switching tier after launch.

Registration is the fastest stage of this process and the least meaningful one. Scheme membership, sponsor onboarding and any CBUAE authorisation each add review time the business cannot compress, and CBUAE sets its own timeline once an application is lodged: no adviser can shorten it or guarantee its outcome. Once live, supervision or programme fees, audits, reporting and renewals recur every year the authorisation or sponsor contract runs. Cost is built in layers rather than one headline number, and the Velarozone fee for this work is itemised in the engagement letter; see how Velarozone works for how those layers are priced. Businesses building a payments product inside a wider fintech setup should fix this sequence before any jurisdiction is chosen.