How do I add KNET payments to a website or app in Kuwait?
Confirm merchant eligibility and KNET availability with your bank or provider, then use its supported integration. Keep order and payment references separate, verify status through the approved server-side process, and test success, failure, cancellation and refunds. Reconcile orders with provider records; a returned browser page is not sufficient proof.
The key idea
Payment integration includes merchant onboarding, technical confirmation and daily finance work. Treat all three as launch requirements.
Ask the provider before fixing the launch date
Give the provider your business activity, website or app details and payment journey. Ask which documents, approvals and account arrangements it needs. Confirm explicitly that the proposed account supports KNET and your platform. Several advertised payment services do not mean every service is enabled for every merchant.
KFH publishes merchant payment services, while MyFatoorah publishes integration documentation. Start there, then obtain written confirmation for your business. Ask about setup, recurring and transaction charges, settlement, refunds and support. Separate these costs from development. Avoid promising a fixed activation date until the responsible provider has confirmed the process.
Describe the amount and customer journey
Specify where customers see the full KWD amount, including delivery or applicable charges, before paying. Keep the displayed total, order total and requested payment amount consistent. Ask how the integration handles Kuwaiti dinar precision; a rounding mismatch should not become a customer-support problem.
Decide whether customers leave the site for a hosted page or use another approved method. MyFatoorah documents different integration routes and a demo environment. Review your chosen route instead of assuming a plugin covers everything. Test Arabic and English checkout on a phone, the back button and returning to an order after an interrupted session.
In practice · illustrative example
Decide what staff should do when the result is unclear
An illustrative customer completes a payment attempt, closes the browser and contacts your office to ask whether the order exists. Your staff need a reference that connects the order and its payment attempt. A vague success page or a screenshot sent by the customer should not be the only way to investigate the result.
Agree with the chosen payment provider how results are verified, how pending attempts are investigated and who handles reconciliation. Rehearse the customer-facing messages with finance and support staff. The wording should explain what is known and the next step, without inviting the customer to pay again while the first attempt remains unresolved.
An order and its payment attempt need distinct records
-
Identify the order
The customer and staff share a usable order reference.
-
Start the attempt
The selected provider's agreed payment journey is followed.
-
Verify the result
The team relies on the provider's approved verification process.
-
Resolve exceptions
Pending or disputed outcomes have a named investigation owner.
Separate the order from the payment attempt
An order can have several payment attempts. Give the order its own reference and retain the provider reference for each attempt. Decide when stock is reserved, how long unpaid orders remain pending and what staff may fulfil. “Payment pending” must not look identical to “paid” in the dispatch screen.
Ask the supplier to show payment verification using the provider’s approved mechanism. Customer-facing success text should reflect confirmed status. Repeated notifications or refreshing a page should not create another paid order or deduct stock twice. Show “we are checking your payment” when a result is delayed, with a reference customers can share.
Rehearse the awkward cases
Use approved test access and payment methods. Do not experiment with production payments without agreement. Include cancellation, decline, a slow confirmation and closing the browser after paying. Then try paying again for the same pending order. Staff should understand the result without asking for payment-card details.
Prepare support wording carefully. “Your payment failed” and “we have not yet confirmed payment” mean different things. Give staff a check for uncertain results before inviting another payment. Keep the technical information needed for investigation, while excluding secrets and sensitive payment data from ordinary emails and support screenshots.
Make finance part of acceptance
Clarify who requests or approves refunds, where the action happens and how its status reaches the order. Ask about full and partial refunds, fees, expected processing and payment-method support. Cancelling an unpaid order is different from refunding a completed payment; the records should reflect that.
For an example, imagine a two-item order where one item cannot be supplied. Finance needs the original payment, approved refund and remaining sale to be traceable. Reconcile order references, provider references and settlement records regularly. An exceptions report for unmatched payments is often more useful than a decorative sales dashboard.
Before launch, ask someone from finance to follow one test order through payment, cancellation or refund, and reconciliation. Have another colleague handle the support question. If each person needs the developer to interpret the record, the handover is incomplete. Agree a named owner for payment-provider communication and an escalation route for unresolved results.
A worksheet for your team
Review payment exceptions with finance
Ask the provider and your finance team to agree the evidence used for each outcome.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Browser closed | An attempt whose customer-facing return was interrupted. | Explain how staff investigate it without guessing. |
| Pending outcome | A reference and an agreed verification route. | Avoid a premature instruction to repeat payment. |
| Daily review | Records that finance can connect to orders. | Assign reconciliation and unresolved-case follow-up. |
A payment integration is ready when customers, support and finance can understand the same result. Include those people in acceptance, not only the developer.
Payment integration acceptance checks
- Provider confirmation of merchant eligibility, KNET and platform support.
- Full KWD total and consistent precision.
- Separate order and payment references with verified status.
- Tests for cancellation, delays and duplicate notifications.
- Refund permissions, support instructions and reconciliation owner.
Frequently asked questions
Can a developer activate KNET without merchant approval?
Integration preparation can begin, but activation depends on provider requirements and approval. Confirm documents and account steps before committing to launch.
Is returning to a success page enough?
No. Confirm the result through the supported provider process and match the order and amount. Keep a pending state when confirmation is uncertain.
Does installing a payment plugin finish the work?
The plugin may supply part of the integration. Merchant setup, configuration, tests, refunds and reconciliation still need attention. Confirm compatibility with the actual checkout.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
Sources checked:
Plan your payment journey with GateGold
Share your store or app, provider and fulfilment process. GateGold can discuss integration scope and checks before you take live payments.
