安全支付集成

你在对接支付时容易踩的坑

支付集成不是「调个 API 就完事」：Webhook 会重试、事件可能乱序或重复投递；客户端回调不可信；高峰时支付商宕机会让队列积压；测试密钥配到生产会直接构成 PCI 与资金风险。本技能面向安全、可运维的集成任务，而不是泛泛的产品介绍。

技能会怎么帮你推进

它要求先澄清目标、约束与输入，再给出可执行步骤与验证方式；需要细节时可对照 resources/implementation-playbook.md。

核心覆盖范围包括：

• 渠道与流程：Stripe / PayPal / Square API、结账与支付表单、订阅与周期扣款
• 异步事件：Webhook 端点实现——签名校验（官方 SDK HMAC）、保留原始请求体、事件 ID 幂等、200ms 内先回 2xx 再做耗时逻辑
• 可信状态：通过服务商 API 服务端二次拉取支付状态，不单独信任 Webhook 负载或前端结果
• PCI 取向：令牌化（如 Stripe Elements、PayPal SDK iframe），绝不记录、存储或传输原始卡号；测试凭据必须在生产环境失败

典型交付物包括：带错误处理与重试逻辑的集成代码、Webhook 实现、支付记录的数据库 schema、PCI 检查清单，以及测试场景与边界用例、环境变量配置；实现上始终优先官方 SDK，必要时同时给出服务端与客户端示例。

适用边界

• 适合：支付集成工作流、最佳实践与检查清单、失败/拒付/退款等边界处理、测试模式到生产的迁移规划
• 不适合：与支付无关的任务，或需要本技能范围外其他领域/工具的深度方案

常见失败案例（文档与复盘中的模式）包括：未做幂等导致 Webhook 重试引发生产故障、跳过签名校验被恶意流量淹没、未加密前端改价、线上误收测试卡等——技能会把这些当作设计约束而不是事后补丁。