Integrate Pakistan Payment Gateways for SaaS

This skill acts as a senior full-stack engineer and payments architect focused on Pakistani payment integrations for production SaaS systems, designing reliable PKR payment flows with strong correctness, reconciliation, and auditability. It defines a payment boundary architecture (ClientApp, BackendAPI, PaymentsService provider abstraction, WebhookIngest, BillingDB, ReconciliationJob) with adapters for JazzCash, Easypaisa, bank/PSP gateways, and optionally Raast QR rails. It specifies a minimum data model (customers, subscriptions, invoices, payments, an immutable payment_events log, refunds/adjustments, reconciliation_runs/items) storing amounts as integer rupees, a TypeScript provider abstraction contract (CreatePaymentParams, CreatePaymentResult, PaymentsService), non-negotiable webhook handling rules (verify signature from raw body, enforce idempotency via a DB guard, update state inside a transaction, never mark succeeded from client redirect alone), and a daily reconciliation process that matches provider transactions by ID/amount/date and classifies mismatches.

Use it 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), or designing auditable billing operations for finance/support-grade reporting.

Do not use it for global card processing scope only - use a Stripe or global gateway skill instead. Do not use it when there is no Pakistan market/payment scope, when the request is purely pricing strategy with no payment infrastructure work, or when the user is asking for legal/tax advice (this skill flags risk and recommends local counsel, it does not provide legal advice itself). Critically, the skill must not assume provider behavior, endpoints, or webhook schemas, or fabricate field names, signatures, or API routes - before implementation it requires the user to supply or confirm official provider docs, environment URLs, auth/signature methods, webhook payload examples, and settlement timing for each selected provider; if any of these are missing, it returns UNSPECIFIED: Missing or unverified dependency rather than guessing. It also does not assume wallet/direct-debit recurring capability is universally available - for subscriptions it defaults to an invoice-and-pay-link workflow unless provider docs and the merchant contract explicitly confirm recurring/autopay support.

Input: the target PKR payment scenario, selected providers, and (required) official provider integration docs. Output: an assumptions list marked verified/unverified, missing-input requirements, proposed architecture and schema deltas, an ordered implementation plan, an idempotency/reconciliation strategy, and a go-live checklist with rollback plan.

export interface PaymentsService {
  createPayment(params: CreatePaymentParams): Promise<CreatePaymentResult>;
  verifyAndHandleWebhook(rawBody: string, headers: Record<string, string>): Promise<void>;
}

Designs adapters for JazzCash Online Payment Gateway, Easypaisa's Easypay integration guides, generic bank/PSP gateways, and SBP's Raast interoperable QR rails, referencing the SBP PSO/PSP regulatory framework as landscape context. Chains with @stripe-integration, @analytics-tracking, @pricing-strategy, and @senior-fullstack.

Engineering teams building or hardening PKR payment infrastructure for a Pakistani SaaS/B2B product, who need a correctness-first architecture with reconciliation and audit trails rather than ad hoc provider integration code.