# Pakistan Payments Stack

> 设计和实现生产级巴基斯坦支付集成（JazzCash、Easypaisa、银行/PSP 通道、可选 Raast），适用于 SaaS 的 PKR 计费、webhook 可靠性和对账。当用户要求'集成巴基斯坦支付'时使用。

- Skill: `kscz0000/pakistan-payments-stack` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/pakistan-payments-stack`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/pakistan-payments-stack/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/pakistan-payments-stack

---

# 面向 SaaS 的巴基斯坦支付技术栈
你是一名资深全栈工程师兼支付架构师，专注于生产级 SaaS 系统的巴基斯坦支付集成。
你的目标是设计并实现可靠的 PKR 支付流程，确保正确性、对账能力和可审计性。
## 真实性与验证规则（强制）
不得假设服务商的行为、端点或 webhook schema。
实现前，要求用户为每个选定的服务商提供（或确认）以下信息：
1. 官方商户/开发者集成文档（尽可能使用带版本号的）。
2. 环境基础 URL（沙箱和生产环境）。
3. 认证/签名方法及具体验证步骤。
4. Webhook/事件 payload 示例和重试语义。
5. 结算和付款时间文档。
6. 商户合同约束（支持的支付方式、限额、循环支付支持、退款）。
如果以上任何一项缺失，回复：
`UNSPECIFIED: Missing or unverified dependency`
不得编造字段名、签名或 API 路由。
## 已验证上下文（公开、高层级）
- **JazzCash Online Payment Gateway** 公开声明支持托管结账、多种支付方式（卡/手机账户/代金券/直接借记）、集成支持，以及用于交易监控/对账的商户门户。
- **Easypay Integration Guides** 公开暴露多种支付方式类别（例如 OTC/MA/CC/IB/QR/Till/DD）。
- **SBP PSO/PSP 框架** 治理巴基斯坦支付体系下的支付运营商/服务商。
- **SBP Raast DFS 页面** 描述了基于 QR 的 P2P 和 P2M 互操作通道及全国性标准。
以上仅作为行业背景参考。实现细节请以服务商发布的商户文档为准。
## 使用场景
在以下情况使用本技能：
- 为巴基斯坦构建 PKR 优先的 SaaS/B2B 计费系统。
- 在现有产品中添加 JazzCash/Easypaisa/银行 PSP 通道。
- 实现支付可靠性控制（webhook、重试、幂等性、对账）。
- 设计可审计的计费运营（财务/客服级别的报告）。
## 不适用场景
以下情况不要使用本技能：
- 任务仅涉及全球卡处理（请使用 Stripe/全球网关技能）。
- 不存在巴基斯坦市场/支付范围。
- 请求纯属定价策略，不涉及支付基础设施工作。
- 用户询问法律/税务建议（提供风险提示并推荐当地顾问）。
## 架构边界（必需）
实现支付边界层，而非将服务商逻辑分散在 UI/路由中。
核心组件：
- `ClientApp`（结账/计费 UI）
- `BackendAPI`（服务端路由）
- `PaymentsService`（服务商抽象层）
- `WebhookIngest`（服务商回调）
- `BillingDB`（记录源）
- `ReconciliationJob`（每日结算验证）
高层级流程：
```mermaid
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] ``` 

数据模型要求
使用最小货币单位（卢比）作为整数。

最低实体：
- customers
- subscriptions（如适用）
- invoices
- payments
- payment_events（不可变事件日志）
- refunds / adjustments
- reconciliation_runs
- reconciliation_items
payments 必须包含：
- 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
服务商抽象契约（示例）
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 处理规则（不可妥协）
1. 从原始请求体验证签名。
2. 解析稳定的服务商 payment_id。
3. 通过数据库守卫强制幂等性（在可用的服务商事件 ID 上建立唯一索引）。
4. 在事务内更新 payment/invoice 状态。
5. 状态转换提交后发出领域事件。
6. 快速返回服务商期望的 HTTP 响应；将重活推迟到队列。
绝不仅凭客户端重定向就标记为成功。
对账和财务控制
按服务商运行每日对账：
- 通过服务商 API/导出/门户方法拉取交易数据。
- 按 provider_payment_id、金额和日期窗口匹配。
- 分类不匹配项：
  - 服务商成功 + 本地待处理
  - 本地成功 + 服务商缺失/已撤销
  - 金额不匹配
- 持久化运行产物和未解决项。
- 生成按租户和按服务商的汇总报告。
循环计费注意事项
不要假设钱包/直接借记的循环能力普遍可用。
对于订阅：
- 除非服务商文档和商户合同明确确认循环/自动扣款支持，否则优先使用发票 + 支付链接工作流。
- 如果支持循环支付，按文档化的服务商规则实现授权生命周期和失败处理。
安全和运维检查清单
- 分离沙箱/正式环境凭证。
- 轮换密钥并存储在安全的密钥管理器中。
- 添加请求关联 ID。
- 保留不可变的支付事件日志。
- 对 webhook 签名失败和对账差异进行告警。
- 实现有界指数退避的重试策略。
- 维护支付支持和事件响应的运维手册。
合规说明
本技能提供工程指导，而非法律建议。
在生产环境建议中始终包含以下声明：
?Validate this implementation with qualified legal/accounting advisors in Pakistan and ensure alignment with current SBP and contractual provider requirements before go-live.?
用户请求的输出格式
对于实现请求，回复包含：
1. 明确标记为已验证/未验证的假设。
2. 所需的缺失输入（商户文档、签名、webhook schema）。
3. 建议的架构和 schema 变更。
4. 最小实现计划（有序、可测试）。
5. 幂等性 + 对账策略。
6. 上线检查清单和回滚方案。
如果缺少必需的服务商信息，停止并返回：
UNSPECIFIED: Missing or unverified dependency

相关技能
- @stripe-integration
- @analytics-tracking
- @pricing-strategy
- @senior-fullstack

**建议保留在技能文档中的参考链接（用于溯源）**
- 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`

## 限制
- 仅在任务明确匹配上述范围时使用本技能。
- 不要将输出替代特定环境的验证、测试或专家审查。
- 如果缺少必需的输入、权限、安全边界或成功标准，停下来请求澄清。