Two very different questions get asked in the same sentence.
The first is whether a business can offer customers the option to pay in crypto. The second is whether a business can operate as a virtual asset business.
They have completely different answers, and the confusion between them is why so many conversations about this go badly. Most businesses asking about crypto payments have not established which question they are actually asking, and the answer to one tells you almost nothing about the other.
This article covers what Dubai's regulator actually regulates, the marketing rules that reach further than people expect, and what a merchant should establish before integrating anything.
Two businesses, two completely different conversations
The clearest way to see why the opening distinction matters is to follow two businesses through it.
A furniture retailer in Dubai wants to offer crypto at checkout because a handful of customers have asked. The right shape for them is a regulated payment provider that accepts the customer's crypto and settles the retailer in dirhams the same way a card processor would. The retailer never holds a virtual asset. Their questions are commercial: what does the provider charge, how fast do they settle, what happens to a payment if the price moves between order and settlement, and what customer information does the provider need. Their integration is a checkout change. Their finance team learns one new reconciliation flow. Nobody applies for anything.
A startup building a platform where users can hold balances, exchange between assets, or lend to each other is in a different world entirely. Every one of those verbs maps onto one of the eight regulated activities. Their first conversation is with a regulatory adviser, not a developer, and it determines whether the product as conceived is even the product they can build. Structuring decisions, including whether custody has to sit in a separate entity, come before architecture rather than after it.
The reason to lay these side by side is that both businesses will describe what they are doing as "accepting crypto" in early conversations, and both will be told by enthusiastic vendors that it is straightforward. For one of them it genuinely is. For the other, the vendor is answering a question that was not asked.
Work out which of the two you are before you do anything else. If your product involves holding, exchanging, transferring, lending or issuing on behalf of users, you are the second business regardless of how the feature is described internally.
Dubai has a dedicated regulator
The Virtual Assets Regulatory Authority, VARA, operates a licensing regime for virtual asset activity in Dubai and publishes a detailed rulebook [1][2].
That it is a dedicated authority rather than a department inside a broader regulator is itself informative about how the activity is treated here.
Note the geography carefully. VARA's remit is Dubai. Other emirates and the financial free zones have their own arrangements, and the Central Bank regulates financial institutions and payment activity under its own framework [7].
Establishing which regime applies to your specific entity and activity is the first question rather than a detail. Getting it wrong means preparing for the wrong regulator, which is an expensive category of mistake.
The eight regulated activities
VARA identifies eight distinct virtual asset activities that define the regulatory perimeter [3][4]:
| Activity |
|---|
| Advisory services |
| Broker-dealer services |
| Custody services |
| Exchange services |
| Lending and borrowing services |
| Management and investment services |
| Transfer and settlement services |
| Virtual asset issuance |
If what you are doing sits inside one of those, you are looking at a licensing question rather than a commercial one, and the conversation moves from your development team to a regulatory adviser.
A provider can apply to be licensed for multiple activities and aggregate them under a single overarching licence, with one exception. Virtual asset custody services must be segregated from other licence categories, and a custodian must be established as a distinct legal entity holding a standalone licence [3].
That separation requirement is worth understanding early, because it shapes how a business structures itself before applying. Holding other people's assets is a categorically different risk from advising on them or facilitating a trade, and the separate entity limits what a failure elsewhere in a group can reach. Retrofitting that structure after the fact is considerably more expensive than designing for it.
VARA publishes a substantial set of rulebooks covering company obligations, compliance and risk management, technology and information, and market conduct, alongside activity-specific rulebooks for each licensed activity [2][5]. It is a developed framework rather than a short statement of principles.
The distinction that decides everything for a merchant
Here is the question to settle before any other.
Do you hold the asset, or does a provider convert it?
In the first arrangement, your customer sends crypto and you receive and hold it. That raises questions about custody, volatility, accounting treatment, key management, and potentially about whether your activity falls inside a regulated category.
In the second, a regulated provider takes the customer's crypto and settles you in dirhams. You never hold the asset. Commercially it behaves much more like accepting an additional payment method.
Most businesses that say they accept crypto mean the second, and many have never explicitly established which they have agreed to.
For almost every ordinary business, settlement in fiat through a regulated provider is the right arrangement. You get the commercial benefit of offering the method without taking on price volatility, custody risk, or the accounting complexity of a volatile asset on your balance sheet.
Holding the asset is a treasury decision, not a payments decision, and it should be made on that basis by whoever makes treasury decisions rather than arriving as a side effect of a payment integration.
The marketing rules reach further than expected
This is the part that catches businesses who are not crypto businesses at all.
VARA has published regulations on the marketing of virtual assets and related activities, and they apply to all entities, including domestic and foreign ones, and whether or not those entities are licensed by VARA to carry out virtual asset activities [6].
Marketing is regulated as an activity in its own right rather than as something that follows automatically from holding a licence.
For unlicensed providers there is a specific route with a specific restriction. Providers not licensed by VARA may still conduct marketing activities in or from Dubai provided the relevant marketing permit is obtained. But unlicensed providers are not permitted to onboard Dubai residents as customers, and marketing material must carry disclosures clearly indicating that the products or services are not available for residents of Dubai [6].
That disclosure requirement is substantive rather than cosmetic. Burying it in small print at the foot of a page is unlikely to satisfy the intent even if it technically appears somewhere.
Does this touch a business that merely mentions crypto? Possibly, and it is worth checking rather than assuming. The regulations are framed around marketing virtual assets and related activities rather than around being a crypto company. A business promoting an unrelated product that happens to accept crypto payments is in a different position from one promoting a virtual asset product, and where exactly that boundary falls is a question for an adviser rather than for inference.
Verify the provider, on the register
VARA operates a public register alongside its licensing pages [8].
Use it. Check whether a provider you are considering is actually licensed, and for which specific activities, rather than accepting a claim in conversation or a certificate image in a pitch deck. A provider licensed for one activity is not thereby licensed for another, and the register is where that distinction is visible rather than in their marketing.
Check at the point of signing rather than relying on something you saw three months earlier, because status can change and the register is the authoritative version.
Five questions for any provider, in writing:
Which regulator licenses you, for which activity, and where do I verify that?
Do we ever hold the asset, or are we settled in fiat?
What is the settlement timing?
What happens if the asset moves in price between the customer's order and settlement, and who bears that?
What compliance obligations of yours flow through to us in terms of customer information?
That last one matters more than it sounds and is covered below.
What changes operationally
Four things behave differently from card payments, and teams discover them in roughly this order.
Irreversibility. A confirmed transaction generally cannot be reversed. Your team is accustomed to chargebacks as a safety net, which means fraud has been partly a financial problem you could recover from. Here it shifts to something you must prevent beforehand rather than dispute afterwards. That changes your checkout controls and it changes the risk calculus on suspicious orders.
Refunds. If you were settled in dirhams, refunding in dirhams is straightforward. If you hold the asset, refunding raises a genuine question: do you return the same quantity or the same value? Those are different amounts, and the difference can be large. Settle it in your policy before your first refund rather than during it, and state it clearly before purchase, because consumer protection obligations do not relax because the payment method is unusual. Our guide on consumer protection for online sellers covers what those obligations are.
Customer information. Your provider's compliance obligations flow through to you, and they frequently require more customer information than a card payment does. That affects your checkout design, your data protection position, and your storage obligations. Ask specifically what you must collect and retain before you integrate, and check that your checkout can actually gather it without adding friction that costs you more orders than the payment method wins. Our guides on PDPL compliance and data retention cover what collecting more customer data commits you to.
Reconciliation. More work than a card processor, because the flow is unfamiliar and your finance team has not seen it before. Budget attention for the first month specifically, and have somebody check the first few statements line by line rather than accepting the totals, which is the pattern worth following with any new payment rail. Our guide on UAE payment gateways covers the conventional acceptance layer this sits alongside rather than replaces.
Do not build the integration yourself
Among the clearest build-versus-buy decisions available.
Building a direct connection to a blockchain for payment acceptance means taking on custody, key management, confirmation handling and volatility. Every one of those is a specialist problem, and they share an uncomfortable property: none has a partial failure mode.
Key management above all. Losing access to a private key is irreversible in a way that no other business system is. There is no support line, no reset, no backup restore that fixes it.
Use a regulated provider's integration. Our guide on build versus buy covers the general reasoning, and this case sits at the extreme end of it.
Establish the business case separately
Whether there is genuine customer demand is your question to answer with your own data, not one to take from a vendor's deck.
Do customers ask for it? Do you lose sales without it? Do the segments you want to reach actually use it?
Adding a payment method because it is prominent in the news is not a business case. The integration costs effort, the provider charges fees, reconciliation consumes finance time every month, and somebody has to learn a settlement flow they have never seen.
Price the second year rather than the setup. That is the honest test for any new payment rail, and it is the number that decides whether this earns its place.
The questions we will not answer
Worth stating plainly, because technology firms routinely answer these and should not.
Whether your specific activity requires a licence. That turns on the regulatory perimeter applied to your facts, and it belongs with a qualified regulatory adviser.
Your tax treatment. Virtual asset tax treatment is a matter for the Federal Tax Authority and your tax adviser, interacting with corporate tax and VAT in ways that depend on your activity. Do not assume a treatment by analogy with another market. Establish it before you start rather than at your first return.
Your accounting treatment. How the asset is classified, valued at reporting dates, and how gains and losses are handled is a question for your accountant. It is another reason the settle-in-fiat route is simpler: it keeps a volatile asset off your balance sheet and your reporting familiar.
What we can tell you is how the technology works, what integrating it involves, and what it will cost to build and run.
Who should own the decision
Finance, with technical support, rather than marketing or technology.
The decisions that matter are about volatility, settlement, reconciliation, tax and accounting. All of those are finance questions.
When this is driven by marketing enthusiasm or technical curiosity, the parts that create actual risk receive the least attention, and the business ends up with an integration nobody in finance understands and a reconciliation process nobody designed.
Where this sits against your other payment rails
It helps to place crypto next to what you already run rather than treating it as a separate category with its own logic.
Against cards, it is slower to settle in some arrangements, materially different on reversibility, and unfamiliar to your finance team. Cards remain the default for good reasons and nothing here displaces them.
Against buy now pay later, the comparison is instructive. Both are additional methods that add reconciliation work and a second supplier relationship. BNPL has a clearer commercial rationale for most retailers, because instalments change affordability in a way that is easy to reason about. Crypto's rationale is usually about reaching a specific customer segment, which is a narrower and more checkable claim. Our BNPL guide covers how to test whether an additional method is genuinely incremental rather than cannibalising, and the same test applies here.
Against bank transfer, crypto settles faster and costs more, which is the trade for a set of customers who prefer it.
The general point is that every additional payment method has a fixed operational cost that recurs monthly regardless of volume: reconciliation, support knowledge, an extra statement to check, and a relationship to manage. That cost is worth paying when a method brings customers you would otherwise lose. It is not worth paying for a method a handful of people mention and nobody uses.
So before adding this, look at what your existing methods already cover and ask which specific customers are currently unable to pay you. If you cannot name them, the honest answer is to wait until you can.
A checklist before you integrate anything
Twelve items. If you can answer all of them in writing, you are ready. If you cannot answer four or more, you are not.
The arrangement. Do we ever hold the asset, or are we settled in fiat only?
The regulator. Which authority licenses the provider, for which activity, and have we checked the register ourselves?
Settlement. How long between the customer paying and the money arriving, and does that change under load?
Price movement. Who bears the difference if the asset moves between order and settlement, and over what window is that measured?
Fees. What is the total on our actual volume, including anything charged on refunds?
Customer information. What must we collect, why, and where will it be stored?
Refunds. On what basis, quantity or value, and is that stated in our policy before purchase?
Reconciliation. What does the statement look like, and has our finance team seen one?
Failure handling. What happens to an underpaid, overpaid or late transaction, and who resolves it?
Support. Who does a confused customer contact, us or the provider, and what can we actually see?
Exit. What is the notice period, and what happens to in-flight transactions if we stop?
Tax and accounting. Has our adviser confirmed the treatment for the arrangement we are actually entering?
Most of those are single questions with single answers, and a provider who cannot supply them quickly is telling you something about how the relationship will run once you are integrated.
The honest summary
If customers genuinely want it: use a regulated provider that settles you in dirhams, verify their licence on the register, get the settlement and refund mechanics in writing, and treat it as a payment method rather than a treasury strategy.
If customers are not asking for it: the integration and reconciliation cost is real and continuing, and the benefit is speculative.
Before committing to anything, establish in writing whether you hold the asset, which regulator licenses the provider and verified how, how settlement and timing work, who bears price movement between order and settlement, and what customer information you must collect. Then take the tax and accounting questions to your adviser.
That is about a week of work spread across a few conversations, and it settles everything material before you have committed to anything or written a line of integration code. Businesses that skip it end up making the same decisions later with less information and more sunk cost behind them.
For the regulatory position itself, go to VARA's own site and rulebooks for Dubai, to the relevant authority for wherever your entity actually sits, and to the Central Bank for the broader financial framework [1][2][7]. All of them publish current material, which is more reliable than any summary including this one, because this area is developing quickly and a summary ages faster here than almost anywhere else.
If you want implementation help, integrating a regulated provider into an existing checkout, designing the refund and reconciliation flows, and reviewing what customer information the arrangement requires you to collect and store starts from around AED 4,000 with us. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- Virtual Assets Regulatory Authority
- VARA Rulebook
- VARA, licensed activities
- VARA Rulebook, Part I, licence approval and registration requirements
- VARA Rulebook, Market Conduct Rulebook
- VARA, Regulations on the Marketing of Virtual Assets and Related Activities 2024
- Central Bank of the UAE, legislation
- VARA, public register
- SKIMBOX, UAE payment gateway comparison
- SKIMBOX, consumer protection for online sellers in the UAE
- SKIMBOX, build versus buy for UAE businesses
- SKIMBOX, PDPL compliance in the UAE
VARA's remit is Dubai; other emirates and the financial free zones have separate arrangements. This area develops quickly and rulebooks are amended, so confirm the current position with the relevant authority. This article is not legal, regulatory, tax or accounting advice, and whether a specific activity requires a licence is a question for a qualified adviser.
