A UAE storefront usually ends up offering four ways to pay: cards, two buy-now-pay-later providers, and cash on delivery. Choosing a payment gateway UAE merchants can sign with covers the first of those and part of the second. The rest is your order model, and that is the part nobody scopes.
They look like four buttons at checkout, and a payment gateway UAE demo will show them that way. They are four different state machines. The thing that breaks is not the integration, because each provider ships a plugin and the buttons work by the end of the week. What breaks is everything that reads order state afterwards: the fulfilment queue, the refund flow, the revenue report, and, from 2027, the invoice going to the Federal Tax Authority.
The four rails, and what each one does to an order
Cards follow the model most systems are already built for. Authorise at checkout, capture at fulfilment, settle a few days later, and carry chargeback exposure for months afterwards. 3-D Secure adds a step where the customer leaves and may not come back, so the order exists before the payment resolves. This is the rail any payment gateway UAE side will hand you working out of the box.
Tabby has five payment states: CREATED, AUTHORIZED, CLOSED, REJECTED and EXPIRED. A payment is created with the checkout session, moves to authorised when the customer completes checkout, and the documentation instructs merchants to send a capture request as soon as the payment is authorised. A partial capture leaves the payment in AUTHORIZED until you capture the full amount or send a close request. The line that matters for accounting: the payout for a payment is processed only after it is closed.
Tamara has eleven order statuses: new, declined, expired, approved, authorised, partially_captured, fully_captured, partially_refunded, fully_refunded, canceled, and updated, which means partially cancelled. Capture is explicitly tied to fulfilment, so an order becomes fully_captured when it has shipped and partially_captured when part of it has. Tamara also runs three clocks: the customer has 30 minutes to complete payment, the order has 72 hours to be authorised, and an authorised order has 90 days to be captured or cancelled. On top of that, an order not captured within 21 days of authorisation is auto-captured and moved to fully_captured.
Cash on delivery has no provider state at all. The money arrives with the courier, days after the order, and reaches you through a reconciliation file rather than a payment API. No payment gateway UAE providers offer will model this for you.
| Cards | Tabby | Tamara | COD | |
|---|---|---|---|---|
| Money committed at | Authorisation | Authorisation | Authorisation | Delivery |
| Capture tied to | Fulfilment | Authorisation | Fulfilment | Not applicable |
| Partial capture | Usually supported | Payment stays authorised | partially_captured | Not applicable |
| Merchant is paid | On settlement | After the payment is closed | On payout schedule | On courier remittance |
| Refunds run through | Acquirer | Tabby | Tamara | Bank transfer you initiate |
| Can fail after the order | Chargeback | Expiry of the checkout | Expiry on three clocks | Customer refuses at the door |
Read down the capture tied to row. Tabby wants capture at authorisation. Tamara wants it at shipment. Same checkout, opposite instruction. An order model with one paid boolean cannot hold both.
Cash on delivery is a fulfilment problem
COD is still a real payment method in the UAE, it sits outside every payment gateway UAE merchants integrate, and it is the one that does the most damage to a data model built around card assumptions.
The order is placed on Monday. It ships Tuesday, is delivered Thursday, and the courier remits in a batch the following week, net of their fee. Between Monday and Thursday the order is real, the inventory is committed, and no money exists.
- Delivery is the payment event. Your system needs a state for delivered-and-collected that is distinct from delivered, because the courier can deliver and fail to collect.
- Refusal at the door is not a refund. Nothing was paid, so there is nothing to refund. The order needs a cancellation path that releases inventory and never creates a credit note.
- Reconciliation is file-based. Matching a courier remittance batch against orders is a report someone has to build, and it will not match on the first run.
- Partial delivery exists. A multi-item COD order can be partly accepted at the door.
BNPL splits the order from the money
With Tabby and Tamara the customer pays in instalments and you are paid on a schedule of the provider making, whether or not they were resold to you through a payment gateway UAE contract. Tabby documentation is explicit that the payout follows closure of the payment, and Tamara ties capture to shipment. Three things follow.
The invoice belongs to the order, not the payout. Teams who build invoicing off payout reports produce invoices that do not correspond to any single order. Once e-invoicing is live, those go to the tax authority.
Refunds go back through the provider. Tabby handles refunds once the merchant accepts the return, including partial refunds. Your system job is to tell the provider what was returned, then reflect a state it does not control. Modelling a refund as a local status change leaves you out of sync with the provider record.
Expiry is a real state you have to handle. Tamara three clocks, 30 minutes, 72 hours and 90 days, mean an authorised order can go stale while sitting in a fulfilment queue waiting on stock. The 21-day auto-capture is the sharper edge: an order you have not shipped can be captured for you, which is a refund conversation rather than a cancellation. Nothing in your system notices unless something is watching.
Payment gateway UAE coverage: What it handles and what it leaves to you
A payment gateway UAE merchants sign with takes care of the card rail: acquiring, 3-D Secure, settlement files, and usually a hosted page or drop-in component. Several also resell Tabby and Tamara as additional methods behind the same integration, which is why a single contract can look like it covers the whole checkout.
It does not cover the four things this article is about. The gateway does not decide when you capture, does not model partial fulfilment for you, does not reconcile courier cash, and does not carry the dates your invoices will need. Those live in your order model, and they are the same whichever payment gateway UAE side you sign with.
Reconciliation: The report finance asks for in month two
Every UAE commerce project reaches the same meeting, and no payment gateway UAE dashboard resolves it. Finance has four sources of money, the acquirer settlement file, two provider payout reports, and the courier remittance batch, and one question: which orders does this deposit represent.
Answering it requires three things that are cheap to design in and expensive to retrofit.
- A provider reference stored on the order, for every rail, with its own field rather than a shared note
- An event log with timestamps for authorisation, capture, payout and refund, rather than a single mutable status
- A currency record that stores the AED amount and the rate at order time, so the same order does not reconcile differently depending on when the report runs
The event log is the one teams skip. A single status column tells you where an order is now. Reconciliation is a question about the past, and no payment gateway UAE providers sell will answer it for you.
Where this meets the e-invoicing mandate
From 1 January 2027, UAE businesses with annual revenue of AED 50 million or more must issue B2B invoices as structured data through an accredited service provider. Everyone below that threshold follows on 1 July 2027. We covered the detail in UAE e-invoicing.
Payment method is where that mandate collides with checkout design, because the invoice date depends on when the supply happened, and each rail puts that moment somewhere different. A card order authorised Monday and captured Wednesday, a Tamara order captured at shipment, and a COD order collected on Thursday are three different dates for three orders placed in the same hour.
If your system carries one date per order, someone will pick one, and every invoice on the other two rails will be wrong. That is a data model problem, not a payment gateway UAE selection problem.
Payment gateway UAE checklist: Three decisions worth making before anyone writes code
| Decision | If you get it right | If you defer it |
|---|---|---|
| One order state machine covering all four rails, or one per rail | Fulfilment, refunds and reporting read one model | Each new rail adds branches to code that was not built to branch |
| Capture triggered by fulfilment or by authorisation, per rail | Each provider gets what its API expects | One rail silently holds authorisations until they expire or auto-capture |
| Event log from day one, or a status column | Reconciliation is a query | Reconciliation is a project |
There is no rail here that is simply better. The question we ask first is which of these your fulfilment process can actually support, because a capture rule that depends on accurate shipment events is a warehouse decision before it is a code decision. Answer these three and the payment gateway UAE question becomes a procurement detail rather than an architecture risk.
How KVY approaches it
We build commerce systems for teams whose software decisions carry real consequences. Payment methods, currency handling and tax identity are architecture decisions we settle in the first weeks, not plugins added later. Bolting them on is how commerce builds fall apart in month six. That is the core of our custom ecommerce development work, and of the B2C ecommerce development side of it.
On a UAE build that means the order model is designed against the provider state machines as documented, not against a generic paid flag, and the reconciliation report is specified before the first integration rather than discovered after the first month-end. The payment gateway UAE contract is the last decision we make, not the first.
Frequently asked questions
Which payment methods does a UAE storefront need?
Most end up with cards, at least one buy-now-pay-later provider such as Tabby or Tamara, and cash on delivery. The mix depends on the category and the customer, and each one adds states to your order model rather than just a button.
How are Tabby and Tamara different for developers?
Their lifecycles differ. Tabby uses five payment statuses and its documentation instructs merchants to capture as soon as a payment is authorised, with payout following closure. Tamara uses eleven order statuses, ties capture to shipment, and runs three clocks of 30 minutes, 72 hours and 90 days, plus auto-capture at 21 days after authorisation.
How do refunds work with BNPL in the UAE?
Through the provider. Tabby handles refunds once the merchant accepts the return, including partial refunds. Your system records the return and reflects a state the provider owns, rather than changing a local status by itself.
Does cash on delivery need special handling?
Yes. Payment happens at delivery, so the system needs a collected state separate from delivered, a cancellation path for refusal at the door that creates no credit note, and reconciliation against courier remittance batches.
What does a payment gateway UAE contract not cover?
It covers the card rail and often resells BNPL, but it does not decide when you capture, model partial fulfilment, reconcile courier cash, or carry the dates your invoices need. Those stay in your order model whichever gateway you choose.
Tell us which rails you need. We will map the order states before anyone writes code.