# Recurring billing in the UAE: subscriptions without chasing invoices
Recurring billing in the UAE means a customer's card is charged automatically on a schedule you set, so you stop sending the same invoice every month and stop waiting on transfers. The mechanics are settled: the card gets tokenized on the first payment, the token is stored with the gateway, and every cycle after that the charge fires on its own. The part almost nobody writes about is the operator layer around it. What happens when a card declines on the third of the month, when to send the invoice, how the recurring charge links back to the deal in your CRM, and how the customer gets a WhatsApp reminder the day before the money moves. That operator layer is where subscriptions either run quietly or turn into a second job.
I run this on our own business. Our AI agent sells studio rental over WhatsApp, and where a client is on a repeating arrangement, the charge and the reminder are handled without anyone touching a spreadsheet. This piece is written from that seat.
Recurring billing in the UAE tokenizes the customer's card on first payment, stores the token with a gateway that supports 3D Secure 2 (mandatory here), then charges automatically each cycle. Gateways that support it include Stripe, Checkout.com, Telr, PayTabs, Tap, Network International, and Mamo. The operator work that decides whether it runs smoothly is retry logic on declines, dunning across email/SMS/WhatsApp, and a link between the recurring charge and the deal record in your CRM.
What recurring billing actually is, and why it matters here
Recurring billing charges a saved card on a fixed schedule without the customer re-entering details each time. Weekly, monthly, quarterly, annually, or on custom intervals. The customer consents once, and the money moves on its own after that.
Two things make it worth setting up in the UAE specifically. The first is churn. When a customer has to manually pay every cycle, some fraction of them lapse for reasons that have nothing to do with wanting to leave. They missed the invoice, the transfer slipped, the reminder landed while they were traveling. Automatic charging removes that friction, and a chunk of what looks like churn was really just admin failure. The second is your own time. Chasing invoices is a recurring cost that scales with your customer count. At ten subscribers it's an afternoon a month. At a hundred it's a person's job, and that person makes judgment calls you never see, deciding who's worth a second follow-up and who "looked slow to pay anyway."
A subscription that bills itself doesn't skip a follow-up because it's Friday afternoon. The charge at 3am on a Saturday and the charge at 9am on a Monday are identical.
How it works technically
The first payment does the important work. When the customer pays the first time, the gateway captures the card and returns a token, a reference that stands in for the card number so you never store the real digits. That token sits with the gateway, tied to a mandate the customer agreed to. Every cycle after that, your system tells the gateway "charge token X for amount Y," and the gateway runs it against the network.
In the UAE, 3D Secure 2 is mandatory. The first transaction, the one that sets up the subscription, goes through a 3DS2 authentication step where the customer confirms with their bank. That authentication is what makes the later automatic charges possible without re-prompting every time, because the mandate is established up front. Some cycles may still trigger a fresh authentication depending on the bank's risk rules and the amount, and a good setup handles it without breaking the flow instead of silently failing.
The recurring flow is: first payment with 3DS2 authentication, card tokenized, token stored against a mandate, scheduled charges fire against the token each cycle. You never store raw card numbers; the gateway holds the token, and you hold the reference plus the schedule.
The scheduling itself lives either in the gateway (if it has a real subscription engine) or in your own system talking to the gateway's charge API. That distinction matters when you pick a provider.
UAE gateways that support recurring, and how they differ
Most gateways serving the UAE support recurring in some form, but the depth varies a lot. Here is the honest map. Treat any rate mentioned as a directional reference, not a quote. Confirm exact pricing and capabilities with the provider, because they change and they depend on your business type.
| Gateway | Recurring approach | Best fit | |---|---|---| | Stripe | Full subscription engine with built-in dunning, trials, proration | Businesses wanting the deepest subscription logic out of the box | | Checkout.com | Recurring supported, often at a more enterprise/custom tier (DIFC-based) | Larger volume, custom flows, MENA-wide scale | | Telr | Token-based recurring, subscription managed more manually | UAE SMEs already using Telr for checkout | | PayTabs | Recurring billing supported for subscription businesses | Regional merchants wanting local support | | Tap | Token-based recurring across GCC | Businesses billing across Gulf markets | | Network International | Established acquirer with recurring capability | Merchants who want a large local acquirer relationship | | Mamo | Built-in subscription products aimed at SMEs | Small businesses wanting simple setup fast |
The short version: Stripe carries the most complete subscription engine, so retry logic, trials, and proration come mostly built in. The local and regional gateways (Telr, PayTabs, Tap, Network International) reliably support token-based recurring, but you often build more of the subscription management and dunning yourself or through a layer on top. Mamo sits at the simple-SME end with subscription products ready to go. None of this is a reason to avoid a local gateway. It's a reason to know, before you commit, how much of the operator layer the gateway gives you versus how much you have to wire yourself.
If you want the broader gateway comparison beyond recurring, we keep that decision in one place rather than repeating it, and the choice usually comes down to your volume, your bank relationship, and how much subscription logic you need.
Retry and dunning: what to do when a card declines
This is the part that separates a subscription that quietly recovers revenue from one that leaks it. Cards decline for ordinary reasons: insufficient funds on the salary-cycle gap, an expired card, a temporary bank block, a limit hit. A large share of failed recurring charges are recoverable if you retry with a bit of patience instead of giving up or hammering the card.
A sensible retry pattern for the UAE looks like this. On the first decline, don't panic and don't retry instantly. Wait, then retry once after a short delay, then again a couple of days later, then a final attempt near the end of the week. Three to four attempts spread over roughly a week catches most of the recoverable declines, especially the "waiting on salary" ones that clear once the account is funded. Beyond four attempts you're mostly annoying the customer and risking the bank flagging your merchant account for repeated failed charges.
Dunning is the communication around those retries, and it should escalate across channels. Start soft. An email when the first charge fails, telling the customer plainly that the card didn't go through and the next attempt is coming. If the retries keep failing, move to SMS. If it's still unresolved, escalate to WhatsApp, which in the UAE is where people actually read messages. The tone matters: this is a "your card needs a look" message, not a debt-collection message. Most failures are innocent, and treating a good customer like a delinquent over an expired card is how you lose them for real.
A workable UAE dunning ladder: retry 3-4 times over about a week (short delay, then spaced days), with communication escalating email, then SMS, then WhatsApp. Stop after roughly four attempts to avoid bank flags. Most recoverable declines are salary-cycle timing or expired cards.
Linking recurring charges to your CRM and WhatsApp
A recurring charge that fires in a gateway dashboard and never touches your CRM is half a system. The subscriber's payment status lives in one place, their deal and conversation history live in another, and someone has to reconcile the two by hand. That manual relay between the gateway and the CRM is exactly the operator gap I keep seeing.
The version that works looks like this. The deal in the CRM carries the subscription: which plan, what cycle, next charge date, payment status. When a cycle succeeds, the CRM record updates itself and the next invoice reference is already staged. When a cycle fails, the deal flips to a failed-payment state and the dunning sequence kicks off automatically from there, not from someone noticing days later. The gateway's webhook is what carries the truth: it tells your system "charge cleared" or "charge failed" in under a second, and the CRM reacts to that instead of a person watching a dashboard.
The WhatsApp layer is the piece customers actually feel. A message the day before the charge, "Your subscription renews tomorrow for AED X, card ending 42, reply here if anything's changed," does two things. It cuts disputes and chargebacks, because nobody is surprised by a charge they forgot about. And it gives the customer a clean moment to update a card that's about to expire, before the decline happens rather than after. Our WhatsApp agent handles that reminder and the reply in the same thread the customer already knows, so a card update is a two-message conversation instead of a support ticket.
Consent, mandates, and security in plain terms
Recurring billing rests on consent. When the customer sets up the subscription, they agree to a mandate: this amount, this frequency, until cancelled. That agreement has to be explicit and recorded, and the customer needs a clear way to cancel. This isn't just good manners; a clear mandate is your defense if a charge is ever disputed.
On security, the load is mostly carried for you if you use a proper gateway. You don't store card numbers, the gateway does, behind PCI DSS compliance. You store the token and the reference. The 3DS2 authentication on the first charge shifts liability for fraud and satisfies the UAE requirement in one step. The practical rule: keep raw card data out of your systems entirely, lean on the gateway's compliance, and make sure your mandate and cancellation flows are honest. That combination keeps you clean on both the security and the trust side.
How this fits together, and what to check first
The technology for recurring billing in the UAE is not the hard part. Every serious gateway does it. What decides whether your subscriptions run themselves or eat your week is the operator layer: retry logic that recovers declines without annoying good customers, dunning that escalates across the channels people actually read, and a live link between the gateway, the CRM, and the WhatsApp thread so a payment status is never something a human has to go check.
We built this for ourselves before selling it. If you want to see where your current setup leaks (declines that never got retried, subscribers who lapsed over admin rather than intent, reminders that never went out), a Growth Audit maps it against your gateway and CRM. If the missing piece is the WhatsApp layer, the reminder before the charge and the card-update reply in the same thread, that's what The Lead, our WhatsApp AI agent, does. You can see how we run it on our own studio bookings in the SkyLight case, and the open pricing is published rather than gated.
