Pay-Ins (Collections) - User Journey
Source: Simpaisa Operating Model v1.0, April 2026
1. Product Overview
Pay-Ins is Simpaisa’s core merchant-facing collections product. It enables global digital merchants to accept payments from consumers across Pakistan, Bangladesh, and Nepal using local payment rails - mobile wallets, bank transfers, and telco billing - without requiring international card infrastructure.
The product sits at the intersection of merchant onboarding, real-time payment orchestration, compliance screening, FX settlement, and treasury management. This document describes the complete user journey, from a merchant’s first interaction with Simpaisa through to live payment acceptance and ongoing operations.
2. Actors and Systems
| Actor / System |
Role |
| Merchant |
Business entity integrating Simpaisa to collect funds from end-consumers |
| End Consumer |
Individual initiating payment in PKR, BDT, or NPR via a local payment method |
| Simpaisa Merchant Portal |
Web UI for merchant onboarding, KYB submission, API key management, and transaction monitoring |
| Simpaisa API Gateway |
Entry point for payment initiation, status polling, and webhook delivery |
| Payment Orchestration Engine |
Routes transactions to the correct local operator based on corridor, method, and merchant configuration |
| Compliance Engine |
AML screening, sanctions checks, and velocity rule enforcement |
| FX and Settlement Engine |
Converts local currency received to merchant settlement currency (typically USD or AED) |
| Local Operator Partners |
JazzCash, Easypaisa, bKash, Nagad, eSewa, Khalti, and bank aggregators per market |
| KYB / Compliance Team |
Internal Simpaisa team conducting merchant due diligence and approval |
| Treasury Team |
Manages float positions, FX hedging, and settlement timing across corridors |
3. Journey Phases
Phase 1 - Discovery and Registration
| Step |
Actor |
Action |
System |
Output |
| 1.1 |
Merchant |
Contacts Simpaisa via website, referral, or BD team outreach |
CRM / BD pipeline |
Lead created in CRM |
| 1.2 |
Merchant |
Registers account on Merchant Portal (email, company name, country) |
Merchant Portal |
Account created in sandbox mode |
| 1.3 |
System |
Sends welcome email with verification link |
Notification service |
Email verified |
| 1.4 |
Merchant |
Explores sandbox documentation, test API credentials, and payment method catalogue |
Developer Portal / Docs |
Integration scoping begins |
Phase 2 - KYB and Compliance Onboarding
| Step |
Actor |
Action |
System |
Output |
| 2.1 |
Merchant |
Submits KYB form: company registration, UBOs, bank details, website, business category |
Merchant Portal / KYB module |
KYB record created; documents uploaded |
| 2.2 |
System |
Automated preliminary screening: sanctions lists, PEP checks, adverse media |
Compliance Engine |
Risk score assigned; flags raised if applicable |
| 2.3 |
KYB Team |
Manual review of submission; may request additional documents |
Compliance back-office |
Review status updated |
| 2.4 |
KYB Team |
Approves or rejects merchant; sets initial transaction limits and permitted corridors |
Compliance back-office |
Merchant status set to Approved or Rejected |
| 2.5 |
System |
Notifies merchant of outcome; if approved, unlocks production API credentials |
Notification service + Merchant Portal |
Production access granted |
Phase 3 - Technical Integration
| Step |
Actor |
Action |
System |
Output |
| 3.1 |
Merchant |
Retrieves production API key and webhook secret from Merchant Portal |
Merchant Portal |
Credentials in merchant’s system |
| 3.2 |
Merchant |
Integrates payment initiation API into checkout or payment flow |
Simpaisa API |
Integration code written |
| 3.3 |
Merchant |
Configures webhook endpoint to receive payment status events |
Merchant Portal + API |
Webhook registered |
| 3.4 |
Merchant |
Runs end-to-end test transactions in production using small amounts across target corridors |
Simpaisa API + local operators |
Integration validated |
| 3.5 |
Simpaisa Solutions Engineer |
Reviews integration, confirms webhook handling, signs off on go-live readiness |
Internal review |
Go-live approval granted |
Phase 4 - Payment Acceptance (Live Transaction Flow)
| Step |
Actor |
Action |
System |
Output |
| 4.1 |
Consumer |
Selects product/service on merchant’s platform; chooses local payment method at checkout |
Merchant platform |
Payment intent formed |
| 4.2 |
Merchant system |
Calls POST /v1/payments with amount, currency, method, and merchant reference |
Simpaisa API Gateway |
Payment session created; Simpaisa transaction ID returned |
| 4.3 |
System |
Compliance Engine screens transaction: AML rules, velocity limits, sanctions |
Compliance Engine |
Pass or block decision; flagged transactions queued for manual review |
| 4.4 |
System |
Orchestration Engine selects operator route: primary operator + fallback rules |
Payment Orchestration Engine |
Operator and channel confirmed |
| 4.5 |
System |
Simpaisa API returns payment redirect URL or deeplink for consumer’s wallet app |
Simpaisa API + Operator API |
Consumer redirected to payment screen |
| 4.6 |
Consumer |
Authenticates in wallet app (PIN, biometric); approves payment |
Local operator (e.g. JazzCash) |
Operator confirms or declines transaction |
| 4.7 |
System |
Operator callback received; Simpaisa updates transaction status to COMPLETED or FAILED |
Simpaisa API + transaction ledger |
Transaction record finalised |
| 4.8 |
System |
Webhook dispatched to merchant: payment.completed or payment.failed event |
Notification service |
Merchant order management updated |
Phase 5 - FX Conversion and Settlement
| Step |
Actor |
Action |
System |
Output |
| 5.1 |
System |
Completed transactions batched by corridor and operator for netting |
Settlement Engine |
Daily settlement batch formed |
| 5.2 |
Treasury Team |
Reviews FX rate for PKR/USD, BDT/USD, NPR/USD; approves or adjusts hedge |
Treasury system |
FX rate locked for settlement batch |
| 5.3 |
System |
Local currency funds received from operator; converted at locked FX rate |
FX and Settlement Engine |
USD/AED equivalent calculated |
| 5.4 |
System |
Simpaisa fee deducted; net settlement amount calculated per merchant |
Settlement Engine |
Settlement statement generated |
| 5.5 |
System |
Funds wired to merchant’s nominated bank account per agreed settlement cycle (T+1 or T+2) |
Banking rails / SWIFT |
Settlement complete; merchant notified |
| 5.6 |
Merchant |
Downloads settlement report and reconciles against internal records |
Merchant Portal |
Reconciliation complete |
4. Failure and Exception Paths
| Scenario |
Trigger |
System Response |
Merchant Impact |
| Operator timeout |
No callback within SLA window |
Auto-fallback to secondary operator; if all fail, transaction marked PENDING_REVIEW |
Webhook delayed; Simpaisa ops team alerted |
| Compliance block |
Transaction hits AML or sanctions rule |
Transaction frozen; compliance team notified; SAR filed if required |
Webhook: payment.blocked; merchant must not fulfil order |
| Consumer insufficient funds |
Operator returns decline code |
Transaction marked FAILED; no retry |
Webhook: payment.failed; consumer shown error |
| Duplicate payment |
Merchant sends duplicate reference |
Idempotency check returns original transaction result |
No double charge; original status returned |
| Webhook delivery failure |
Merchant endpoint unreachable |
Exponential backoff retry for 24 hours; merchant can poll GET /v1/payments/{id} |
Merchant must implement polling fallback |
| FX rate breach |
Rate moves beyond merchant’s agreed tolerance band |
Settlement paused; treasury team alerted; merchant notified |
Settlement delayed pending rate renegotiation |
5. SLAs and Key Metrics
| Metric |
Target |
Owner |
| Payment initiation API latency (p95) |
< 800 ms |
Engineering |
| End-to-end transaction confirmation (p95) |
< 45 seconds |
Engineering + Operators |
| Operator fallback trigger |
30 seconds with no response |
Engineering |
| Webhook delivery (first attempt) |
< 5 seconds post-confirmation |
Engineering |
| KYB review turnaround |
2 business days (standard); 5 days (enhanced due diligence) |
Compliance |
| Settlement cycle |
T+1 (default); T+2 (high-risk merchants) |
Treasury |
| Platform uptime |
99.9% monthly |
Engineering |
| Transaction success rate (per corridor) |
> 95% |
Engineering + Product |
6. Ongoing Operations
| Activity |
Frequency |
Owner |
| Transaction monitoring and alerts |
Real-time |
Engineering + Compliance |
| Operator reconciliation |
Daily |
Treasury + Engineering |
| Merchant settlement |
T+1 / T+2 |
Treasury |
| AML transaction review queue |
Daily (same-day SLA for high-risk flags) |
Compliance |
| Merchant periodic review (KYB refresh) |
Annual (or triggered by risk event) |
Compliance |
| Operator SLA review |
Monthly |
Product + Engineering |
| Corridor performance reporting |
Weekly |
Product + Data |