For a business comparing payment providers in Pakistan, the useful question is what happens between creating an order and knowing it has been paid. A wallet request still needs the customer’s approval. A voucher can remain unpaid. A bank payment may need to be matched to the right purchase. These differences affect when you release goods, restore inventory or investigate a missing confirmation.
Build your shortlist around the complete payment journey: customer action, payment confirmation, expiry, refund and merchant settlement. That gives you a stronger basis for comparing JazzCash, easypaisa and potential Raast P2M options than a list of supported names.
What our Pakistan sample tells us
Our review of the PayStar offer snapshot dated 14 September 2026 identified 64 unique offers linked exclusively to Pakistan. Of these, 36 were recorded as incoming and 28 as outgoing, and all 64 carried a PKR currency link.
This is a dated commercial sample, not a market census or confirmation of current availability. Country, currency and method links require qualification together. The sample helps structure provider questions; it does not establish that every listed method supports both collections and payouts for your company.
Compare the customer action behind wallet acceptance
JazzCash’s official gateway guide describes mobile-account checkout in which the customer enters a JazzCash number and approves the payment on their phone. It also describes a voucher flow where the customer pays a generated voucher before expiry. These are different completion journeys under the same payment brand. JazzCash payment gateway.
Easypaisa’s corporate portal separately presents an online gateway using easypaisa or an over-the-counter channel, payment collections, and bulk disbursement services. Treat those as distinct requirements when discussing an easypaisa payment gateway or PKR payouts. Easypaisa corporate solutions.
For each proposed option, ask the PSP to demonstrate the exact checkout your customers would receive. Record where approval happens, what an unpaid order looks like, and how the merchant receives a final result. An available wallet name is only the beginning of that comparison.
Qualify Raast P2M as a merchant workflow
Raast P2M adds a useful local distinction: merchant acceptance can involve several different ways of initiating payment. The official 1LINK catalogue describes its Raast P2M service with QR codes, aliases, IBAN and Request to Pay. 1LINK: Raast P2M service catalogue.
Use those modes to frame questions about an offered service. Ask which merchant modes the PSP actually provides, whether the selected mode carries your order reference, and where a pending request and a completed payment become distinguishable to your operations team. For Request to Pay, establish the expiry and refund workflow explicitly. A demonstration of a personal transfer does not answer these checkout questions.
Raast is official market context here, not a claim that the offers in our sample provide Raast acceptance. Obtain confirmation for the exact business, integration and merchant account before adding it to a launch plan.
Request evidence for five moments in the payment journey
| Moment | Evidence to request from the provider |
|---|---|
| Payment requested | The customer’s next action, the request identifier, and how the amount and order are associated. |
| Awaiting approval | The observable pending state, expiry rule and permitted status checks. |
| Payment completed | The authoritative confirmation, its timestamp and a way to retrieve the result after a missing notification. |
| Order cancelled or returned | The refund process, the connection to the original payment, partial-refund support and final refund evidence. |
| Merchant funds settled | A report matching transactions, fees, refunds and the amount credited to the agreed settlement account. |
Ask for a worked example covering all five moments. Documentation can describe the intended flow; a demonstration shows what your team will actually see. Record any manual steps and their owner before estimating the effort to launch.
Test a request that outlives the order
Consider a hypothetical order for PKR 12,000. Your store reserves inventory for ten minutes, while the proposed payment request remains payable for fifteen. A customer approves at minute twelve, after the store has released the stock.
These timings are illustrative, not published JazzCash, easypaisa or Raast limits. They expose a decision that the merchant and provider need to resolve: should the request expire with the inventory reservation, should stock remain reserved longer, or should a late payment enter an exception process?
Test that decision before launch. Also test a delayed payment notification and a repeated notification for the same transaction. Your team should be able to identify the original order, confirm whether money moved, and decide whether to fulfil or refund it. Sending another payment request while the first outcome is unknown can make the exception harder to resolve.
Compare PKR payouts on their own requirements
For outgoing payments, start with who receives the money and why: supplier, contractor, customer refund or another approved beneficiary. Confirm the destination account or wallet, beneficiary requirements, funding arrangements, limits, fees and evidence of completion with the PSP.
Keep a refund linked to its original collection wherever the agreed service supports that relationship. Do not assume an unrelated outbound transfer updates the original order or its refund record. Likewise, customer payment confirmation and settlement to your merchant account should have separate evidence and clearly agreed timing.
Build a Pakistan shortlist with PayStar Discovery
Bring your business activity, company registration country, customer checkout, expected PKR amounts and volumes, payout destinations and refund requirements to PayStar Discovery. We can help turn that brief into a focused PSP shortlist with the commercial, technical and operational questions needed to assess each option.
You choose the provider and contract directly with it. The PSP remains responsible for processing and settlement under that agreement. A useful shortlist makes the next validation step clear before integration begins.