Designing an end-to-end crypto-to-AED payment platform for UAE merchants

The main product decision was to organise Arvio around familiar merchant actions rather than crypto infrastructure.

A manager creates an invoice through POS or web. The customer receives a payment request and pays in crypto. Arvio handles the payment processing and conversion, while the merchant works with the transaction through its AED amount, status, balance, and settlement state.

The merchant did not need to manage wallets, networks, exchange mechanics, or crypto balances as part of daily operations.

Crypto remained a payment method for the customer rather than a new operating model for the business.

• AED amount
• Transaction status
• Merchant balance
• Settlement state

The core transaction was structured around three moments.

Create: the merchant generates an invoice through POS or web.

Pay: the customer receives the payment request and completes the crypto payment.

Settle: the transaction is confirmed, converted, and enters the merchant’s AED settlement flow.

The customer-facing and merchant-facing interfaces showed different information, but both represented the same underlying transaction state.

The customer needed a clear payment action and confirmation. The merchant needed to know how much was paid, whether the transaction had completed, what value would be received in AED, and where the payment could be found afterwards.

Settlement was treated as a merchant-facing part of the service rather than hidden back-office logic.

I structured three models around different business needs.

Making these models explicit helped businesses understand not only how customers would pay, but how money would move through the service after each transaction.

Arvio was designed as a complete operational system rather than a standalone checkout.

All product surfaces shared the same payment and settlement logic, while exposing different information depending on who was using them.

• POS payment interface — invoice creation, QR payment, progress, confirmation, receipts, and the next transaction;
• web payment interface — the same transaction logic in browser-based payments;
• merchant dashboard — balances, transactions, settlements, terminals, reporting, and controls;
• admin system — internal management of merchants, transactions, settlements, and platform operations;
• onboarding — merchant application, agreement, activation, and terminal setup;
• acquisition and sales — bilingual website, presentations, brochure, and product communication.

For Arvio, trust depended largely on making the movement of money understandable.

The interfaces consistently surfaced the information needed to answer basic operational questions.

• what the customer was paying;
• whether the payment was confirmed;
• what the merchant would receive in AED;
• which settlement model applied;
• where the transaction could be found later;
• what receipt or transaction record was associated with it.

The goal was to absorb infrastructure complexity rather than asking merchants to understand it.

No licensing claim is made in this case because the final licensing status and exact licensed entity have not been independently confirmed.

The external communication followed the same product logic.

The website positioned Arvio around merchant outcomes rather than crypto technology and translated the service into use cases across hospitality, retail, everyday services, logistics, and car rental.

The onboarding path was presented as a short operational sequence.

The same proposition and terminology were then carried into presentations and the printed brochure.

The completed scope covered the full product: POS and web payment interfaces, merchant dashboard, internal admin system, onboarding, settlement mechanics, identity, bilingual acquisition website, presentations, and brochure.

The product was fully developed, but the client decided not to bring it to market.

• POS and web payments
• merchant dashboard
• internal admin
• onboarding and settlement
• identity and bilingual website
• presentations and brochure

Because it never entered live operation, there are no verified merchant adoption, transaction-volume, conversion, retention, or revenue metrics.

The case demonstrates end-to-end product definition and execution across customer-facing, merchant-facing, and internal operational surfaces rather than commercial validation.

The complete payment operation was built.Commercial validation never happened.