Skip to main content
Work through every item below before you switch to production. Each one corresponds to a failure mode that regularly reaches support after launch — most of them are caught in minutes here, and cost hours once real money is moving.
Complete all testing against the sandbox using the test credentials before starting this checklist. This page assumes your integration already works end-to-end in test.

​
1. Test Coverage

Confirm you have actually exercised each path — not just the happy one.
  • Successful payment with K-Net completes and returns CAPTURED
  • Successful payment with Visa and MasterCard completes and returns CAPTURED
  • Apple Pay tested, if you intend to offer it
  • Customer cancelling on the payment page is handled gracefully
  • Declined or failed payment shows a clear message and allows a retry
  • Customer closing the browser mid-payment does not leave a permanently stuck order
  • Status check correctly identifies every paymentStatus value, not just CAPTURED
  • Full refund tested end-to-end and confirmed via the status endpoint
  • Partial refund tested end-to-end and confirmed via the status endpoint
  • Refund against an ineligible transaction fails cleanly without crashing your handler

​
2. Configuration

  • Base URL is read from a configuration variable, not hardcoded
  • Production private key obtained and stored separately from the test key
  • success_url and error_url point to live, publicly reachable production URLs
  • currency is set correctly (414 for KWD)
  • language is set appropriately for your customer base
  • Every endpoint switched to production — initialization, status check, and refund
It is common to switch the initialization URL to production and forget the status check or refund URLs. Verify all three explicitly.

​
3. Security

  • Private key is never present in front-end JavaScript, mobile binaries, or public repositories
  • All Payzah API calls are made server-side only
  • Private key is stored in environment variables or a secrets manager, not in source control
  • API keys and error responses are excluded from any logs shared with third parties
  • HTTPS enforced on your success_url and error_url endpoints

​
4. Order Integrity

  • trackid is unique for every transaction and never reused
  • Order fulfilment is triggered only on paymentStatus: CAPTURED
  • The redirect alone never marks an order as paid — status is always verified server-side
  • Duplicate refund submissions are prevented on your side (retries, double-clicks, background jobs)
  • Amounts are validated against your own order record before initialization and before refunding

​
5. Logging and Reconciliation

  • Every request and response is logged with trackid, PaymentID, code, and message
  • Refunds logged separately with refrence_code, amount, and refund_type
  • Logs are retained long enough to cover your chargeback and dispute window
  • A reconciliation process exists to compare your records against Payzah settlements

​
6. First 48 Hours After Launch

  • Process one small real transaction yourself and confirm it settles
  • Process one small real refund and confirm it completes
  • Monitor error rates and response codes closely for the first day
  • Have a rollback plan — know how to disable checkout quickly if something is wrong
  • Confirm your support team knows how to look up a transaction by trackid
Launch during business hours on a weekday, not late on a Thursday. If something breaks, you want your team and Payzah support both reachable.

Test Credentials

Sandbox cards for K-Net, Visa, MasterCard, and Apple Pay.

Best Practices

Security, logging, and transaction management guidance.