Pakistan Payments Stack

When to Use This Skill

Use this skill when:

• Building PKR-first SaaS/B2B billing for Pakistan.
• Adding JazzCash/Easypaisa/bank-PSP rails to an existing product.
• Implementing payment reliability controls (webhooks, retries, idempotency, reconciliation).
• Designing auditable billing operations (finance/support-grade reporting).

Do Not Use This Skill When

Do not use this skill when:

• The task is only global card processing (use Stripe/global gateway skills).
• No Pakistan market/payment scope exists.
• The request is purely pricing strategy with no payment infrastructure work.
• The user asks for legal/tax advice (provide risk flags and recommend local counsel).

Architecture Boundary (Required)

Implement a payment boundary instead of scattering provider logic across UI/routes. Core components:

• ClientApp (checkout/billing UI)
• BackendAPI (server routes)
• PaymentsService (provider abstraction)
• WebhookIngest (provider callbacks)
• BillingDB (source of record)
• ReconciliationJob (daily settlement verification) High-level flow:

flowchart LR
  client[ClientApp] --> api[BackendAPI]
  api --> svc[PaymentsService]
  svc --> jazz[JazzCash Adapter]
  svc --> easy[Easypaisa Adapter]
  svc --> bank[Bank/PSP Adapter]
  svc --> raast[Raast/QR Adapter Optional]
  jazz --> hook[WebhookIngest]
  easy --> hook
  bank --> hook
  raast --> hook
  hook --> db[BillingDB]
  db --> recon[ReconciliationJob] ``` 

Data Model Requirements
Use smallest currency unit (Rupee) as integer.

Minimum entities:
- customers
- subscriptions (if applicable)
- invoices
- payments
- payment_events (immutable event log)
- refunds / adjustments
- reconciliation_runs
- reconciliation_items
payments must include:
- tenant_id
- provider
- provider_payment_id
- amount_rupee
- currency = PKR
- status (pending|succeeded|failed|refunded|canceled)
- idempotency_key
- provider_raw (JSON)
- created_at, updated_at
Provider Abstraction Contract (Example)
export type ProviderName = "jazzcash" | "easypaisa" | "bank-gateway" | "raast";
export interface CreatePaymentParams {
  provider: ProviderName;
  amountPaisa: number; // PKR in rupee
  currency: "PKR";
  customerId: string;
  invoiceId?: string;
  successUrl: string;
  failureUrl: string;
  metadata?: Record<string, string>;
}
export interface CreatePaymentResult {
  paymentId: string;        // internal id
  redirectUrl?: string;     // hosted flow
  deepLinkUrl?: string;     // app flow
  qrPayload?: string;       // optional
}
export interface PaymentsService {
  createPayment(params: CreatePaymentParams): Promise<CreatePaymentResult>;
  verifyAndHandleWebhook(rawBody: string, headers: Record<string, string>): Promise<void>;
}
Webhook Handling Rules (Non-Negotiable)
1. Verify signature from raw body.
2. Resolve stable provider_payment_id.
3. Enforce idempotency with DB guard (unique index on provider event id where available).
4. Update payment/invoice state inside a transaction.
5. Emit domain event after committed state transition.
6. Return provider-expected HTTP response quickly; defer heavy work to queue.
Never mark succeeded from client redirect alone.
Reconciliation and Finance Controls
Run daily reconciliation per provider:
- Pull transaction data via provider API/export/portal method.
- Match by provider_payment_id, amount, and date window.
- Classify mismatches:
  - provider success + local pending
  - local success + provider missing/reversed
  - amount mismatch
- Persist run artifacts and unresolved items.
- Generate per-tenant and per-provider summaries.
Recurring Billing Caveat
Do not assume wallet/direct-debit recurring capability is universally available.
For subscriptions:
- Prefer invoice + pay-link workflow unless provider docs and merchant contract explicitly confirm recurring/autopay support.
- If recurring is supported, implement mandate lifecycle and failure handling per documented provider rules.
Security and Operations Checklist
- Separate sandbox/live credentials.
- Rotate keys and store in secure secret manager.
- Add request correlation IDs.
- Keep immutable payment event logs.
- Alert on webhook signature failures and reconciliation deltas.
- Implement retry policy with bounded exponential backoff.
- Maintain runbooks for payment support and incident response.
Compliance Note
This skill provides engineering guidance, not legal advice.
Always include this line in production recommendations:
?Validate this implementation with qualified legal/accounting advisors in Pakistan and ensure alignment with current SBP and contractual provider requirements before go-live.?
Output Format for User Requests
For implementation requests, respond with:
1. Assumptions explicitly marked as verified/unverified.
2. Required missing inputs (merchant docs, signatures, webhook schema).
3. Proposed architecture and schema deltas.
4. Minimal implementation plan (ordered, testable).
5. Idempotency + reconciliation strategy.
6. Go-live checklist and rollback plan.
If required provider facts are missing, stop and return:
UNSPECIFIED: Missing or unverified dependency

Related Skills
- @stripe-integration
- @analytics-tracking
- @pricing-strategy
- @senior-fullstack

**Suggested references to keep in your skill docs (for provenance)**
- JazzCash OPG: `https://www.jazzcash.com.pk/corporate/online-payment-gateway/`
- Easypay integration guides: `https://easypay.easypaisa.com.pk/easypay-merchant/faces/pg/site/IntegrationGuides.jsf`
- SBP PSO/PSP: `https://www.sbp.org.pk/PS/PSOSP.htm`
- SBP Raast P2M/P2P: `https://www.sbp.org.pk/dfs/Raast-P2M.html`

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.