Integrating Tabby, Tamara and Card Payment Gateways into UAE Web Apps

Taking payments online in the UAE is more involved than dropping a checkout button onto a page. Customers expect to pay by card, by Apple Pay or Google Pay, and increasingly in instalments through buy-now-pay-later providers such as Tabby and Tamara. Each method has its own integration, its own status updates and its own refund rules, and all of them have to end up correctly in your orders and your accounts.

This guide is for developers, product owners and e-commerce managers. It covers the UAE payment landscape, how to choose a gateway, how an integration works end to end, what changes when you add Tabby and Tamara, and how to reconcile, secure and test the whole thing. "Integrated" here means the full payment lifecycle working reliably, not one successful test transaction.

The UAE payment landscape

Card gateways and acquirers

Card payments reach your bank through a gateway and an acquirer. Providers active in the UAE include Network International (N-Genius), Telr, PayTabs, Checkout.com, Amazon Payment Services and Stripe, among others. They differ in pricing, settlement timing, supported card schemes and currencies, and the quality of their developer tools. Fees and terms change and are often negotiated, so compare current published terms and quotes directly with each provider rather than relying on comparison articles.

Buy now, pay later: Tabby and Tamara

Tabby and Tamara let customers split a purchase into instalments while the merchant is paid by the provider, which takes on the credit decision and the collection. For the merchant, BNPL behaves like a separate payment method with its own checkout flow, eligibility rules, settlement and refund process.

Wallets: Apple Pay and Google Pay

Wallets let customers pay with a card stored on their phone, usually confirmed with Face ID, a fingerprint or a passcode. In most cases you add them through your card gateway rather than through a separate contract, because the gateway processes the underlying card payment.

Choosing a gateway: criteria that matter

Use these as an evaluation checklist when comparing providers, filling it in from each provider's current documentation and sales conversations:

• Payment methods: card schemes, Apple Pay, Google Pay, and whether BNPL is offered through the gateway or contracted separately.
• Integration options: hosted payment page, embedded or hosted fields, direct API.
• Currencies: which currencies you can charge in, and which you are settled in.
• Refund API: full and partial refunds available programmatically, not only through a dashboard.
• Webhooks: which events are sent, how they are signed, and how retries work.
• Platform plugins: maintained plugins for Shopify, WooCommerce or whatever platform you use.
• Sandbox quality: a realistic test environment with test cards and failure scenarios.
• Settlement reports: reports, downloadable or via API, that show fees and refunds per transaction.
• Support: technical support that responds when something breaks.

How a gateway integration works end to end

Hosted page vs embedded fields vs direct API

• Hosted payment page: the customer is redirected to the gateway's page to pay, then returned. The simplest option, and it keeps card data entirely off your systems.
• Embedded or hosted fields: the card fields are served by the gateway but appear inside your checkout. A smoother experience, while card data still goes straight to the gateway.
• Direct API: card data passes through your servers to the gateway. Maximum control, but it significantly increases your PCI DSS obligations, and few businesses need it.

The flow, step by step

1. Your application creates an order and a payment request with the gateway, using a unique reference.
2. The customer pays on the hosted page or fields.
3. The customer is redirected back to your site.
4. The gateway sends a webhook to your server confirming the result.
5. Your server verifies the webhook, updates the order, and triggers fulfilment and invoicing.
6. Later, the gateway settles funds to your bank, and each settlement is matched back to orders.

Webhooks and payment status

The single most important rule: the redirect back to your site is not proof of payment. Customers close browsers, lose connection or tamper with return URLs. The source of truth is the gateway, confirmed through a verified webhook or a server-to-server status check. Your webhook handler should verify the signature, look up the payment status if in doubt, and be idempotent. Gateways retry webhooks, so the same event can arrive more than once, and processing it twice must not ship two orders or send two invoices. Store the gateway's event or transaction ID and ignore duplicates.

Refunds, partial refunds and cancellations

Plan these from the start. Can staff issue a refund from your own admin, or must they log into the gateway? What happens to stock and to the invoice? A partial refund needs a matching credit note for the refunded lines. Where the gateway separates authorisation from capture, cancelling before capture works differently from refunding afterwards. The integrations that cause the most pain later are the ones that take money perfectly well but treat refunds as an afterthought.

Adding Tabby and Tamara to checkout

Eligibility checks and promotional messaging

BNPL providers decide whether a customer is eligible and typically set conditions such as order value limits. Your checkout should show the option only where it applies and handle a rejection gracefully, offering card payment instead. Both providers also offer on-site messaging, such as showing the instalment amount on product pages, which should follow their published guidelines.

Order capture, cancellation and refund flows

A BNPL order typically involves the provider authorising the purchase and the merchant confirming or capturing it. The merchant must also tell the provider about cancellations and refunds, including partial ones, so the customer's instalments are adjusted. Wire these steps into your order management rather than relying on someone to update a separate merchant portal. API details change, so build from each provider's current developer documentation.

Platform plugins vs custom integration

If you run Shopify, WooCommerce or another major platform, start with the provider's official plugin or app; it covers most flows and is maintained by the provider. A custom integration through the API makes sense for custom web applications and mobile apps, or where your order process has steps the plugin cannot handle, such as deposits, split shipments or bookings.

Reconciliation with accounting and ERP

Each provider pays out on its own schedule, net of fees and refunds, often grouping many orders into a single bank transfer. Reconciliation means matching every settlement back to its orders, fees and refunds, so your accounts show sales, fees and receivables correctly. The practical way to do it is to import each provider's settlement reports, or pull them by API, and match on the transaction references you stored at checkout. If references are not stored consistently from day one, reconciliation becomes manual detective work every month.

If you need payment data flowing automatically into an ERP or accounting system, our API and system integration services cover designing those flows.

Security, PCI DSS scope and data protection

• Never store full card numbers or security codes. Use hosted pages or fields, and the gateway's tokens for saved cards and repeat payments.
• Hosted pages or fields keep most of your systems out of PCI DSS scope. You still have obligations, so confirm your validation requirements with your gateway or acquirer.
• Keep API keys and webhook secrets out of source code and restrict who can see them.
• Serve everything over HTTPS and verify every webhook.
• Treat customer names, addresses and phone numbers as personal data under the UAE PDPL; our guide to PDPL compliance covers the essentials.

VAT and invoicing considerations

The payment method does not change what you have sold. Whether a customer pays by card, wallet or BNPL, your tax invoice must still meet Federal Tax Authority requirements; see our guide to VAT-compliant invoicing. Refunds should produce credit notes rather than edits to the original invoice. How provider fees are treated is a question for your accountant, and specific VAT treatments should be confirmed with your tax adviser.

Testing and go-live checklist

1. Successful sandbox payment for each method you offer: card, Apple Pay, Google Pay, Tabby, Tamara.
2. Declined card, cancelled payment and BNPL rejection each handled with a clear message.
3. Customer closes the browser after paying: the order is still confirmed through the webhook.
4. Duplicate webhook delivered: the order is processed once.
5. Webhook with an invalid signature is rejected.
6. Full and partial refunds issued from your admin, with credit notes and stock updated.
7. Apple Pay domain verification completed for the production domain.
8. Settlement report matched against test orders.
9. Production keys stored securely and sandbox keys removed.
10. Alerts in place for failed webhooks and payment errors.
11. One real low-value transaction and refund completed on production before launch.

If you are planning a store or app that needs these payment methods, see our e-commerce development in Dubai. For travel-specific considerations such as deposits and supplier payments, read payment gateways for UAE travel booking websites.