payment-platform-readiness

支付平台就绪

使用此技能，让应用商店、Web 结账、钱包、订阅、退款、争议、促销和权益系统中的支付可靠、合规、易于支持、可重放且有利于产品体验。

工作流

1. 确认支付渠道、产品类型、计费模式、提供商标识符、目录映射、权益语义、退款／争议政策、结算／费用模式、支持界面和对账负责人。
2. 阅读 references/payment-platform-patterns.md；如果涉及结算、财务结账或跨系统对账，则加载 references/billing-reconciliation-patterns.md。
3. 梳理目录、结账、收据／Webhook 处理、幂等账本写入、权益投影、退款／撤销／争议处理、支持更正、结算和对账。
4. 针对 Apple IAP、Google Play Billing、Stripe／Web 结账、钱包、促销／管理员发放、恢复购买、续订、退款、拒付和延迟事件，定义提供商特定的优先级规则。
5. 检查平台特定限制、沙盒／线上环境隔离、回退路径、客户沟通、财务结账和运营回滚。
6. 对于中断或积压，明确定义写入状态：已暂停、已隔离、已去重、按提供商生效时间排序、重放中、投影器已修复、财务已对账和已恢复。
7. 对于发票／税务／财务结账上线，将发票、税费、优惠券、贷项通知单、退款、争议、费用、结算、收入导出、权益、催缴和手动调整建模为独立事件，并为其指定负责人和异常队列。
8. 对于财务结账，为每项资金／税务／结算／收入检查明确数值容差、频率、负责人、源系统、异常队列和结账阻塞项。
9. 输出支付状态模型、账本架构、事件优先级规则、对账计划、支持工具、阻塞项、可观测性仪表板、回滚控制和上线检查清单。

不适用场景

• 如果主要决策涉及套餐、价格、价值指标或商业实验，请使用 saas-subscription-pricing。
• 如果主要权威来源是卖家／创作者收入、冻结款项、准备金和打款，请使用 marketplace-payouts-review。
• 对于无需重新设计支付平台的退款／拒付／恢复购买支持状态机，请使用 refund-and-support-flow-review。

来源核验

• 使用时从官方来源核验当前的 Apple、Google、钱包、支付处理商、税务、发票、结算和争议要求。
• 对于任何可能阻断资金流转或客户访问的要求，记录提供商、API／政策版本、司法管辖区、访问日期和来源 URL。
• 将记忆中的数值阈值、费用表、审核规则和平台政策视为未经核验，直至从权威来源重新查阅。

防护措施

• 不要仅凭客户端确认授予持久权益。
• 确保支付记录、权益状态和支持工单可相互对账。
• 不要利用支付方面的困惑来留住客户。
• 不要将退款、取消、撤销、争议、拒付、宽限、账单重试、恢复购买、促销和手动调整合并为一个通用状态。
• 不要静默修改权益；应追加更正账本事件并重放投影器。
• 不要让支持人员更改提供商的事实记录。支持更正必须经过角色权限控制、记录原因、在适当情况下设置有效期，并可审计。
• 没有费用、税务、结算、发票、退款、争议和权益对账证据时，不要上线支付功能。
• 只有每项发布门槛都明确列出测试样例、仪表板／警报、回滚或紧急停用开关路径、负责人和审批证据时，才可宣告该门槛已完成。
• 不要将 Webhook 重放描述为通用的队列清空操作；每种重放状态都必须明确所需证据、排序／幂等规则、退出门槛、死信处理、客户／支持影响和事件复盘材料。

输出格式

Payment surfaces:
Billing model:
Authority boundary:

Readiness matrix:
- Catalog:
- Checkout:
- Confirmation and ledger:
- Entitlement projection:
- Refund/revoke/dispute:
- Support/reconciliation:

Payment and entitlement state model:
- <state> -> <provider evidence, internal projection, customer access, support note>

Provider precedence rules:
- <Apple/Google/Stripe/promo/admin/restore event> -> <idempotency key, effective timestamp, ledger event, entitlement effect>

Reconciliation and finance close:
- <money/settlement/tax/fee/entitlement check> -> <source, cadence, owner, exception action>
- Close control table -> check, source systems, cadence, numeric tolerance, owner, exception queue, close blocker
- Explicit close events -> invoice_created / tax_calculated / coupon_applied / credit_note_issued / payment_succeeded_or_failed / refund_or_dispute / fee_recorded / settlement_received / revenue_exported / entitlement_granted_or_revoked / dunning_started_or_exhausted / manual_adjustment

Support-safe correction flow:
- <case> -> lookup keys (account_id, user_id, invoice_id, payment_intent/charge, subscription, entitlement_id, tax document, support_case_id), evidence, allowed action, approval, ledger event, customer message

Webhook outage replay flow:
- Use a table: state, owner, required evidence, ordering/idempotency rule, dead-letter handling, exit gate, customer/support impact
- Include incident review: provider timeline, retry/dead-letter metrics, projector diff, false-revoke/over-grant disposition, finance exceptions, control fix, approval artifact

Blockers:
- <blocker>

Observability and rollback controls:
- <dashboard/alert> -> <signal, threshold, owner, runbook>
- <rollback/kill switch> -> <scope, trigger, customer impact, recovery proof>

Release gates:
- <gate> -> <test fixture, dashboard/alert, rollback or kill switch, owner approval>