Tap Payments in the UAE (2026): fees, 5-day settlement and integration

Tap does not publish a public rate card for the UAE. Its own pricing page says the rate depends on your industry and annual sales volume. The number repeated across every UAE comparison page in August 2026 is 2.75% per transaction with no setup fee and no monthly fee, and that band is close enough to budget against, but it is not a quote. The figure that actually decides your cash position is in Tap's own support documentation rather than on any comparison page: transactions settle in 5 business days, and payouts run to your bank weekly, every Tuesday, with a minimum of AED 100 for corporate accounts and AED 1,000 for individual accounts.

The numbers I will not repeat

You will find pages quoting Tap approval rates to one decimal place. 94.1% here, 96.2% there, usually credited to some round number of test transactions run by a reviewer nobody can name. I am not repeating those. No gateway in this region publishes acceptance rates by merchant category, and no third party can measure yours without your traffic, your card mix and your fraud rules.

Three things you can verify yourself inside two weeks, which beat anyone's percentage:

• Ask Tap sales for a written rate sheet with your industry classification and expected monthly volume on it. Negotiated rates differ by volume, so the sheet is the only rate that applies to you.
• Push one live charge of AED 5 through production, then refund it. You now know the checkout behaviour, the refund path and the timestamps.
• Reconcile your first payout line by line against the charges it covers. That tells you the real settlement date and the export format your finance process has to live with.

Everything below that is stated as fact comes from tap.company, developers.tap.company or support.tap.company. Where a widely repeated number has no official source, I say so instead of laundering it into a table.

What Tap charges in the UAE

The pricing model is per-transaction with no monthly commitment for standard merchants. As published across UAE market comparisons in August 2026, the headline is 2.75% per successful transaction covering Visa, Mastercard, Amex and JCB, with no setup fee and no monthly platform fee. Tap's own UAE site does not display this figure. It routes you to sales, because the rate moves with category and volume.

That distinction matters more than it sounds. A salon doing AED 40,000 a month and a marketplace doing AED 900,000 a month are not being offered the same sheet, and quoting the public band back at a sales rep will not get you the second one. Volume gets you the second one.

Two structural points worth understanding before you compare Tap against anything else:

The percentage is charged per successful transaction, and there is no fixed per-transaction component in the standard UAE structure that Tap publishes. On small tickets that is a real advantage over gateways that add a flat AED 1, where a AED 25 sale carries another 4% on top of the percentage. Our comparison of Telr, PayTabs and Stripe in the UAE works through that arithmetic for the flat-fee models.

International cards and cross-currency settlement price above the domestic band with every UAE acquirer, Tap included. If a meaningful share of your buyers pay on foreign-issued cards, your blended rate lands above the headline no matter what the sheet says.

Settlement and payout: where the comparison pages are wrong

This is the part I would check before signing anything, because the widely circulated figure for Tap UAE is T+3, and Tap's own support article says something different.

What Tap publishes: transactions settle in 5 business days, and settled balances are then transferred to your bank account for free on a weekly cycle, every Tuesday. Corporate merchants in the UAE see the bank transaction land on Friday. Payout minimums are AED 100 for corporate accounts and AED 1,000 for individual accounts. If you want money released below the minimum, Tap charges AED 15 for that early payout. You can also ask customer support to make the cycle less frequent, fortnightly or monthly, if weekly transfers clutter your bank statement.

Run that against a real week. A customer pays you on Wednesday afternoon. Five business days puts settlement around the following Wednesday. The next weekly payout window is Tuesday after that. Depending on where the payment falls in the cycle, cash arrives roughly one to two weeks after the customer saw "payment successful" on their screen.

Nobody's cash forecast should be built on the checkout confirmation screen. Build it on payout dates. If your rent, salaries and supplier terms need money faster than that, negotiate settlement timing during the sales conversation, before you integrate, because it is far harder to renegotiate after you are live and switching costs are real.

What quietly raises your effective rate

The nominal percentage is never what you pay across a full month. Three cost lines sit outside the headline, and Tap does not publish specific figures for all of them, so I will describe the mechanism rather than invent numbers.

Currency conversion is the largest one for most Dubai businesses that sell abroad. If you accept in USD and settle in AED, a conversion happens somewhere in that chain and it carries a spread. Tap does not publish an FX margin for UAE merchants, so ask for it in writing and ask specifically whether it is applied at authorisation or at settlement. A spread you cannot see still comes out of your revenue.

Chargeback handling costs money per case, and in the UAE market the band across regional gateways runs roughly AED 50 to AED 150 per dispute. The fee applies whether you win or lose. Tap does not publish a public UAE chargeback fee, so this is a question for your rate sheet, not something to assume.

The processing percentage on a refunded transaction is generally not returned to the merchant by regional gateways. On a AED 5,000 sale refunded in full, that is roughly AED 138 gone at a 2.75% rate. A business with a 10% refund rate should model that as a line in unit economics rather than treating it as noise.

Take your last full month, add processing, conversion, refunds and disputes together, divide by gross sales. That blended number is your real rate. It is usually 15 to 30 basis points above the headline for a domestic-only merchant and a good deal more for anyone selling cross-border.

Payment methods and licensing

Tap Payment Services L.L.C. is licensed by the Central Bank of the UAE as a Retail Payment Services Provider, and Tap now holds licences across every GCC market. That is checkable on tap.company's regulatory licences page, and it is the kind of thing worth checking rather than assuming, because plenty of tools operating in this market are reselling somebody else's licence.

On methods, Tap covers the international card schemes plus the regional debit rails that actually matter if you sell across the Gulf: mada in Saudi Arabia, KNET in Kuwait, Benefit in Bahrain, along with Apple Pay and Google Pay. That regional coverage is the single strongest argument for Tap over a card-only processor. A Kuwaiti buyer who does not see KNET at checkout is a lost sale before your fee ever applies, and no amount of conversion optimisation fixes a missing payment rail.

Onboarding: what actually holds the file up

Tap asks for the standard UAE merchant pack. Business licence or commercial registration, ownership and signatory identity documents, and a valid IBAN certificate from your bank confirming the business account. Tap's support documentation is explicit that additional documents get requested depending on ownership structure and business activity.

I am not going to give you a number of days, because the published sources contradict each other and Tap does not commit to one. What I can tell you is what stalls applications, since this is the same pattern across every acquirer in this market:

1. The trading name or activity on the licence does not match what the website sells. A licence for management consultancy pointed at a supplements store cannot be classified by the acquirer, and the file sits.
2. There is no live website with visible pricing, refund policy, delivery terms and contact details. A staging link or a coming-soon page fails this. Underwriters open the site.
3. The IBAN certificate carries an account name that differs from the licensed entity. This one is nasty, because it often passes application review and fails at the first payout instead, with money parked while support tickets travel.
4. The revenue model raises questions. Long delivery windows, subscriptions, travel and anything resembling deposits against future service invite follow-up questions and sometimes a rolling reserve.

Fix all four before you apply and you skip most of the back and forth. If the licence genuinely does not match the business, fix the licence first. No amount of chasing the gateway solves an underwriting problem.

The API: charge, authorize, refund, invoice

Tap's REST API is the reason developers pick it over the lighter tools. Authentication is HTTP token based: you send your secret key as a bearer token in the Authorization header. Keys are issued in four flavours from the dashboard under API Credentials, a public and secret key for test, and a public and secret key for live. Tap's support team will not send secret keys by email, which is correct behaviour and also a decent signal about the operation.

The core objects you will use:

• Charge creates a payment and returns a hosted checkout URL or a token-based flow if you are collecting card data through the SDK.
• Authorize holds funds without capturing them, which is what you want for bookings where the final amount is not fixed at reservation time.
• Refund reverses a captured charge, in full or partially, against the original charge ID.
• Invoice generates a hosted invoice with a payment link, which is the fastest path if you sell by quote rather than by cart.

The webhook is the piece that decides whether your operation is automated or manual. Tap sends a server-to-server POST when a charge, authorization, invoice or recurring payment changes state, and signs the payload with an HMAC-SHA256 hashstring. Your endpoint recomputes the hash with your secret key and compares. If it matches, the call is genuine.

Plugins exist for Shopify, WordPress and WooCommerce, Magento, OpenCart, PrestaShop, Joomla and ExpandCart, plus direct integrations with regional platforms like Salla, Zid and Zyda. If you run a standard store, install the plugin and spend your engineering time elsewhere. Test the live keys with real small-value cards before you trust it, because plugin versions drift against platform versions and a sandbox pass tells you very little.

What happens after the payment, which is the part nobody builds

The gateway's job ends when the money is captured. Everything your team actually does after that is unbuilt by default: matching the payment to the order, moving the deal, telling the customer, telling the owner, filing the receipt.

Here is the flow we run, described precisely enough to hand to a developer:

1. Create the charge through the API with your CRM deal ID carried in the metadata and in the post URL. Never rely on matching by amount and name later. Two customers paying AED 350 on the same afternoon will teach you why.
2. Send the checkout link into the thread where the customer asked to pay. In practice that is WhatsApp for most Dubai service businesses, and the link needs to arrive in seconds, not after someone opens a dashboard.
3. Receive the Tap webhook on your endpoint. Recompute the hashstring, compare, reject anything that does not match.
4. Deduplicate by charge ID before you act. Webhooks retry. If your handler is not idempotent you will post two confirmations to the same customer and book the payment twice.
5. Update the deal: stage to paid, amount, charge ID, timestamp. Write the charge ID, because that is what makes a dispute defensible six weeks later.
6. Fire the confirmation back into the same conversation thread, and notify the owner if the ticket size warrants it.
7. Handle the refund event through the same path in reverse, so the follow-up sequence stops chasing a customer you refunded yesterday.

The trap almost everyone hits: treating the browser redirect after checkout as the payment confirmation. The customer pays, closes the tab before the redirect completes, and your system never learns anything happened. The webhook is server-to-server and fires regardless of what the customer's browser did. Use it as the source of truth and treat the redirect as cosmetic.

I know the cost of skipping this because we paid it. Running collections for our own studio group, two sync bugs between the payment confirmation and the CRM stage left roughly AED 15,000 of paid bookings sitting in the CRM marked unpaid for weeks. Nobody stole anything. The money was in the bank. The system just did not know, so customers got chased for payments they had already made. That is the failure mode of a gateway with no automation layer behind it, and it gets worse as volume grows, not better.

Wiring one process end to end like this is our payment and CRM automation build, from AED 6,000 to set up and AED 1,200 a month to run. Getting the link into the conversation within seconds, at 3am on a Saturday as reliably as Monday morning, is what our WhatsApp AI sales agent handles. If you want the mechanics of link-in-chat collection specifically, we covered payment links inside WhatsApp separately.

Tap Connect for marketplaces and multi-vendor platforms

If you are running a platform where money has to reach somebody other than you, Tap Connect handles it natively, and this is where Tap separates from the lightweight tools entirely.

The model: you hold Marketplace Keys, which are used to onboard businesses through the Business API. Each business you create returns a unique destination_id. When a payment comes in, you add a destinations object to the charge and specify how the amount splits, part to the vendor, part to you as commission. Merchant Keys handle the payment processing itself.

The operational catch, straight from Tap's documentation: you can accept payments for a business immediately after onboarding it, but payouts to that business are blocked until its KYC completes and Tap approves the account. If you launch a marketplace and onboard fifty vendors in a week, you can take money for all of them and pay out to none of them. Vendors will not read your documentation about this. Sequence the KYC ahead of the launch, or you will spend your first month explaining held funds.

Tap versus the lightweight payment link apps

Mamo and Ziina occupy a different slot. They are built for getting a link out fast with minimal onboarding and no developer involved, which is genuinely the right answer for a freelancer, a small clinic taking a handful of payments a week, or anyone testing whether people will pay at all.

Tap is the choice when the payment has to sit inside something. A checkout you control, an app, a marketplace with splits, a CRM that reacts to the webhook. You are paying for an API surface, regional debit rails and a licensed acquiring relationship, and you need someone who can write code against it. If you have no engineering resource at all and no plan to get any, that surface is cost without benefit, and a link app will serve you better this quarter.

Volume also decides it. Above roughly AED 500,000 a month, you should be negotiating rather than accepting anyone's public band, and Tap will negotiate. Link apps generally will not.

Who Tap is wrong for

Individual account holders with low turnover get squeezed by the AED 1,000 payout floor. If you clear AED 600 in a fortnight, that balance sits until it crosses the line or you pay AED 15 to release it early.

Businesses that need money in the account within 48 hours will find the standard 5 business day settlement plus weekly cycle painful. Negotiate faster settlement before you integrate, or pick a provider whose default cycle matches your cash needs.

Anyone expecting the gateway to run their sales process will be disappointed, which is true of every gateway. Tap moves money and reports on it. It does not update a deal, confirm a booking to the customer, or follow up with someone who opened the link and closed it. That layer is a separate build. If you want to know where your current flow stops moving without a human pushing it, that is exactly what a growth audit maps, and our full price list is public so you can work out the cost before you talk to anyone.