Executive Summary
- UAE: Select a provider-led checkout using a dirham payment token issued by a CBUAE-licensed issuer. Limit the first pilot to UAE-resident payers and authorised merchant categories. Launch only after the provider's permissions, banking arrangements and required outsourcing approvals cover the specified route. Payment Token Services Regulation, Circular 2/2024 (PTSR), Articles 2(1), 2(4), 2(6)–(7), 19–20.
- UAE: A foreign payment token is not an alternative for ordinary merchant purchases. Its payment-use exception concerns purchases of virtual assets or their derivatives. Immediate conversion into AED does not remove the provider's separate transfer restriction. PTSR, Articles 2(4)–(7).
- Dubai: VARA permission cannot replace CBUAE payment-token permission. Dubai mainland falls within VARA's territorial remit, but VARA expressly preserves applicable CBUAE requirements. The DIFC exclusion does not authorise a mainland checkout. Dubai Law 4/2022, Article 3; VARA Regulations, III.A.4(b); PTSR, Article 2(13).
- UAE: Keep the startup's first-launch role technical. Token custody, conversion offers and merchant-acquiring-style token services require separate classification. An approved agency arrangement is a possible alternative, but a vendor contract alone does not establish it. PTSR, Articles 1(52), 1(54), 19.
- UAE and India: Put the financial customer contracts, binding conversion quote, token control and AED settlement undertaking with appropriately authorised entities. Indian support access must satisfy the provider's outsourcing and data requirements. PTSR, Articles 20, 28; Outsourcing Regulation for Banks, Circular 14/2021, Articles 6, 8.
- India and payer countries: Exclude Indian-resident payer routes from the initial pilot. RBI's cross-border payment-aggregator rules impose payment-instrument and foreign-exchange conditions that UAE permission cannot satisfy. Assess Indian funding separately before establishing a regulated UAE subsidiary. RBI Payment Aggregator Directions, 2025, paragraph 11; Overseas Investment Master Direction, paragraph 21(7).
Participants and ownership through settlement
The transaction map must identify legal entities before assigning regulated roles. The merchant supplies the underlying goods or services and invoices in AED. The payer owns or acquires the payment token. Its issuer defines the token's rights and redemption obligations. An originating wallet service may transmit it, while a different business controls the receiving address. A converter, settlement provider and settlement bank may each perform separate functions.
For the proposed model, the merchant sends an AED invoice to the checkout. The authorised provider supplies the binding token quotation, fees, expiry and destination address. The startup displays those instructions without independently offering conversion. The payer accepts the financial provider's terms and sends the specified token through an approved wallet route.
The receiving provider accepts the token in the capacity stated in the merchant and payer agreements. Those agreements must identify beneficial ownership during receipt and conversion, and the event that discharges the purchase debt. A designated converter then redeems or sells the token. The identified AED settlement obligor instructs payment through its agreed banking route into the merchant's account. Neither customer tokens nor merchant settlement money enters the startup's account under this design.
The map must include every subcustodian, liquidity counterparty, key holder and bank-account owner. It must also show rejected payments, expired quotations, partial payments and refunds. A refund involves its own recipient, authorisation and currency decision; it should not create an unexamined stored balance. These proposed allocations implement the customer-information and safeguarding duties in PTSR Articles 23 and 28.
Permitted tokens for ordinary merchant purchases
The permitted first-launch token is a dirham payment token issued by a licensed issuer. Under Article 2(7)(a), a merchant may accept that token towards a business sale. Article 2(7)(b) permits the foreign-token alternative only for a purchase of a virtual asset or virtual-asset derivative. Registration of a foreign issuer does not extend that exception to ordinary goods or services. PTSR, Article 2(7).
The provider faces a separate restriction. Article 2(4) prohibits a licensee or registree from knowingly initiating, facilitating, effecting or directing a token transfer outside the specified permitted uses. A provider that receives a foreign token for an ordinary merchant purchase cannot rely solely on paying the merchant AED afterwards. The customer's token transfer remains part of the provider's payment service. PTSR, Articles 2(4)–(5).
A contrary characterisation would treat the customer as independently selling an asset, then spending separate fiat proceeds. That requires a genuinely different transaction: the seller's own proceeds, a separate payment obligation and contracts reflecting those events. It cannot be established merely by labelling an integrated checkout a conversion service. Even that redesign must satisfy the restrictions applicable to its token transfer and conversion. No foreign-token off-ramp is included in the recommended launch.
The phrase “stablecoin” does not establish eligibility. PTSR Article 1(51) defines a Payment Token by its claimed stable value and reference currency, subject to CBUAE designation. Article 12 distinguishes dirham and foreign-currency denominations. Article 2(3) separately prohibits the specified algorithmic-stablecoin and privacy-token services. The product should therefore use one identified token and network, with permission checked against that exact instrument.
Search terms including “payment token license UAE”, “stablecoin payments UAE” and “crypto payment gateway UAE” describe commercial interests. The official service categories are Payment Token Issuance, Payment Token Conversion, and Payment Token Custody and Transfer. The token's permitted use must be established before choosing among those categories. PTSR, Article 1(59) and Article 5.
A small pilot does not itself create an exemption. Article 4 addresses specified reward, bonus-point and issuer-only arrangements, plus a discretionary small-issuer exemption. The proposed general merchant checkout should not rely on those exceptions merely because it starts with few users. Its first launch should use the licensed-provider route. PTSR, Article 4.
Dubai, the Central Bank and financial free zones
CBUAE regulates the payment-token activity. Article 2(1) reaches services performed within the UAE or directed to persons there. Hosting the API abroad or using an Indian contracting company does not remove a service directed to mainland merchants from that wording. Federal Decree-Law 6/2025, Articles 61–62, also addresses licensed financial activities performed through digital infrastructure.
Dubai Law 4/2022 applies throughout Dubai, including its ordinary free zones, except the DIFC. VARA's Regulations expressly require compliance with applicable CBUAE rules, including payment-token requirements. A business may need VARA permission for a separate virtual-asset activity while also requiring CBUAE permission for its payment service. Neither a VARA badge nor a general virtual-asset custody permission establishes the latter. Dubai Law 4/2022, Article 3; VARA Regulations, III.A.4(b); PTSR, Article 8.
PTSR Article 2(13) excludes financial free zones from that article's references to the UAE. Federal Decree-Law 6/2025, Article 2, also preserves the financial-free-zone boundary. Those exclusions do not grant a DIFC business permission to provide the proposed service to Dubai mainland customers. This launch should use a provider whose permission covers the mainland activity; a DIFC-only product requires its own territorial analysis.
Token acquiring, fiat payments and stored value
The receiving entity may perform Payment Token Custody and Transfer. Article 1(54) covers safeguarding customer tokens or their private keys, and receiving, holding and transferring tokens for customers. It expressly includes merchant-acquiring-style arrangements that allow merchants to receive payment tokens for goods or services. Token acquiring therefore requires examination under the PTSR itself.
The converter performs a different function. Article 1(52) covers remunerated spot purchases or sales as principal or agent. It also covers enabling counterparties to place and accept offers. A business can cross this boundary through its conversion marketplace or contracting role without holding customer assets. Issuance is separate again: the first business sale or transfer can constitute issuance, including the distribution arrangement addressed in Article 1(58). A checkout should not add token distribution without examining that provision.
The AED leg must then be classified on its own facts. Under the Retail Payment Services and Card Schemes Regulation (RPSCS), merchant acquiring involves contracting with a payee to accept and process transactions resulting in transferred funds. Payment aggregation includes receiving, pooling and transferring customer payments to merchants. Payment initiation can occur without holding funds. RPSCS, Circular 15/2021, Article 1(60), (66), (68).
This does not mean that every token checkout requires two permissions for the same service. PTSR Article 39 removes the specified crypto-asset and virtual-asset activities from the earlier RPSCS and SVF regimes after the transition period. Its Exclusions also distinguish activities requiring permission under those other regulations. Classify the token service and each additional fiat function separately. Do not rely on a legacy payment-token entry in an older payment-services licence.
A reusable fiat balance requires an additional assessment. The SVF definition combines payment to an issuer, stored value and the specified undertaking to supply goods, services or payment to another person. A retained refund balance may engage that definition or payment-account rules, depending on its operation. The first model should settle and refund without offering a reusable balance. SVF Regulation, Circular 6/2020, Article 1(27)–(29); PTSR, Article 39.
A genuine technical-provider model
The startup can retain its software and merchant-facing interface without automatically becoming the financial provider. Article 1(54) excludes technology supplied to another person for that person's own token safeguarding, administration or transfers. That exclusion does not cover independently providing the underlying service to customers. The RPSCS technical-support exclusion also preserves the separate treatment of payment initiation. PTSR, Article 1(54); RPSCS, Exclusions 6–6.1.
For technology supplied to a provider holding customer tokens, the startup must also examine the PTSR infrastructure exclusion. It applies only where the technical service does not itself constitute a Payment Token Service. Supplying a custodian's software should not be misdescribed as the merchant administering its own wallet. PTSR, Exclusions 2.
The broader statutory test also matters. Federal Decree-Law 6/2025, Article 62, reaches direct or indirect provision and facilitation through technology. In FAQ 6 concerning that law, CBUAE distinguishes technical supply exclusively for a licensed institution's benefit from professionally conducting or offering a financial activity. The FAQ is explanatory guidance and remains subordinate to the legislation.
The recommended allocation gives the authorised provider the merchant payment contract and the payer financial-service contract. It approves onboarding, binding financial quotations, recipient addresses, transfer instructions, conversion and settlement. The startup displays provider-approved information, maintains the API and handles defined support tasks. Any separate merchant software agreement must avoid promising payment acceptance, conversion or AED settlement in the startup's own name.
Operational controls must match those contracts. The startup should have no customer key, recovery authority, signing share or administrator power that permits it to move value. It should not choose conversion counterparties, accept offers independently, redirect settlement or decide financial refunds. Owning the pricing screen is compatible with displaying the provider's quote; independently making the conversion offer engages Article 1(52). A separate software fee does not determine the classification.
A genuine agency arrangement provides another route. Under Article 19, the licensee must submit its assessment and obtain CBUAE approval before an agent performs payment-token services. Customers must receive the agency disclosure, and the principal remains responsible under the regulation. The startup's regulated conduct therefore does not invariably require its own licence, but it must fit an actual approved agency arrangement. The first launch should remain technical unless that additional approval is obtained.
Provider permissions and the own-permission alternative
The selected provider chain must cover custody and transfer, conversion, and any separately regulated AED service. Article 8 permits specified existing businesses to apply for Non-Objection Registration. A virtual-asset exchange operator can apply for conversion; a bank or exchange house can apply for dirham-token conversion. The custody registration route in Article 8(3) concerns foreign tokens for appropriately licensed virtual-asset custodians. It does not automatically authorise dirham-token custody.
Permission must belong to the entity performing the function. Review its current licence or registration, conditions, token scope and operational restrictions. Article 12 allows CBUAE to restrict customers, volumes and activities. A register entry is a useful identity check, but the provider must also establish authority for the proposed arrangement. The bank's acceptance of the settlement route must be documented independently. PTSR, Articles 7(9)–(11), 8 and 12(4)–(7).
The startup should pursue its own permission if it intends to contract as the financial principal or perform a regulated function outside a valid exclusion or approved agency. Token custody, merchant-acquiring-style token services and remunerated conversion must each appear in that application assessment. Independent fiat acquiring, aggregation or payment initiation needs the corresponding payment-services analysis. PTSR, Articles 1(52), 1(54), 2(1), 19; RPSCS, Article 1(60), (66), (68).
An own-permission applicant needs a UAE-incorporated company outside the financial free zones. It must meet the applicable capital, fit-and-proper, control, technology and customer-protection requirements. CBUAE also requires the independent assessments specified in Article 6. Articles 13–15 add category-specific financial requirements; the application is more than a commercial incorporation exercise. Own issuance should be considered only where the business actually undertakes issuance. PTSR, Articles 5–6, 13–15.
Obtaining another licence cannot cure a prohibited token use. Where the business insists on a foreign-token payment for ordinary merchandise, change the payment product. A licensed-issuer dirham token or a conventional fiat checkout is the appropriate redesign branch, each with its applicable permissions. PTSR, Articles 2(4), 2(7).
Contracts, safeguarding and customer support
The merchant agreement should identify the financial principal, accepted token, AED entitlement and settlement deadline. It must allocate quotation expiry, conversion spread, network charges, failed transfers and bank rejection. It should state when the customer has paid the merchant and who bears loss between token receipt and AED credit. The startup's support agreement must not silently transfer those financial obligations to the software supplier.
The payer agreement should identify the token recipient and its legal capacity, applicable fees, consent process and complaint channel. Refund terms should specify who authorises repayment, its currency, the recipient checks and the treatment of exchange differences. PTSR Article 28 requires pre-contractual information on these financial and operational matters. Article 25 preserves applicable CBUAE consumer-protection requirements; contractual loss allocation must respect those protections.
Keep issuer reserves distinct from customer tokens and merchant settlement claims. The issuer's reserve and redemption obligations fall under Articles 21–22. Custodians' customer-token safeguarding falls under Article 23. Neither arrangement, without examining its terms, establishes that the merchant's eventual AED receivable has identical protection. Require daily reconciliation of the actual token and fiat ledgers as a contractual control.
The financial provider should retain customer due diligence, transaction-monitoring decisions, suspicious-activity reporting and financial complaint resolution. The startup can collect information or route support requests under the approved mandate. Contracts should give the provider and regulator access to relevant records, require incident escalation and preserve service continuity on termination. PTSR, Articles 24–25, 28, 35–36; CBUAE's June 2026 AML/CFT/CPF thematic review, sections 6.2.1–6.2.2.
Indian operations, funding and data access
Keep Indian development and support separate from customer-value handling in the first model. RBI's 2025 Directions distinguish a payment gateway that provides technology without handling funds from a payment aggregator that receives and settles payments. The gateway exclusion from those Directions does not establish permission to undertake a separate virtual-digital-asset activity. RBI Payment Aggregator Directions, paragraphs 4(i)–(j), 10(g).
If the Indian business undertakes customer asset exchange, transfer or custody, its FIU-IND position requires separate treatment. FIU-IND's registration circular addresses those activities when performed for others in business and imposes reporting-entity requirements. FIU registration is an anti-money-laundering status, not approval of a UAE payment product. FIU-IND circular F.No. 9-8/2023/COMPL/FIU-IND-Pt-II, 15 September 2025, paragraphs II–III.
Funding a regulated UAE subsidiary raises a different Indian issue. Paragraph 21(7)(d) classifies the foreign business by whether its activity, if conducted in India, would require registration with or be regulated by an Indian financial-sector regulator. A UAE permission alone does not determine that classification. Under paragraph 21(7) of RBI's Overseas Investment Master Direction, a non-financial Indian entity using the specified overseas financial-services investment route must have net profits during the preceding three financial years. The route excludes banking and insurance. The separate IFSC relaxation concerns an IFSC in India. Founder residence, the investor's identity and the target's activity therefore matter before capital is remitted.
The group should use an authorised-dealer bank to classify the proposed investment and document its service-export receipts. Development fees should follow the actual software contract and ordinary business-account route under this design. Customer purchase money should never be described as software revenue. If the founder is resident in India, a founder-funded alternative requires its own resident-individual assessment under paragraph 22 of the Overseas Investment Master Direction. The ordinary resident-individual ODI route excludes investment in a foreign financial-services business. The distinct IFSC-in-India relaxation does not cover direct investment in a Dubai entity. Overseas Investment Master Direction, paragraphs 22 and 24(2).
Indian support access is also a UAE outsourcing issue. PTSR Article 20 applies the Outsourcing Regulation for Banks to licensees. Article 8 requires prior CBUAE non-objection for material outsourcing. Article 6.3 requires CBUAE approval and the specified written customer consent before customers' confidential data is shared outside the UAE. It also requires customers' written acknowledgment that their confidential data may be accessed in foreign legal proceedings. A group company in India is not exempt merely because the same founders control it.
Article 6.1 also requires the master system of record, including confidential data, to remain in the UAE. Article 6.2 permits a foreign bank branch, with CBUAE approval, to retain a UAE copy updated at least daily instead. The data agreement should identify fields, storage locations, remote access, permitted purposes, subcontractors, security and deletion. Articles 6.4–6.6 also require equivalent confidential-data safeguards in every relevant jurisdiction, continued bank and customer ownership, and CBUAE access. They prohibit offshore storage where local law restricts supervisory access. Limit initial support access to the minimum authorised information. For a separate RPSCS service, Article 14 requires personal and payment data to be stored and maintained in the UAE. Offshore access and local retention are distinct questions; satisfying one does not settle the other.
India's DPDP commencement is staged. The principal processing provisions covered by the eighteen-month commencement clause were not yet operative on 14 October 2026. The deferred provisions include the amendment removing Information Technology Act section 43A. The team must therefore assess the law applicable when processing begins rather than treating the DPDP transition as permission for unrestricted access. G.S.R. 843(E), 13 November 2025, clause (c); DPDP Rules, 2025, rule 1. The Indian support company also remains subject to CERT-In's cyber-security directions. It must report specified incidents within six hours of noticing them or being notified of them, designate a contact and retain ICT-system logs for a rolling 180 days. The directions require Indian-jurisdiction retention; CERT-In's FAQ 35 also permits overseas storage where logs can be produced within a reasonable time. The logging design must preserve the UAE data restrictions. CERT-In Directions under Information Technology Act section 70B(6), 28 April 2022, (ii)–(iv); FAQs, May 2022, question 35.
Payer countries and marketing claims
A UAE-resident pilot avoids promising an immediate international payer service. Article 2(6) restricts licensed dirham-token issuance to UAE residents. It does not otherwise impose a territorial restriction on where tokens may be used or transferred under the PTSR. That distinction does not override Article 2's permitted-use rules or another country's payment laws. Non-resident token use should therefore be assessed separately from initial issuance.
An Indian-resident payer route presents a concrete additional condition. For outward transactions under RBI's PA-CB rules, paragraph 11(c) requires instruments issued by authorised Indian payment systems, excluding small PPIs. Paragraphs 11(d)–(e) require the applicable authorised-dealer and FEMA arrangements. A UAE-issued token and UAE provider permission do not themselves satisfy those conditions. This is a reason to exclude that route from the first pilot, rather than assert a universal Indian stablecoin prohibition.
Marketing from India to UAE customers remains within PTSR Article 2(9)–(10). A person promoting payment-token services must hold the relevant permission or be appointed by a Licensee to promote on its behalf. That marketing appointment is distinct from Article 19 agent approval. The permitted promotion must also respect the dirham-token and foreign-token use restrictions.
The checkout should identify the financial provider and describe the approved token, supported payer locations, fees and settlement terms accurately. Claims of acceptance of every stablecoin, worldwide availability or regulatory endorsement are inappropriate for the proposed pilot. Article 25 requires accurate, non-misleading promotions; Article 26 expressly distinguishes CBUAE white-paper review from endorsement.
Implementation order and expansion triggers
First, freeze the product specification. Select a licensed-issuer dirham token, its exact network, UAE-resident payer criteria and ordinary merchant categories. Document the quote, receipt, conversion, AED payment and reverse flows, including ownership at each stage. Remove foreign-token payments, reusable balances and startup-controlled transfer powers from this first design. PTSR, Articles 1(52), 1(54), 2(4)–(7).
Next, match each financial function to a provider's final permission and conditions, then obtain the bank's documented acceptance of the settlement route. Complete any Indian investment assessment before committing capital. Execute the financial customer contracts and technical-services mandate; obtain required outsourcing, offshore-data, marketing or agent approvals before the corresponding activity begins. PTSR, Articles 7–8, 19–20; Outsourcing Regulation, Articles 6, 8.
Run non-value tests before a bounded live pilot. Test incorrect networks, duplicate callbacks, quotation expiry, failed conversion, delayed AED settlement and refunds. The provider should approve the operational results and retain the financial decisions. Technical testing cannot substitute for the permissions required by Article 2(1); business continuity and security duties continue under Articles 35–36.
Expand only through recorded change approval. A new payer country requires its own payment and marketing review. New token distribution, signing authority, conversion offers, financial merchant contracts or pooled fiat balances require a fresh activity classification. Where the startup becomes the financial principal, obtain its applicable permission before deployment. Where the token use itself falls outside Article 2, redesign the product before accepting that payment.