How to integrate Tap Payments in Kuwait: KNET, Apple Pay, mada and Benefit

A Tap Payments integration in Kuwait is usually one of two jobs. Either a Kuwaiti business wants KNET, cards and Apple Pay on a website or app, or a brand that already sells in Kuwait wants to add Saudi and Bahraini customers without a second gateway.

Below: Tap's CBK licence, fees and payouts, how each payment method behaves, build steps for web and React Native (Expo), sandbox testing, and the webhook details that cause lost orders. The facts come from the Central Bank of Kuwait register and Tap's developer documentation and help centre (plus Amazon Payment Services' docs for Apple Pay via KNET), checked on 27 September 2026.

Is Tap Payments licensed in Kuwait?

As of 27 September 2026, yes. The Central Bank of Kuwait (CBK) keeps a public register of e-payment services providers. It lists Tap Payments e-Payment Service Provider (KSCC) under the Large EPSP category, with an address in Salmiya and the website www.tap.company.

The register currently shows nine e-payment services providers. Three hold the large category (Tap, UPayments and Hesabe) and six hold the small category. The register does not print licence numbers or dates, so if your compliance team needs a document, ask Tap for a copy of the licence.

If you sell online in Kuwait, your checkout also has to meet Kuwait's digital commerce law. Our digital commerce law checklist for websites maps it to screens and fields. For the full list of licensed options and how they differ for developers, see payment gateways in Kuwait.

Fees, payouts and KNET activation

As of 27 September 2026, we found no published Kuwait fee table on Tap's site, so your transaction rate is a quote for your business. Get it in writing. Tap's help centre does publish these terms:

If most of your customers pay by card, plan cash flow around the 5-day card cycle, not the 2-day KNET one.

Payment methods you get through one Tap integration

Tap's API uses one charge endpoint for every method. You change the source.id and the currency, and Tap routes the payment. The differences that matter are the flow and the currency lock.

Tap's test card page also lists NAPS/QPay (Qatar), STC Pay (Saudi Arabia) and OmanNet (Oman). Ask Tap which of them your Kuwaiti account can enable.

Four ways to integrate Tap

Tap's overview page describes four integration routes. The right one depends on how much of the checkout you want to own.

1. Hosted checkout. Your server creates a charge and the customer pays on Tap's page. Least code, least control over design. Apple Pay and mada appear there without extra work.
2. Card SDK (tokenization). Tap's SDK draws the card fields inside your page or app and returns a one-time token. Your server charges the token. You own the checkout design without handling raw card numbers.
3. Plugins. According to Tap's overview page, its technical team built plugins for WooCommerce, Magento and OpenCart. For Shopify, it lists a native plugin built by Tap and a redirection plugin built by partners.
4. Custom card form. Only if you hold a valid PCI DSS certificate and attestation of compliance. Tap then shares an RSA key to encrypt card data before it reaches their token API. This route is only for merchants that already hold that certification.

For a custom website or app, option 2 plus a redirect for KNET is the common pattern: embedded card fields and an Apple Pay button, with KNET and Benefit sending the customer to their own payment pages.

Integrating Tap on a website

The same steps apply to Next.js, Laravel, Django or any server-rendered stack.

1. Get keys. Register at tap.company, then take the test and live keys from the Tap dashboard. Tap issues a secret key and a public key for each mode. The secret key lives in a server environment variable only. Tap's docs are explicit that secret keys must never be shipped to the frontend.
2. Register your domain. Tap needs the domain that will load its web SDKs registered with them, and that includes the Apple Pay button.
3. Create the charge on your server. Send amount, currency, customer, source.id (a card token, src_kw.knet, src_bh.benefit or src_sa.mada), a redirect.url and a post.url. For KNET and Benefit, the response comes back with status INITIATED and a transaction.url. Send the customer there.
4. Handle the return. Tap sends the customer back to your redirect URL with a tap_id parameter. Your server retrieves that charge from Tap before showing "paid". Never trust the query string alone.
5. Confirm from the webhook. The post.url receives the final status server to server. Mark the order paid from there, after validating the hashstring (below).
6. Refunds. Create them through Tap's Refunds API. Pass a post.url on the refund request so the result also reaches your server; Tap's webhook doc includes a hashstring recipe for refunds too. Retrieve the refund from the API before you update the order.

KNET has its own rules no matter which provider you use. The details are in our KNET integration guide.

Integrating Tap in a React Native (Expo) app

According to Tap's developer docs, Tap offers React Native SDKs for cards, Apple Pay and checkout, alongside Flutter, native iOS (Swift) and native Android (Kotlin) SDKs. For an Expo app, this is the structure we use:

1. Create charges on your backend. The app calls your own API, which creates the charge with the secret key and returns only what the app needs, such as the KNET transaction.url.
2. Open redirect methods in an in-app browser. Open the transaction URL with expo-web-browser, and set redirect.url to a page on your domain that returns the customer to the app through a universal link or your app scheme.
3. Use native SDKs in a development build. Tap's React Native card and Apple Pay SDKs are native modules, so they run in an Expo development build, not in Expo Go. Register the app's bundle ID with Tap, or the mobile SDKs will not run.
4. Keep secrets on the server. Creating charges, retrieving a charge to confirm status, and any hash string an SDK needs belong on your backend. Tap's Flutter checkout docs describe that hash string as an HMAC-SHA256 signature generated with your secret key. The app holds only the public key.
5. Confirm from the backend. The order is released only after your backend reads the charge status from Tap and from the webhook.

Flutter alternative. If your app is built in Flutter, Tap's docs list a Card SDK, a Checkout SDK and an Apple Pay SDK for Flutter. Tap's Flutter checkout sample builds the hash string in Dart; in production, build it on your server and send it to the app. The same rules on bundle ID registration, secret keys and backend confirmation apply.

Apple Pay through Tap in Kuwait

Tap's docs say Apple Pay has to be enabled on the Tap side before it works, and list Kuwait, Saudi Arabia, the UAE, Qatar and Bahrain as supported, with USD as an additional currency.

Three practical points:

• Button placement on the web. Apple Pay does not work inside iframes or pop-up windows, so Tap's docs suggest adding a separate Apple Pay button on your checkout page.
• Hosted checkout. If you use Tap's hosted page, Apple Pay shows up without extra configuration.
• KNET routing in Kuwait. Amazon Payment Services' documentation describes Apple Pay through KNET as mandatory for Apple Pay transactions in Kuwait, and says KNET Apple Pay does not support authorization or recurring operations. Tap's KNET documentation says KNET card payments support authorization. As of 27 September 2026, we did not find the Apple Pay routing described in Tap's docs. If you plan pre-authorizations, subscriptions or saved-wallet billing in KWD, ask Tap in writing how Apple Pay on your Kuwaiti account is routed.

Our Apple Pay integration guide covers the Apple side: merchant IDs, domain verification and in-app setup.

Webhooks, the hashstring and three decimals

Skip the webhook and orders go missing: the customer paid, but your system never hears about it.

• According to Tap's webhook docs, Tap posts to your post.url only for CAPTURED and FAILED charges. INITIATED and ABANDONED charges are not posted, and their post status stays PENDING.
• If your endpoint is unreachable, Tap makes two more attempts, then marks the post status ERROR. Your system needs a job that retrieves stale pending charges directly from the API.
• Tap cannot post to localhost. Use a public tunnel or a staging server when testing.
• Each webhook carries a hashstring header. You rebuild it with HMAC-SHA256 from the charge ID, amount, currency, gateway and payment references, status and created time, using your secret key, then compare.
• The amount must be formatted to the currency's decimals before hashing. Tap's table gives KWD and BHD three decimals (3.000) and SAR and AED two. A KWD order of 12.5 hashed as 12.50 will fail validation every time.

This is also why the redirect is not enough. Tap's docs note that a customer can close the browser or lose connection after paying. The webhook still arrives, and your order still gets marked paid.

Testing in the Tap sandbox: KNET test cards

Test keys create transactions in Tap's sandbox. Tap publishes a test card page with KNET, Benefit, NAPS/QPay, mada, Visa, Mastercard, Amex and OmanNet cards, and STC Pay test phone numbers.

For KNET, Tap's page tells you which test bank to pick from the bank list on the KNET test page, and lists test cards and expiry dates that return CAPTURED or NOT CAPTURED. For cards, specific expiry dates return DECLINED, EXPIRED_CARD or TIMED_OUT. Tap can change these values, so copy them from its page before each test cycle.

A short test plan before launch:

• One captured and one failed payment per method you enable, with the order state set from the webhook, not the redirect.
• A customer who closes the tab on the KNET page.
• A webhook with a tampered amount (your validation should reject it).
• A partial and a full refund, if you offer returns.
• Arabic and English checkout on a real phone, in Safari for Apple Pay.

Selling in Saudi Arabia or Bahrain through Tap

According to Tap's docs, mada (SAR only) and Benefit (BHD only) run on the same charge endpoint as KNET. Adding them means a new source and currency on that endpoint, the same webhook handler, and the same dashboard.

For example, a hypothetical Kuwaiti fragrance brand that sells in KWD today and wants a Bahrain storefront would add a BHD price list, ask Tap to enable Benefit, and route Bahraini orders to src_bh.benefit. The order, refund and reconciliation code it already runs for KNET stays the same. Whether that brand needs a separate merchant account or legal entity in Bahrain or Saudi Arabia is Tap's call during onboarding. Ask before you build.

For other CBK-licensed providers, see our guide to payment gateways in Kuwait and our MyFatoorah integration guide.

Before you go live

• Swap test keys for live keys on the server and in the app or web SDK configuration.
• Point redirect.url and post.url at production URLs over HTTPS.
• Ask Tap to enable each method you need (Apple Pay, Benefit and others are switched on by Tap).
• Run one small live payment per method and per channel (web and app), then refund it.
• Store Tap's charge ID and your own order reference on every order for reconciliation.

How Rukn builds Tap integrations

We build the checkout, the server side and the webhook handling as part of a website or app project, in Arabic and English, and test every enabled method in the sandbox before launch. See our web development service for Kuwaiti businesses. Websites start from KD 799 and mobile apps from KD 1,999; the final quote depends on scope.

Send us the payment methods and countries you need through our contact page, and we will reply with an integration plan and a quote.