Payment initiation in sandbox / test mode
A fee or subscription payment is started from the product's own flow using the provider's test mode. The pack never moves real money: live transactions are out of scope by design.
Section 23.2
Pakistan Payments (JazzCash / EasyPaisa) test pack
Local payment collection for Pakistani products — fee and subscription collection via JazzCash and EasyPaisa, exercised in sandbox / test mode only.
Many Pakistani web products collect money outside cards: school and madrasa fees, shop subscriptions and service charges are routinely paid through JazzCash and EasyPaisa. If that collection flow breaks — a callback that never lands, a payment recorded twice, a receipt that does not match the ledger — the product loses money or trust even while every screen looks fine. This pack exists to test that flow where a product actually offers it.
Applicability is decided per product, never assumed. For the POS / Retail profile the pack is NEEDS REVIEW: whether the pilot product offers JazzCash or EasyPaisa collection is undocumented in every source available to the platform, so the pack is neither assumed present nor assumed absent. For the Madrasah profile it is attached as a proposal, because fee collection through these rails is common in that category — its cases are created when the profile is first applied to a real product.
The checks in this pack
Success and failure callbacks are handled once, correctly
The provider's success callback marks the invoice paid exactly once; a failure or abandoned payment leaves it unpaid. A replayed callback must not double-record the payment.
Receipt and ledger entry match the payment
After a test-mode payment, the issued receipt and the accounting entry carry the same amount, payer and reference as the payment itself — the same reconciliation discipline the profiles require of fee records generally.
Interrupted payments recover cleanly
A payment abandoned mid-flow (closed wallet app, lost connection) must not leave the invoice half-paid or the payer charged without a record; the state afterwards is checked explicitly.
Status on each profile
| Profile | Status | Reason (from the profile definition) |
|---|---|---|
| POS / Retail | Needs review | NOT APPLICABLE-UNKNOWN: whether Dukaan AI offers JazzCash/EasyPaisa collection (for subscriptions or shop-level payments) is undocumented in every source available to the platform (discovery, walkthrough, public pages). The pack is neither assumed present nor assumed absent — it stays NEEDS REVIEW until product documentation or an authenticated inspection settles it. |
| Madrasah / Masjid / Maktab | Attached (proposed) | PROPOSED applicability: fee collection via JazzCash/EasyPaisa is common in this category, but no specific product has been validated — the pack attaches as a proposal and its cases are created (sandbox/test mode only, Section 23.2) when the profile is applied to a real product. |
Honest limits
No payment case in this pack has executed against a live product yet: on the POS profile the pack is NEEDS REVIEW, and on the Madrasah profile it is a proposal awaiting a first product. This page describes what the pack will check and why — it is not a claim that any product's JazzCash or EasyPaisa flow has been verified.
Pack checks run under the platform's standing safety rules: TEST-QA accounts and TEST-QA-marked data only, no real payments, credentials only through the secret store, and every result — pass, fail, blocked or needs-review — reported as it actually is. Read how the resulting evidence becomes a readiness score and coverage figure.