KNET payment gateway integration is rarely blocked by code. It is blocked by a commercial registration in the wrong name, a settlement account that is not corporate, or a compliance reviewer opening a half-finished site. This is the practical version: what KNET, Tap and MyFatoorah actually require, the sequence and how long each step really takes, what breaks once real money moves, and what we do differently in a build.

What KNET, Tap and MyFatoorah actually require

Every route to KNET starts from the same paperwork, and it is company paperwork, not developer paperwork. You need a valid commercial registration (CR) from the Ministry of Commerce and Industry with an activity that matches what you are selling, the authorised signatory's Civil ID, and a corporate bank account in Kuwait in the company's exact legal name. Personal accounts are rejected at review, every time. Add a bank or IBAN letter confirming that account, plus an estimate of monthly volume and average ticket size.

Then there is the split most teams miss. Going direct to KNET means a local bank sponsors you as an acquiring merchant and you get your own merchant ID through the KNET switch: cheaper per transaction at volume, but on the bank's timeline and with the bank's integration documents. Going through an aggregator such as Tap or MyFatoorah means you sit under their merchant arrangement: onboarding in days, a higher per-transaction cost, and KNET plus Visa, Mastercard and Apple Pay in one integration.

Both routes review your live site or app before issuing production keys. They look for prices in KWD, a refund policy, a delivery or service-fulfilment policy, terms of use, a reachable Kuwait phone number, and the whole thing legible in Arabic as well as English. An unfinished site is the single most common rejection we see — and it is a rejection that costs weeks, not hours.

The real sequence and timeline

The order is not negotiable, because each step is an input to the next:

  • CR and corporate bank account — 1 to 3 weeks if the CR is already clean. Nothing else can start.
  • Gateway application and KYC — 2 to 5 business days for an aggregator; longer if the signatory is abroad.
  • Sandbox credentials — usually the same week. Build the entire checkout here, including failure paths.
  • Compliance review of the live site — the step that silently eats a month, because it only begins once the site is genuinely complete.
  • Production keys — 1 to 3 weeks after compliance passes for an aggregator; 4 to 8 weeks for a direct KNET merchant ID.
  • Settlement configuration — payouts land T+1 to T+3 business days into the Kuwaiti account, with weekend and public-holiday gaps.

Realistically: 3 to 6 weeks to live payments with an aggregator if paperwork is ready, 6 to 10 weeks for direct KNET. Plan it in parallel with the build, not after it. Our ranges for the surrounding work are in app cost Kuwait and website cost Kuwait.

What breaks once real money moves

The 3DS redirect. KNET is a hosted redirect flow, not a card form you embed. The customer leaves your app for a bank page and has to come back — so you must handle deep-link returns on iOS and Android, session timeouts, and the user closing the browser mid-authentication. 3-D Secure on cards adds a second challenge screen with its own abandonment. Treat the redirect parameters as a hint only: the sole source of truth is a server-side verification call plus the gateway webhook.

Lost callbacks. The payment succeeds, the callback never arrives, and you have an orphan payment and an angry customer. You need an idempotency key per order, a payment state machine that can be re-driven, and a daily job that pulls the gateway's transaction list and matches it against your orders. Match on the gateway reference, never on your own order ID alone.

Refunds. A KNET refund is not a card void. It settles back to the original account on its own cycle, partial refunds are not supported on every configuration, and some setups have a refund window. Build a manual refund path with an audit log from day one rather than discovering this in month two.

Fils and Arabic receipts. KWD has three decimal places and gateways expect the amount as an integer number of fils. A two-decimal assumption anywhere in the stack charges the wrong amount quietly. Receipts and invoices need right-to-left layout, the company's Arabic legal name exactly as it appears on the CR, and three-decimal totals — most invoice templates get all three wrong.

What we do in a build

We model payments as a persisted state machine — initiated, redirected, verified, settled, refunded, failed — and store every raw gateway payload for reconciliation and disputes. The gateway sits behind one provider interface, so moving from MyFatoorah to direct KNET later is a configuration change, not a rewrite of checkout. Verification is always server-side, webhooks are idempotent, and a nightly reconciliation report flags any mismatch before the customer does.

Receipts are Arabic-first, not translated afterwards. On Printit, a Kuwaiti print marketplace, quoting, mapping and payment sit in the same flow: the price is computed live, the customer pays, and the job reaches the right print house — which is exactly where payment-state bugs become operational ones. Where it earns its place we add an AI layer on top of the same data — failure triage, reconciliation summaries, automated quoting — which is the kind of work covered on our AI services page.