Tabby & Tamara BNPL Integration Guide UAE (2026)

# Tabby and Tamara BNPL Integration Guide: A Technical Playbook for UAE Merchants

TL;DR: Tabby and Tamara are the two "buy now, pay later" providers most UAE shoppers will recognise, and both now hold Central Bank of the UAE (CBUAE) licences of different kinds — integration is a standard REST-API-plus-webhook flow (checkout session → redirect → webhook confirmation → capture), but the parts merchants actually get wrong are regulatory scope, VAT on the goods versus the platform fee, and webhook authentication, not the happy-path checkout.

BNPL is no longer a nice-to-have widget on a UAE checkout page — it is close to becoming table stakes. The UAE BNPL market was expected to reach US$2.84 billion in 2025 (15.6% growth on 2024) and is forecast to grow at roughly 11.2% CAGR through 2030, reaching close to US$4.82 billion by then, according to a ResearchAndMarkets report cited by Business Wire (source).

Two providers dominate checkout pages in Dubai, Abu Dhabi, and Sharjah: Tabby, which was founded in the UAE in 2019 and whose developer docs list the UAE and Saudi Arabia as its markets, and Tamara, a Saudi-founded provider whose developer docs list Saudi Arabia, the UAE and Bahrain. Both ship ready-made plugins for the common e-commerce platforms (Shopify, WooCommerce, Magento, Salla, Zid and others), so they appear on large retail sites and small stores alike.

This guide walks through what actually changes when you add Tabby and/or Tamara to a UAE storefront — the regulatory context, the tax and data-protection angles, and the concrete API steps — rather than repeating generic "BNPL is popular" marketing copy.

Why UAE Retail Leans So Heavily on BNPL

A few forces are compounding here:

BNPL is sold to merchants as a checkout-conversion lever. Providers pitch higher average order values and lower cart abandonment when a "split into 4" option sits next to the card fields. We have not seen independent UAE data that quantifies this, so A/B-test it on your own checkout rather than taking the uplift on trust.
B2B BNPL is growing even faster than consumer BNPL in the UAE. Against the 15.6% consumer figure above, a 2026 market report projected UAE B2B BNPL payments growing 37.7% year-on-year to reach roughly US$1.50 billion in 2025, as SME credit platforms and regulated fintechs move into trade financing (source).
The regulator has stepped in, which — counterintuitively — has made BNPL more attractive to serious merchants, because it reduces the reputational and compliance risk of partnering with an unlicensed or thinly capitalized provider.

The Regulatory Backdrop: CBUAE's Finance Companies Regulation

Before writing a single line of integration code, it's worth understanding what changed in UAE law, because it affects how you should evaluate any BNPL partner — not just Tabby and Tamara.

On 27 December 2023, the Central Bank of the UAE (CBUAE) brought a revised Finance Companies Regulation into effect, which brings short-term lending products, including BNPL, under regulation as "short-term credit" (White & Case summary, Hadef & Partners analysis). Key provisions merchants and their engineering teams should know about:

Requirement	Detail
Licensing	Finance businesses and licensed financial institutions may offer short-term credit in mainland UAE directly or through approved agents; a new Restricted License category was created for short-term lending companies
Credit cap	Restricted License finance companies may only extend loans that do not exceed AED 20,000 or three months' verifiable net income of the borrower
Repayment term	Maximum 12 months
Fee cap	Total fees (including any late-payment fees) are capped at 30% of the original loan amount
Capital requirement	Minimum capital of AED 20 million or aggregate capital funds equal to 5% of outstanding lending volume
Grace period	Providers already operating had 90 days from the effective date to apply to the CBUAE for a licence or cease financing activities

For a merchant, the practical takeaway is simple: you are not the credit provider — the BNPL company is. The two providers' UAE licences are not the same, though: Tamara announced a CBUAE restricted finance licence on 20 October 2025 (Tamara), while Tabby's CBUAE licence, granted in April 2026, is a Stored Value Facilities (wallet) licence (The Paypers). Ask each provider which authorisation covers the BNPL product you are offering and write that into your merchant agreement, and make sure your checkout copy doesn't misrepresent the credit terms.

VAT and Data Protection: What Actually Applies

VAT. The UAE's standard VAT rate remains 5%, unchanged since VAT was introduced in 2018, and it continues to apply under Federal Decree-Law No. 8 of 2017 (as amended, most recently by Federal Decree-Law No. 16 of 2025, effective 1 January 2026) (source). For a BNPL checkout, the important nuance is that VAT applies to the price of the goods or services sold — not to the fact that the customer chose to pay via Tabby or Tamara instead of a card. The merchant discount fee you pay to your BNPL provider is a separate commercial line item under your merchant agreement; treat it like any other payment-processing cost for tax purposes and confirm the exact VAT treatment of that specific fee with your accountant, since financial-service fee treatment can have its own rules distinct from standard retail VAT.

Data protection. The UAE's core data protection statute is Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (PDPL), in force since 2 January 2022 (Securiti overview). One detail matters specifically for payments teams: Article 2 of the PDPL excludes banking and credit personal data that has its own legislation regulating its protection and processing from the law's scope. In practice this doesn't mean "anything goes" — it means the compliance obligations for the payment/BNPL data flowing through your checkout sit primarily with the CBUAE-regulated provider and your PCI-DSS scope as a merchant, rather than being a pure PDPL question. Don't store BNPL customer eligibility responses, phone-verification codes, or installment schedules in your own database longer than your order-fulfillment workflow needs — pass-through, not retention, is the safer default.

Tabby vs. Tamara: Practical Differences for Integrators

Both providers offer near-identical merchant value propositions (split into 4, pay-in-30-days, no interest to the consumer) and both publish separate API hosts you must get right: per region for Tabby, per environment for Tamara.

Tabby — founded in the UAE, live in the UAE and Saudi Arabia. API docs live at docs.tabby.ai, with distinct base URLs per market — api.tabby.ai for the UAE and api.tabby.sa for Saudi Arabia — so don't hardcode a region.
Tamara — founded in Saudi Arabia; its docs list Saudi Arabia, the UAE and Bahrain as markets. UAE customers go through an ID-verification (UAE KYC) step, so mobile apps opening Tamara in a WebView must grant camera permission (Tamara docs). API docs live at docs.tamara.co, with separate sandbox (api-sandbox.tamara.co) and production (api.tamara.co) hosts.

Many UAE merchants running Shopify, Magento, WooCommerce, or a custom Next.js/Node storefront offer both side by side, so that a customer declined or unfamiliar with one provider can use the other.

Real Integration Steps: Tabby

1. Get merchant credentials. Get your test keys and merchant_code from the Tabby Merchant Dashboard (or your account manager): a public key and a secret key, each in test (sk_test_...) or live form. Tabby infers the environment from which key you send — there's no separate sandbox subdomain to manage, which trips up teams used to Stripe-style separate test endpoints.

2. Run a background eligibility check before showing Tabby. Send the cart total and customer contact details to Tabby's checkout API (POST /api/v2/checkout); a created status means eligible, rejected means not. When the customer actually places the order, call the same endpoint again with the full order payload (items, shipping, buyer). The response tells you whether this customer/cart combination qualifies — reject the option in your UI gracefully if it doesn't, rather than showing a broken button.

3. Redirect the customer to the Tabby-hosted payment page. The session response includes a hosted payment page link (web_url); save the returned payment.id, then redirect the browser there rather than trying to collect BNPL-specific eligibility data yourself.

4. Handle the redirect back to your `success`/`cancel`/`failure` URLs. These are set per session in the checkout request's merchant_urls, and Tabby appends payment_id to them. Verify the status server-side with the Retrieve Payment call rather than trusting the URL.

5. Verify via webhook, not just the redirect. Register your webhook URL yourself with POST /api/v1/webhooks (secret key plus an X-Merchant-Code header), optionally with a custom auth header (for example X-Auth-Key) that Tabby will echo back so you can check it. On payment authorization, Tabby POSTs a payment status update — treat the redirect as a UX signal only, and treat the webhook as the source of truth for actually marking an order paid, exactly as you would for any card gateway.

6. Capture explicitly. Tabby separates authorization from capture: only captured payments are settled to you. Once the payment is AUTHORIZED and the order is accepted in your order system, send a capture for the full payment amount, with a reference_id derived from your order ID so retries don't double-capture. Tabby leaves uncaptured payments alone for 21 days, after which it may capture them itself.

7. Use the same region-scoped base URL for capture and refund calls that you used for checkout creation — mixing UAE and KSA endpoints across the lifecycle of a single order breaks the calls that follow.

Full endpoint-level reference, an OpenAPI spec, and a Postman collection are published at docs.tabby.ai.

Real Integration Steps: Tamara

1. Collect credentials. A Tamara merchant account comes with an API Token, a separate Notification Token, and a Public Key (used only for the promotional widgets). All three get used for different purposes — don't conflate them.

2. Authenticate as a bearer token. Every API call carries Authorization: Bearer {api_token} in the header. Use api-sandbox.tamara.co while integrating and api.tamara.co once you cut over to production — these are genuinely separate hosts, unlike Tabby's single-domain-plus-key-mode approach.

3. Create a checkout session (`POST /checkout`), passing order total, tax amount, shipping amount, items, and consumer/shipping details, plus your merchant_url object (success, failure and cancel redirect URLs). Store the returned order_id. The webhook URL is registered separately, once, in the Tamara Partners Portal (Settings → General Settings → Webhooks).

4. Redirect to the `checkout_url` returned in the checkout-session response — this is Tamara's hosted, PCI-scoped flow, so you never touch card or eligibility data directly.

5. Verify webhook authenticity before trusting it. Tamara attaches a JWT to each webhook call as a tamaraToken query parameter and again as a bearer token in the Authorization header (HS256, verifiable with your Notification Token). Validate it server-side before updating order status — skipping it is a real security gap since it means anyone who guesses your webhook URL could otherwise spoof a "paid" event.

6. Authorise, then capture. When the order_approved webhook arrives, call the Authorise Order endpoint (unless Tamara has enabled auto-authorisation for your account); an authorised order can be treated as paid. Then call Capture Order when you ship or fulfil. Tamara auto-captures orders left uncaptured 21 days after authorisation, and an approved order not authorised within 72 hours expires.

7. Handle partial captures and refunds explicitly if you support partial shipments; Tamara's API supports capturing less than the full authorized amount, which matters for split-fulfillment UAE warehouses.

Full reference documentation, including the JWT verification detail, is at docs.tamara.co.

Common Pitfalls Worth Flagging to Your Dev Team

Trusting the browser redirect instead of the webhook. Customers close tabs, lose connectivity, or bounce back from a BNPL provider's page before the redirect completes. Only the webhook is authoritative.
Skipping webhook authentication "for now." Both providers document how to verify webhook authenticity (Tabby via the auth header you register, Tamara via the tamaraToken JWT); treating this as optional in a rushed launch is how fraudulent "paid" callbacks slip through.
Hardcoding a single regional base URL across both providers when your storefront later expands beyond the UAE — Tabby's separate KSA endpoint and Tamara's other GCC markets mean a config-driven base URL from day one saves a rewrite later.
Forgetting the eligibility check. Both Tabby and Tamara have order-value minimums/maximums and country/customer eligibility rules; surfacing the BNPL option to every customer regardless of eligibility just produces support tickets.
Conflating the BNPL merchant fee with VAT. They're separate line items with separate tax treatment, as noted above — don't let a junior dev bake the merchant discount rate into a "VAT" field in your accounting export.

For teams that don't have in-house payments engineering bandwidth, this is exactly the kind of well-documented-but-detail-heavy integration where an experienced partner earns its keep — Wise Hustlers' API integrations service covers this class of work, from webhook security to reconciling BNPL settlement data against your order and accounting systems.

FAQ

Do I need a CBUAE license to accept Tabby or Tamara on my UAE store?

No. The BNPL provider extends the credit; as a merchant you're integrating their API and hosted checkout, not lending yourself. Because Tabby and Tamara hold different kinds of CBUAE licence, confirming which authorisation covers the product you offer is still part of vendor due diligence.

Is VAT charged differently when a customer pays with BNPL instead of a card?

No — UAE VAT (currently 5%) applies to the price of the goods or service regardless of payment method. The BNPL merchant fee you're charged by Tabby or Tamara is a separate cost on your side, not a VAT-relevant change to the customer-facing price.

Which provider should I integrate first, Tabby or Tamara?

Many UAE merchants offer both. If you can only launch one first, check which one your existing payment gateway or e-commerce platform (Shopify, Magento, Salla) already has a pre-built plugin for — that will cut integration time regardless of provider.

What's the biggest technical mistake merchants make integrating BNPL in the UAE?

Treating the browser redirect back to your success page as proof of payment instead of waiting for and verifying the provider's webhook. It works fine in testing and then fails silently in production the first time a customer's connection drops mid-redirect.

Tabby and Tamara BNPL Integration Guide: A Technical Playbook for UAE Merchants