用途：为巴基斯坦市场的 SaaS/B2B 产品设计并实现生产级 PKR 支付集成，涵盖 JazzCash、Easypaisa、银行/PSP 通道以及可选的 Raast/QR，重点是正确性、对账与可审计性。适用于构建 PKR 优先的计费、在现有产品中加入本地支付通道、实现 webhook 重试与幂等控制、以及面向财务和客服的可审计账单报表。纯全球卡处理（应使用 Stripe 等技能）、无巴基斯坦市场范围、或仅做定价策略而无关支付基础设施的场景不适用；法律/税务问题应标记风险并建议咨询当地专业人士。
主要能力：要求建立独立支付边界，而非把各通道逻辑散落到 UI 或路由中。核心组件包括客户端结账 UI、后端 API、PaymentsService 通道抽象、WebhookIngest 回调入口、作为唯一事实来源的 BillingDB，以及每日结算校验的 ReconciliationJob。数据模型要求以最小货币单位整数存储，至少含 customers、subscriptions、invoices、payments、payment_events（不可变事件日志）、refunds/adjustments、reconciliation_runs、reconciliation_items；payments 含 tenant_id、provider、provider_payment_id、amount_rupee、PKR、status、idempotency_key、provider_raw 与时间戳。提供 PaymentsService 接口示例，含 createPayment 与 verifyAndHandleWebhook。
使用方式：实现前必须先由用户提供或确认所选通道的官方商户/开发者文档、沙箱与生产 base URL、鉴权与签名方法及精确校验步骤、webhook 负载示例与重试语义、结算与出款时间文档、以及商户合同约束（支持方式、限额、循环扣款与退款）。缺失时须返回 UNSPECIFIED: Missing or unverified dependency，不得编造字段名、签名或 API 路由。Webhook 必须先从原始 body 验签、解析稳定的 provider_payment_id、用数据库唯一索引保证幂等、在事务内更新状态、提交后再发领域事件、快速返回通道期望的响应，且绝不能仅凭客户端跳转判定成功。
限制：资料仅给出 JazzCash 托管结账与商户门户、Easypaisa 多种支付方式分类、SBP PSO/PSP 框架与 Raast 互操作 QR 等高层背景，具体端点与字段以商户文档为准。循环扣款能力不可默认普遍可用，订阅宜优先采用账单加支付链接，除非文档与合同明确支持。技能提供工程指导而非法律意见，上线前需按提示由巴基斯坦合格法律/会计顾问验证并符合 SBP 与合同要求。具体价格、费率与平台支持细节暂未提供。