Pay-Outs (Disbursements) - User Journey
Source: Simpaisa Operating Model v1.0, April 2026
1. Product Overview
Simpaisa Pay-Outs enables global merchants, platforms, and financial institutions to disburse funds to consumers and counterparties across Pakistan, Bangladesh, and Nepal at scale. The product supports a wide range of use cases: merchant refunds, ride-hailing driver pay-outs (e.g. InDrive), gig economy earnings distribution (e.g. Cadana), insurance claim payments, digital lending disbursements, employee salary disbursements, and remittance last-mile delivery (e.g. dLocal, TerraPay, GCC Remit, Uniteller, VOOO, Muzz).
Pay-Outs operates on a fully prefunded model. All disbursements are settled against a merchant's pre-funded Simpaisa account. No credit is extended. Disbursements reach end-beneficiaries within seconds to minutes, depending on the corridor and instrument.
2. Key Personas
| Persona |
Who They Are |
Primary Goal |
| Global Merchant / Platform |
Ride-hailing, gig, e-commerce, lending platform with recipients in Pakistan, Bangladesh, Nepal |
Disburse earnings, refunds, or loan proceeds reliably at scale |
| Remittance Operator |
International MTOs (TerraPay, dLocal, GCC Remit, VOOO, Muzz) routing last-mile PKR/BDT/NPR |
Ensure fast, compliant last-mile delivery to beneficiary wallets or accounts |
| Finance / Treasury (Merchant Side) |
Finance lead managing prefunding, FX exposure, and reconciliation |
Maintain liquidity, reconcile disbursements, manage FX risk |
| API / Integration Developer |
Technical lead building the merchant's system integration with Simpaisa |
Integrate Pay-Outs API reliably, handle webhooks, manage errors gracefully |
| End Beneficiary |
Consumer receiving funds - driver, gig worker, loan recipient, refund recipient |
Receive correct amount, quickly, to preferred account or wallet |
3. User Journey Map
Phase 1: Merchant Onboarding and Integration
| Step |
Actor |
Action |
Simpaisa System |
Outcome |
| 1.1 |
Global Merchant |
Signs commercial agreement for Pay-Outs; specifies corridors (PKR, BDT, NPR), instruments (mobile wallet, bank), and expected volumes |
CRM records agreement; compliance team initiates KYB |
Commercial terms agreed, KYB triggered |
| 1.2 |
Compliance Team |
Completes KYB: reviews corporate docs, UBO structure, AML screening, sanctions check |
KYB platform (Sumsub or equivalent) processes documents; compliance team approves |
Merchant approved; account created in Simpaisa platform |
| 1.3 |
Integration Developer |
Receives sandbox credentials; integrates Pay-Outs REST API; implements webhook receiver for disbursement status callbacks |
Sandbox environment available; API docs accessible; test disbursements processed in simulation mode |
Integration complete; test disbursements validated |
| 1.4 |
Integration Developer |
Passes integration checklist: correct payload structure, HMAC webhook validation, idempotency key usage, error-handling paths |
Simpaisa integration team reviews test logs; signs off on go-live readiness |
Merchant cleared for production |
Phase 2: Prefunding and Account Management
| Step |
Actor |
Action |
Simpaisa System |
Outcome |
| 2.1 |
Finance (Merchant) |
Wires prefund amount in USD (or agreed settlement currency) to Simpaisa's designated bank account |
Treasury team verifies incoming wire; converts at agreed FX rate; credits merchant's Simpaisa wallet in local currency equivalent (PKR, BDT, NPR) |
Merchant wallet funded; ready for disbursements |
| 2.2 |
Finance (Merchant) |
Monitors wallet balance via Simpaisa merchant portal or balance API; sets low-balance alerts |
Portal shows real-time balance; low-balance threshold alerts sent via email/webhook when balance drops below configured level |
Finance team proactively tops up; no disbursement interruptions due to insufficient funds |
Phase 3: Disbursement Submission
| Step |
Actor |
Action |
Simpaisa System |
Outcome |
| 3.1 |
Merchant System (API) |
Submits disbursement request via POST /payouts with: beneficiary identifier (MSISDN, IBAN, or account number), amount, currency, corridor, instrument type, and unique idempotency key |
API gateway authenticates request (OAuth2 bearer token); validates payload schema; checks idempotency key for duplicate detection |
Request accepted (HTTP 202); transaction ID returned |
| 3.2 |
Simpaisa Platform |
Performs pre-disbursement checks: balance sufficiency, beneficiary validation (MSISDN active, account exists), AML transaction screening, sanctions list check |
Risk engine applies rules; AML screening via integrated provider; beneficiary validation against telco / bank directory |
Disbursement cleared or flagged for review |
| 3.3 |
Simpaisa Platform |
Deducts disbursement amount from merchant's prefunded wallet; routes payment instruction to the appropriate PSP / mobile money operator / bank rails |
Ledger debited atomically; payment instruction queued to corridor-specific processor (e.g. JazzCash/Easypaisa API for PKR mobile wallet, NIFT/RAAST for bank transfer) |
Funds in transit; transaction status: PROCESSING |
| 3.4 |
Corridor PSP / Mobile Operator |
Processes payment instruction; credits beneficiary's account or mobile wallet |
PSP sends callback to Simpaisa with status (SUCCESS/FAILED); Simpaisa updates transaction record |
Beneficiary receives funds; transaction status: COMPLETED |
| 3.5 |
Simpaisa Platform |
Sends webhook notification to merchant's registered endpoint with final status, transaction ID, timestamp, and corridor confirmation reference |
Webhook delivered with HMAC signature; retry logic applied if merchant endpoint unresponsive |
Merchant system updated with final disbursement status |
Phase 4: Batch Disbursements (High-Volume Flows)
| Step |
Actor |
Action |
Simpaisa System |
Outcome |
| 4.1 |
Merchant System (API) |
Submits batch file or bulk API call with up to 10,000 disbursement records; each record carries its own idempotency key |
Batch ingestion endpoint validates structure; deduplicates records; creates batch job with unique batch ID |
Batch accepted; batch ID returned for polling |
| 4.2 |
Simpaisa Platform |
Processes batch asynchronously: validates each record, checks aggregate balance sufficiency, routes individual payments to corridor processors |
Parallel processing across corridors; failed records isolated and flagged without halting successful records |
Batch progresses; per-record status tracked |
| 4.3 |
Merchant System (API) |
Polls batch status endpoint or receives batch completion webhook; downloads per-record results file |
Batch completion webhook fired when all records resolved; results file generated with per-record status, reference IDs, and failure codes |
Merchant reconciles batch; resubmits failed records if appropriate |
Phase 5: Error Handling and Failed Disbursements
| Failure Type |
Trigger |
System Response |
Merchant Action Required |
| Invalid Beneficiary |
MSISDN not registered with mobile operator; account number invalid |
Transaction rejected pre-disbursement; funds not debited; error code returned |
Correct beneficiary details and resubmit |
| Insufficient Balance |
Merchant wallet balance below disbursement amount |
Request rejected; 402 error returned; low-balance alert triggered |
Top up wallet; resubmit |
| AML / Sanctions Flag |
Beneficiary or transaction matches watchlist |
Transaction frozen; compliance team notified; case opened |
Await compliance resolution; do not resubmit without clearance |
| PSP / Corridor Failure |
Downstream PSP returns error or times out |
Simpaisa retries via alternate PSP if available; if unresolvable, transaction marked FAILED; funds returned to merchant wallet |
No action required; resubmit if needed |
| Velocity / Limit Breach |
Single transaction exceeds per-transaction or daily limit |
Transaction rejected; limit error returned |
Split into smaller transactions or request limit review with Simpaisa |
Phase 6: Reconciliation and Reporting
| Step |
Actor |
Action |
Simpaisa System |
Outcome |
| 6.1 |
Finance (Merchant) |
Downloads daily settlement report from portal or via reporting API; reconciles against internal disbursement records |
Settlement report generated at T+1; includes per-transaction status, amounts, fees, FX rates applied, and corridor references |
Finance team reconciles; discrepancies flagged |
| 6.2 |
Finance (Merchant) |
Reviews fee invoice from Simpaisa (per-transaction fees + FX margin); approves and processes payment |
Invoicing module generates monthly or agreed-cycle invoice; auto-deducted from prefunded balance or separate invoice |
Fee settlement completed |
4. Service-Level Expectations
| Metric |
Target |
| Mobile wallet disbursement speed (PKR) |
< 60 seconds (real-time) |
| Bank transfer speed (PKR/BDT/NPR) |
< 4 hours (RAAST/NEFT same-day) |
| API success rate |
> 99.5% |
| Batch processing time (10,000 records) |
< 30 minutes |
| Webhook delivery |
Within 30 seconds of status change; 3 retries with exponential backoff |
| Portal uptime |
99.9% monthly |
5. Compliance and Regulatory Touchpoints
| Requirement |
How Simpaisa Meets It |
| Merchant KYB |
Full KYB including UBO identification, corporate docs, and AML screening completed before onboarding |
| Transaction AML screening |
Every disbursement screened against sanctions lists (OFAC, UN, local) and AML rules in real time |
| SBP Reporting (Pakistan) |
Regulatory reporting to SBP for cross-border disbursements under Schedule II PSO/PSP licence conditions |
| BFIU Reporting (Bangladesh) |
Suspicious transaction reporting to Bangladesh Financial Intelligence Unit per BFIU guidelines |
| Data residency |
Beneficiary data stored in-country per applicable data protection requirements |
6. Key Differentiators
-
Multi-corridor in one integration: Pakistan, Bangladesh, and Nepal accessible via a single API and contract
-
Real-time mobile wallet disbursements: sub-60-second delivery to JazzCash, Easypaisa, bKash, and equivalent wallets
-
Fully prefunded, zero credit risk: no credit exposure for Simpaisa; predictable treasury model for merchants
-
Idempotent API design: safe to retry; prevents double payments in unstable network conditions
-
Compliance-native: AML and sanctions screening embedded in transaction flow, not bolted on
-
Regulatory coverage: operating under SBP, BFIU, and NRB-compliant frameworks in each corridor
7. Open Questions and Edge Cases
| Question / Edge Case |
Notes |
| Partial batch failure handling |
Confirm whether failed-record funds are immediately returned to merchant wallet or held pending merchant confirmation |
| FX rate lock-in timing |
Document exactly when FX rate is fixed: at prefunding, at batch submission, or at individual disbursement execution |
| NPR corridor readiness |
Nepal corridor is listed in scope - confirm live PSP partners and regulatory approvals are in place |
| Reversal / refund flow |
Define the process for reversing a completed disbursement (e.g. mistaken amount); SLA and regulatory implications |
| Beneficiary notification |
Confirm whether Simpaisa sends SMS/push notification to beneficiary on receipt, or whether this is merchant responsibility |