Pakistan: separating Raast, JazzCash and easypaisa transfers from merchant acquiring

“The order was paid to JazzCash” is not enough information for reconciliation. The customer may have made a transfer, paid through a merchant gateway or obtained a token to pay later. Similarly, Raast can appear inside another provider’s app. The brand on a phone is not the operation type, and the creation of payment instructions is not receipt of money.

Teams serving lawful Pakistani merchants should map functions: where the payment goes, who confirms the result, where the funds sit and how they are returned. Raast, JazzCash and easypaisa are discussed as significant available systems and services, without an unsupported popularity ranking.

Raast ID and a merchant alias solve different problems

SBP describes a P2P Raast ID as a mobile number linked to an account. Payments can address a registered ID or IBAN; sending does not require the sender’s own Raast ID. The individual-user FAQ specifies one ID linked to one account, with relinking available. That description covers domestic transfers and directs customers to their bank for applicable limits.

The operational implication is that a phone number cannot be treated as permanent proof of the destination bank account. Retain beneficiary verification and a snapshot of the instructions for each attempt. For goods or services collection, the onboarding file must explain why the chosen account and contract are appropriate. An employee’s personal alias does not become merchant infrastructure merely because checkout displays it.

Raast P2M supports QR, merchant aliases, IBAN and Request to Pay with immediate or later payment deadlines. SBP requires business due diligence and support for refund requests that the merchant can accept or reject, alongside prompt confirmation or rejection notifications. These are participant requirements, not proof that every bank has activated every function for your business. P2M circular.

Request to Pay asks for payment; it does not itself debit funds

Checkout should distinguish request creation, payer consent and financial outcome. Recommended internal fields include order ID, attempt ID, the provider’s request identifier, expiry, expected amount, beneficiary and final transaction reference. This is a suggested data model; your MSP determines the actual API field names.

Consider an illustrative case: a customer opens a Later request, then independently sends funds to the IBAN. Treating the two paths as separate orders can lead to duplicate payment and duplicate fulfilment. Establish a policy linking alternative attempts to one order. Handle a confirmed excess payment separately; do not silently absorb it into the customer’s next order or send it to an unrelated address supplied in chat.

JazzCash: preserve exact field meaning

The published gateway documentation uses a merchant-generated pp_TxnRefNo, pp_Amount without a decimal separator at the specified monetary scale, and PKR in pp_TxnCurrency. It also includes transaction timing and pp_SecureHash. Refunds reference the original transaction. This is a particular published interface version: reconcile it against your assigned production specification, including signature rules and status sequencing.

Amount scaling errors are particularly expensive. A PKR 100 test should check the buyer’s screen, request, response, report and bank entry. Copying a number between formats without checking can produce a hundredfold mismatch. Use an unambiguous internal amount representation and convert at the integration boundary, with separate tests for each API version.

JazzCash describes document review, biometrics, agreement signing and registration in the business’s name; its eligibility wording mentions CNIC and NTN. A consumer wallet does not substitute for these stages. Gateway methods include mobile accounts, cards and vouchers, so the JazzCash name alone does not identify the instrument funding a purchase.

easypaisa: a token is not a confirmed payment

The easypaisa merchant FAQ lists Mobile Account and OTC among gateway methods: OTC uses a token paid through the specified outlets and banking channels. Operations therefore need a distinct “awaiting token payment” state. Issuing the token must not credit the order. Obtain the expiry, repeat-payment behavior and final-status rules from your current integration specification.

easypaisa’s retailer-to-merchant terms separately describe a bank contract, use for lawful goods and services, assigned limits and corrective debits. This is a useful counterexample to “once the wallet receives it, nobody can touch it.” The document does not support unconditional irreversibility or transferring an agent’s permissions into merchant acceptance.

Where the real operational workload appears

A pilot must extend beyond successful payments. Leave a request unpaid, close the browser after authorization, test repeated notifications, query after a timeout and execute an approved refund. For every case, record who holds final confirmation and how an operator retrieves it at night. If support can see only the customer’s SMS, process reliability remains unproven.

Reconcile merchant settlement separately from customer payment. The contract should explain fees, deductions, available funds, the destination bank account and timing around non-working days. “Real-time” acceptance does not promise identical availability for every withdrawal. A refund against an original purchase and a new outgoing disbursement also need separate grounds and identifiers.

A payment-service licence does not license gambling

Pakistan Code contains specific gambling-prevention legislation. An overseas gambling licence and access to a regulated wallet therefore do not establish permission for that business in Pakistan. This technical review is not a route around restrictions. A commercial launch requires the applicable local legal basis and explicit acceptance of the business category by the servicing institution.

A sound integration can be explained in one sentence containing verifiable facts: who pays whom, through which product, on what basis, and which message confirms the outcome. If the explanation is merely “the local partner handles everything,” the risk has been hidden from the merchant rather than resolved.