Pakistan
USA
Canada
UK
Dubai
Australia
Germany
- Check for a maintained plugin or an official integration before you commission custom code.
- Payment plugins must handle failure, retries and duplicate notifications, not only the happy path.
- Redirect or hosted payment pages keep card data away from your server and reduce risk.
- Always confirm provider documentation, approval steps and fees directly with the provider.
The payment mix in Pakistan
Pakistani shoppers pay in several ways at once. Cash on delivery remains common, bank transfer is familiar, mobile wallets such as JazzCash and Easypaisa are widely used, and card payments run through local bank and processor gateways. A store that offers only one method loses buyers who prefer another, but a store that offers six poorly integrated methods creates support headaches.
International selling adds another layer. A Pakistani business that wants to collect foreign cards or PayPal may face limits on which providers will onboard it, and those limits change. Treat availability as something you confirm with each provider and with your bank before design starts, not something a developer can promise.
This is why custom gateway plugins exist. Providers publish APIs, but few maintain a polished WooCommerce, Magento or Laravel integration, and public plugins vary in quality. If you are new to the topic, our overview of how to build a WooCommerce plugin explains the general process this article builds on.
Build, buy or use the provider's plugin
The right route depends on how well your needs match what already exists.
Option | Strength | Risk | Best when |
|---|---|---|---|
Provider's official plugin | Maintained by the people who know the API | May be basic or outdated | It covers your checkout flow and works with your platform version |
Third-party marketplace plugin | Quick to install | Support and security depend on the author | You can inspect reviews, update history and code quality |
Custom plugin | Fits your exact flow and rules | You own maintenance and security | No good option exists or your rules are unusual |
Hosted payment link or page | Simplest, keeps payment off your site | Less control over the experience | You sell few items or want to launch fast |
Choosing the checkout experience
There are three common patterns. In a redirect flow, the customer leaves your store, pays on the provider's page and returns. It is simple and keeps card entry off your site, but the journey feels less smooth. In a hosted fields or embedded flow, the payment form sits inside your checkout while the sensitive fields are served by the provider. It looks better and takes more engineering. In a wallet push flow, the customer approves a prompt on their phone, which suits mobile-first buyers but needs careful waiting and timeout handling.
Pick the pattern from your customers, not from developer preference. If most buyers pay from a phone wallet, a flow that requires typing long card numbers will lose orders. If most are repeat buyers on desktop, a smoother embedded form may justify the extra work.
How a custom gateway is built
The sequence below applies to WooCommerce and, with different class names, to other platforms.
- Get sandbox access and documentationObtain test credentials and the current API specification from the provider. Confirm the order of calls, signature rules and webhook behaviour in writing.
- Design the payment flowDecide between redirect, hosted fields or on-site entry. Redirect and hosted approaches keep sensitive data off your server.
- Create the gateway classIn WooCommerce this extends the payment gateway base class, defines settings, and implements the payment and refund methods.
- Handle the callbackVerify the provider's signature, match the notification to the right order, and update the order status only once, even if the callback arrives twice.
- Add logging and reconciliationRecord each request and response (never full card data), and make it easy to match provider reports to store orders.
- Test every outcomeRun success, failure, cancel, timeout, duplicate callback and refund cases in the sandbox, then a small live test before launch.
Go-live rehearsal
Treat launch like a small project. Agree a window outside peak selling hours, take a full backup, switch live credentials, and make one real purchase of a low-value item. Refund it and confirm the refund appears in both systems. Only then enable the method for customers, and keep the old method available for a few days in case you must roll back.
After launch, check the first day of orders against the provider's report line by line. Differences found early are cheap to fix. Differences found at month end are painful. Assign one person on the finance side to own this reconciliation, since developers rarely see the bank side.
What the plugin must get right
The visible part of a payment plugin is a button. The real work is everything that happens when something goes wrong. A customer pays, loses signal and closes the browser before returning to your site. The provider confirms payment, but the customer never lands on your thank-you page. A good plugin relies on the server-to-server notification, not the browser return, to mark the order as paid.
Idempotency matters too. Providers often send the same notification more than once, so the plugin must recognise an order that is already paid and ignore the repeat, otherwise stock and emails fire twice. Amounts and currency should be checked against the order before it is marked paid, so a tampered request cannot underpay.
Finally, think about refunds and partial refunds, order cancellation and expiry for payments left pending. Pakistani stores that also sell on cash on delivery often need to mix both in one order flow, which complicates stock handling and status naming.
Order states to plan for
Name these in your brief so the plugin and your team use the same words.
State | Meaning | Typical action |
|---|---|---|
Pending payment | Customer started but has not paid | Wait, then expire or send a reminder |
Paid, processing | Provider confirmed payment | Pack and ship |
Failed | Payment declined or errored | Offer retry, log the reason |
Cancelled | Customer or admin stopped it | Release stock, void payment |
Refunded | Money returned in full or part | Update stock and accounting |
COD confirmed | Customer verified by call or message | Dispatch and track collection |
Security and compliance notes
Rules vary by provider, bank and platform, so verify current requirements directly. These are the principles that hold in general.
- Keep card data off your serverUse redirects or hosted fields so card numbers never touch your code or logs.
- Verify every callbackCheck the signature or secret before trusting a notification, and compare amount and currency.
- Protect credentialsStore API keys in settings or environment variables, never in the repository or front-end code.
- Use HTTPS everywhereBoth the store and the callback endpoint must be served securely.
- Apply standard WordPress protectionsNonces, capability checks and escaping, as described in our plugin security guide.
- Respect provider and regulator rulesMerchant agreements and State Bank of Pakistan requirements apply to your business. Ask your provider and an adviser what covers you.
- Keep audit logsYou need a trail for disputes and chargebacks, without storing sensitive data.
Mistakes we see on payment projects
Each of these has caused real order and reconciliation problems for stores.
Trusting the browser return
Orders marked paid because a customer reached a URL can be faked. Confirm server to server.
No handling of duplicate callbacks
Double notifications create double stock deductions and emails.
Testing only in the sandbox
Live behaviour can differ. Run a small real transaction with an agreed refund before launch.
Forgetting block checkout
Newer WooCommerce checkouts need separate support for payment methods, so confirm both.
Weak reconciliation
If finance cannot match provider reports to orders, the plugin is unfinished.
Unmaintained code
Provider APIs change, so a plugin with no owner breaks without warning.
Planning the project
Start with a short brief: platform and version, payment methods wanted, whether refunds happen through the plugin, how pending orders should expire, and who handles reconciliation. Attach the provider's documentation and your merchant contact. With that in hand, a developer can estimate honestly.
Costs depend on how complete and stable the provider's API is, the number of payment methods, whether you need refunds and reporting, and how much testing the provider requires before going live. If your platform is Shopify rather than WooCommerce, the options differ, and our guide to accepting payments on Shopify in Pakistan covers that route. For Laravel and custom stores, we handle similar work under API development and integration.
Junaid's take
In my experience, a payment integration is a small amount of happy-path code surrounded by edge cases, documentation gaps and waiting for provider approvals. Businesses underestimate the waiting and the testing, and then blame the developer.
I would first try the provider's own plugin or a well-reviewed one, review the code if it is open, and only then consider custom work. If we do build, I want a sandbox, the provider's named technical contact and a rehearsal of the failure cases on staging before any real money moves.
Offer cash on delivery as well if your customers expect it, but track refused parcels carefully. If you want to discuss a gateway for your own store, get in touch or read about our plugin development services.
Junaid has worked on plugin development for more than 18 years, across SEO, paid media, web development and custom software. He founded SEOnumber1, builds WordPress plugins, CRMs and web applications, has served 500+ clients in 48 countries, and holds Google Ads, Analytics and Google Blue and Green Belt certifications. He is a National Level Award Winner in Digital Marketing. Read his story or ask a question about this article.