Mobile Apps

Payment Gateway Integration for Pakistani Apps: JazzCash, Easypaisa, and Card Options Compared

By Daniyal Hassan · · 11 min read

If you are building a mobile app and need to actually collect money from users in Pakistan, this is the post I wish someone had handed me in 2009. We have wired up payment gateway integration in Pakistan for marketplaces, food delivery, ed-tech, and B2B SaaS apps, and the honest truth is that the gateway you pick matters less than understanding the approval friction, the per-transaction economics, and how each rail behaves on a mid-range Android phone in Faisalabad with a flaky 4G signal. This is a practitioner’s comparison of JazzCash, Easypaisa, and card options — fees, paperwork, and the integration work nobody warns you about.

The short version: which rail should your app use?

Most Pakistani apps end up offering three things at checkout: a mobile wallet (JazzCash and/or Easypaisa), card payments (Visa/Mastercard via an aggregator), and cash on delivery. You rarely pick one. The real decision is the order you build them in and how much engineering you sink into each.

  • JazzCash and Easypaisa — best for consumer apps where most users do not own a credit card. Lower friction for the buyer, but you carry KYC and settlement-timing realities.
  • Card payments (aggregators) — necessary if you serve urban, higher-income, or diaspora users, and mandatory if you want recurring/subscription billing that actually works.
  • Cash on delivery — not a gateway, but in Pakistan it is still a payment method you cannot ignore for physical goods. Plan for it in your data model from day one.

If you only have budget for one integration in your MVP, and your audience is mass-market, start with one wallet plus COD. Add cards once you have revenue to justify the higher fees and the heavier compliance lift. We cover that build sequencing as part of our mobile app development work, because doing it in the wrong order burns weeks.

JazzCash API integration: what it really takes

JazzCash is the most common starting point for app payment gateway integration in Pakistan because of reach — it sits on the largest mobile network and a huge chunk of mass-market users already have a wallet. The JazzCash API integration itself is not technically hard. The friction is in onboarding.

The onboarding reality

You will need a registered business — a sole proprietorship with an FBR NTN and a business bank account is usually the minimum. Expect to submit company documents, CNICs of directors, and a brief description of what you are selling. Approval is not instant; in our experience it runs anywhere from a couple of weeks to over a month depending on how clean your paperwork is and how responsive your assigned contact is. Budget for this calendar time before your launch date, not after.

The integration itself

Mechanically, JazzCash gives you a merchant ID, a password, and an integrity (hash) salt. You build a request payload, generate a secure hash (HMAC-SHA256) over the fields in a specific order, and either redirect the user to a hosted page or trigger a mobile-account (MWALLET) charge. Two things trip teams up:

  • Hash ordering. The secure hash must be computed over fields concatenated in the exact sequence their docs specify. One field out of order and every transaction silently fails verification. Test this against the sandbox before you touch production.
  • Server-side callback verification. Never trust the client-side success redirect. Always verify the response hash and reconcile the transaction status server-to-server before you mark an order paid. We have audited apps that fulfilled orders on a spoofable front-end redirect — do not be that app.

For a clean MVP-grade JazzCash integration with sandbox testing, callback verification, and reconciliation, plan for roughly PKR 120,000–250,000 of engineering, more if you need refunds, partial captures, and an admin reconciliation dashboard.

Easypaisa integration for your app

Easypaisa (Telenor Microfinance Bank) is the other wallet you will almost certainly want. Functionally it competes head-to-head with JazzCash, and many apps offer both so the user can pay from whichever wallet they already top up. The Easypaisa integration in your app follows a similar shape: merchant credentials, a hosted checkout or direct mobile-account flow, and a server-side confirmation step.

A few honest differences we have seen in the field:

  • Settlement and reconciliation cadence differs between providers. Confirm the exact T+ settlement window in writing during onboarding — it affects your cash flow and refund timelines, and the marketing brochure is not the contract.
  • Documentation maturity. Both providers’ docs have gotten better over the years, but you should still expect to email support and wait for a real human to unblock an edge case (especially around refunds and disputed transactions). Bake that latency into your timeline.
  • Failure UX matters more here than with cards. Wallet users abandon fast. If a charge hangs for 20 seconds with no feedback, they assume it failed and either retry (creating a double charge you must dedupe) or leave. Build idempotency keys and a clear pending state.

Offering both wallets roughly doubles the gateway work but rarely doubles the cost, because the architecture — a payment-provider abstraction layer in your backend — is shared. Build that abstraction once and adding the second wallet is mostly configuration and a new adapter.

Card payments: when you actually need them

Card acceptance in Pakistan typically goes through an aggregator that gives you a single integration covering Visa and Mastercard, 3-D Secure authentication, and sometimes wallets bundled in. You need cards if any of the following is true:

  • You sell subscriptions or anything recurring. Wallets are awkward for automated recurring billing; cards (with tokenization) are built for it.
  • A meaningful slice of your users are urban professionals or overseas Pakistanis who default to a card.
  • You want higher average order values — card users statistically spend more per transaction in our experience.

The tradeoffs

Card rails carry higher per-transaction fees than wallets and a heavier compliance posture (3-D Secure, fraud rules, chargeback handling). You will also see real-world decline rates on Pakistani cards — issuing banks decline cross-border or unusual transactions aggressively. Always show users a clear, retryable error and an alternative (wallet or COD) when a card declines, instead of dumping them at a dead end. That single UX decision recovers sales that would otherwise vanish.

Fees, friction, and integration effort compared

This is the comparison most posts dodge. Exact percentages change with your negotiated rate and volume, so treat these as honest ranges, not quotes — confirm current numbers directly with each provider before you commit.

  • Per-transaction fee: Wallets (JazzCash, Easypaisa) generally sit lower than card rails. Cards add scheme fees on top, so the effective percentage is higher. Negotiate — published rates are starting points, and volume moves them.
  • Approval friction: Wallets and aggregators both require a registered business, NTN, and bank account. Card aggregators sometimes ask for more, since they are exposing you to chargeback liability. The smoother your documentation, the faster you clear.
  • Integration effort: A single wallet is the lightest lift. A second wallet is incremental if you abstracted the first. A card aggregator is the heaviest because of 3-D Secure flows, tokenization for saved cards, and chargeback/dispute handling.
  • Recurring billing: Practical with cards via tokenization; clunky with wallets. If subscriptions are core, lead with cards.
  • User reach: Wallets win on mass-market reach; cards win on order value and recurring revenue.

The non-obvious lesson after years of this: the gateway fee is rarely your biggest cost. Failed-payment recovery, double-charge disputes, and reconciliation overhead cost more in support hours than the percentage points do. Spend your engineering budget on robust callbacks, idempotency, and a clean reconciliation view — not on shaving 0.2% off a fee.

Architecture: build the abstraction, not the integration

Whatever you start with, do not hard-code one provider into your checkout. Build a thin payment-service layer in your backend that exposes a provider-agnostic interface — initiate, verify, refund, webhook handler — and put each gateway behind an adapter. This is the single most valuable decision in any mobile app payment integration in Pakistan, because:

  1. You will add a second or third rail. Guaranteed. The abstraction makes that a one-week task instead of a refactor.
  2. Providers change credentials, endpoints, and hash rules. Isolating that change to one adapter saves you from regression-testing your whole checkout.
  3. Reconciliation and analytics become trivial when every payment flows through one normalized record, regardless of which gateway processed it.

Keep all secrets (salts, merchant passwords, API keys) server-side. The mobile app should never hold a gateway secret — a determined user can decompile your APK in minutes. The app initiates, your server signs and verifies. Non-negotiable.

Common mistakes we are hired to fix

  • Trusting the client redirect. Orders marked paid on a front-end success URL with no server-side verification. This is a refund-fraud invitation.
  • No idempotency. User taps pay twice on a slow connection, gets charged twice, opens a complaint, you lose trust. One idempotency key per checkout attempt fixes it.
  • Skipping the sandbox. Teams test in production with real money because the sandbox felt slow to set up. You will miss hash and callback bugs that only surface under real failure conditions.
  • Ignoring the failure path. Most of your engineering attention goes to the happy path, but in Pakistan the failure and pending paths are where revenue leaks. Design those first.
  • No reconciliation tooling. Without an admin view that matches gateway settlements to your orders, you will not catch missed or stuck payments until a customer complains.

Frequently Asked Questions

Do I need a registered company for JazzCash or Easypaisa integration?

Yes. Both wallet providers require a registered business, an FBR NTN, and a business bank account before they issue live merchant credentials. A sole proprietorship is usually enough to start. Have your documents clean and ready, because incomplete paperwork is the most common reason onboarding drags past a month.

How long does payment gateway integration take in Pakistan?

The engineering for a single wallet is often a week or two of focused work, but the calendar time is dominated by provider approval, which can run a few weeks to over a month. Card aggregator onboarding can take longer due to chargeback liability checks. Always start the paperwork before you start the code.

Should I offer JazzCash, Easypaisa, or both?

For a mass-market consumer app, offer both — many users hold only one wallet, and forcing them to the other costs you the sale. If you build a proper payment abstraction layer, adding the second wallet is incremental work, not a second full integration.

Can I do recurring subscription billing with mobile wallets?

It is awkward. Wallets are built for one-off charges, so automated recurring billing is fragile. If subscriptions are central to your product, lead with card payments and tokenization, then offer wallets for one-time top-ups or first payments.

What does in-app payment integration cost in Pakistan?

For a clean, MVP-grade single-gateway integration with sandbox testing, server-side verification, and reconciliation, budget roughly PKR 120,000–250,000. Multiple rails, refunds, saved cards, and an admin reconciliation dashboard push it higher. The bigger long-term cost is support and reconciliation, not the build.

Is cash on delivery still worth supporting?

For physical goods in Pakistan, yes — a large share of buyers still prefer COD, especially outside major metros. It is not a gateway, but treat it as a first-class payment method in your data model so order status, refunds, and reconciliation stay consistent across all methods.

Talk to One Source Soft about your app’s payments

If you are planning an online payment app in Pakistan and want the gateway architecture done right the first time — abstraction layer, server-side verification, idempotency, reconciliation, and the right rail order for your audience — we can help. We have been integrating JazzCash, Easypaisa, and card payments into Pakistani apps for years, and our public Google reviews reflect that track record. Start with a free consultation and audit of your payment flow: tell us your users, your model, and your timeline, and we will map the fastest path to collecting money cleanly.

See how we approach mobile app development, and get in touch for a no-obligation review of your payment integration plan.

Related reading

Keep reading