Aani Instant Payments for UAE Marketplace Operators

What Aani supports today#

Aani is the UAE’s national instant-payment platform operated by Al Etihad Payments, a CBUAE subsidiary. AEP customer guidance describes 24/7 domestic transfers in AED between accounts at licensed institutions and payment providers in the UAE. It also explains that the participating provider determines customer fees.

In its 10 April 2026 update, AEP lists QR payments, Request to Pay, proxy transfers and multiple-account management as current features. It reports an average account-to-account completion time of no more than three seconds. That figure describes platform performance; an integration still needs its own status and exception handling.

The same update lists cross-border payments, electronic direct debit, e-cheques and additional B2B services as future developments. Do not sell those future services as available in your product. AEP’s published product page shows an AED 50,000 transaction limit; confirm the applicable amount, channel and account limits with your provider before designing order or payout limits.

Choose an access route for the marketplace model#

Start with a participating bank or payment provider that can explain the full dirham flow. Ask for the legal entity providing each service, the account holder receiving the buyer payment, and the contractual basis for the platform’s role. An Aani consumer-app enrollment is not proof of an API or marketplace onboarding path.

Resolve the regulatory role before moving customer funds#

The CBUAE Retail Payment Services and Card Schemes Regulation addresses categories including merchant acquiring, payment aggregation and domestic transfers. Its description of aggregation includes receiving, pooling and later transferring customer payments to merchants. If that is your business activity, assess the relevant licensing and partner structure rather than assuming a software label removes the obligation.

Licensing provisions include specific treatment for banks. They do not create a general marketplace exemption. Document whether the platform acts as a merchant, an agent under an approved arrangement, or a provider performing a regulated activity. Keep customer protection, safeguarding, AML and complaint responsibilities attached to the entity and service actually in scope.

Separate the buyer payment from the seller payable#

Illustrative commercial example: a buyer pays AED 1,000 for a completed service. The marketplace agreement assigns an AED 100 platform fee and AED 900 seller entitlement, before any taxes or provider fees. A confirmed AED 1,000 collection records the receipt and the seller liability. It does not prove that AED 900 has reached the seller.

This example illustrates separate records, not a promise that Aani supports automatic splitting. Your provider may settle to one merchant account and require a different supported disbursement process. Confirm whether fees are charged separately, netted from settlement or deducted from the recipient; the journal and customer amount must reflect the actual terms.

Define the integration contract and recoverable work#

Retain the request fields, amount in AED, order reference, beneficiary version, stable operation key and provider reference. Save the intended operation before submission. A signed or authenticated callback should update a durable pending record; receipt and completion need separate states so a worker can resume after a crash.

Enforce uniqueness for the business effect as well as the webhook event. Two distinct notifications can describe the same collection, and a saved callback can still have unfinished follow-up work. Update the local payment state, any actual journal effect and follow-up outbox work transactionally, then mark processing complete.

If a response times out or arrives out of order, retrieve the existing provider operation and reconcile its current state. Do not start a fallback transfer while the original can still succeed. A partner-specific confirmed failure or completed cancellation can justify a replacement, linked to the original unpaid obligation.

Reconcile receipts, fees and disbursements separately#

Match the provider’s collection and settlement reports to order receipts. Then match seller disbursements to seller liabilities. Preserve fee lines and refund adjustments so a fast buyer payment does not hide an unpaid seller or a missing reconciliation item.

Use the partner’s actual reporting and contractual settlement model. Aani’s instant account-to-account description does not determine whether an acquirer or aggregator pays out its merchant balance immediately. Show users the status your evidence supports, rather than translating every accepted request into “paid.”

Test the cases that create real exceptions#

• Duplicate callback: one receipt and one financial effect.
• Worker crash after saving a callback: pending work resumes.
• Successful collection and failed seller payout: seller liability remains open.
• Unknown outbound transfer: provider lookup occurs before fallback.
• Wrong recipient or disputed service: the defined complaint and refund process has a named owner.

Approve launch when the participating partner has confirmed the intended flow, pricing and support responsibilities, and these cases reconcile using actual integration records. That gives product, operations and finance a usable release decision without treating established rail features as unknown or promising capabilities outside the partner contract.