Pick your integration route first
Most failed integrations start by choosing the hardest option for no reason. Decide this before anyone writes code:
| Route | Build effort | Best for | Trade-off |
|---|---|---|---|
| Store plugin | Almost none | WooCommerce, WordPress, Shopify stores | Limited UI control |
| Hosted checkout | An afternoon | Any site, fastest path live | Customer leaves your domain |
| Embedded checkout | A day or two | Branded flow, no redirect | Slightly more front-end work |
| Server-to-server API | A week or more | Custom flows, apps, marketplaces | You own every edge case |
If you run a standard store, use the plugin. The only good reasons to go further are a checkout experience you cannot get otherwise, or a flow a plugin simply cannot express — subscriptions with custom logic, marketplace splits, in-app payments.
Route 1 — plugin for WooCommerce, WordPress or Shopify
That is genuinely the whole job for most stores. Rapid Gateway publishes official plugins for WooCommerce, WordPress and Shopify. The thing worth checking before you commit to any provider is whether its plugin is actually maintained — an abandoned plugin breaks on the next platform update and takes your checkout with it.
- Create your merchant account and get approved.
- Download or install the plugin for your platform.
- Paste your merchant credentials into the plugin settings.
- Set your callback or webhook URL if the plugin asks for one.
- Run a test transaction in test mode, then switch to live.
Route 2 — hosted checkout
Hosted checkout is the fastest path for a custom site. Your server creates a payment, you redirect the customer to the provider page, they pay, and they come back. You build no payment UI and handle no card data, which also keeps your PCI scope small.
- Your backend calls the create-payment endpoint with amount, currency, your order reference and customer details.
- You receive a checkout URL and redirect the customer to it.
- The customer pays with cards, Raast, JazzCash, easypaisa or bank transfer on the hosted page.
- The provider posts a signed webhook to your server with the final status.
- Your server verifies the signature, marks the order paid, and fulfils.
Route 3 — embedded checkout
Embedded checkout keeps the customer on your domain in an iframe while the provider still handles the sensitive parts. It is the same API underneath as hosted checkout and fires the same webhooks, so you can ship hosted first and move to embedded later without re-integrating.
Worth knowing before you choose it: an embedded flow gives you a better-looking checkout but the same failure modes, and you still must treat the webhook as the source of truth rather than anything the iframe tells the browser.
Route 4 — server-to-server API
Full API integration is for flows a checkout page cannot express. You authenticate with your credentials, create payments directly, and handle every status transition yourself. Budget properly for it — the happy path is a day, and the edge cases are the rest of the week.
- Authentication — obtain and cache a token rather than minting one per request.
- Idempotency — send a unique reference per payment so a retry never charges twice.
- Status handling — pending is a real state, not an error. Wallet payments often sit pending while the customer approves on their phone.
- Webhooks — verify the signature server-side and treat the webhook as authoritative.
- Reconciliation — poll the status endpoint for anything that never produced a webhook.
The webhook is the part people get wrong
Almost every serious integration bug in Pakistani e-commerce comes down to trusting the browser. The customer redirect can fail, the tab can close, the mobile network can drop mid-return — and if your order only becomes paid when the browser comes back, you will lose paid orders.
The rule is simple: the signed webhook is the truth, the browser is a convenience. Verify the signature on your server, make your handler idempotent so a repeated delivery does not double-fulfil, and respond quickly with a 200 before doing slow work. Our webhooks guide covers signature verification and retries in detail.
Test these before you go live
- A successful payment on each method you intend to accept — do not assume cards passing means wallets pass.
- A failed or declined payment — your UI must say something useful, not hang.
- An abandoned payment — customer opens the page and never pays. The order must not sit paid.
- A wallet payment the customer never approves — this is the most common real-world case in Pakistan and it ends in a timeout, not an instant failure.
- A duplicate webhook — send the same one twice and confirm you fulfil once.
- A real transaction on a real mobile connection before launch. Desktop-only testing hides redirect problems that only appear on mobile data.
Integration mistakes that cost money
| Mistake | What it causes |
|---|---|
| Marking orders paid on redirect | Unpaid orders shipped, paid orders lost |
| No idempotency reference | Duplicate charges on retry |
| Treating pending as failure | Wallet payments rejected that would have succeeded |
| Not verifying webhook signatures | Forged callbacks can mark orders paid |
| Hardcoding credentials in front-end code | Keys exposed to anyone who views source |
| Only testing the happy path | Every edge case debugged in production |
| No reconciliation job | Silent gaps whenever a webhook is missed |
What you need before you can integrate anything
None of the above matters until you are approved. In Pakistan that normally means business registration or NTN, CNIC, a business bank account and your website. Approval takes hours to a few days depending on the provider and your documents.
⚠️ You should not be paying anyone for that approval — if someone asks for an activation or onboarding fee, read onboarding fee scams first.
Integrating with Rapid Gateway
Rapid Gateway is a payment gateway in Pakistan that supports all four routes above through one integration — official WooCommerce, WordPress and Shopify plugins, hosted checkout, embedded checkout, and a REST API with signed webhooks. One set of credentials covers cards, Raast and Raast QR, JazzCash and easypaisa wallets, bank transfer and QR.
There is a sandbox with test credentials so you can exercise the failure cases above before any real money moves — which, given how much of this guide is about edge cases, is the part worth using. Create an account to get credentials, or talk to our team if you want a hand choosing a route.
Frequently asked questions
How long does payment gateway integration take in Pakistan?
A store plugin is under an hour. Hosted checkout is typically an afternoon. Embedded checkout is a day or two. A full server-to-server integration with proper status handling, idempotency and reconciliation is realistically a week, most of it spent on edge cases rather than the happy path.
Do I need PCI certification to accept cards?
Not if you never touch card data. Hosted and embedded checkout keep card entry on the provider infrastructure, which keeps your own scope minimal. If you were to collect card numbers on your own servers, the compliance burden changes completely — which is why almost nobody does.
Can I integrate without a developer?
Yes, if you are on WooCommerce, WordPress or Shopify. Install the official plugin, paste your credentials, run a test payment. Anything beyond a standard store will need someone who can handle a webhook endpoint.
What happens if a webhook never arrives?
It happens — your server could be briefly down, or a delivery can be lost. This is why you also poll the status endpoint for payments that have been pending too long. Treat a GET on the payment status as the final arbiter when a webhook is missing.
Can I test without being approved first?
You can usually build against the documentation immediately, but you need credentials to run real test transactions, and those come with your account. Apply early so approval and development overlap rather than queue.
The bottom line
Choose the simplest route that fits your store, treat the signed webhook as the only source of truth, and test the failure cases before launch rather than discovering them with real customers. Create a Rapid Gateway account for sandbox credentials, or read the JazzCash and easypaisa integration guide for a wallet-specific walkthrough.