支付检查清单

支付是产品的收入命脉。一个按钮点下去钱没到账、订阅没生效、退款没处理——这些问题不会出现在演示里，却会在上线后集中爆发。

支付系统不同于其他功能模块：它同时涉及资金安全、合规要求、用户体验和财务对账，任何一环出问题都可能造成直接经济损失或法律风险。对于 AI 产品出海而言，还叠加了多币种、多税制、多支付方式的复杂性。

本章提供一套可直接使用的支付检查清单，覆盖支付集成、定价展示、退款处理、税务合规四个核心领域。每项检查都有明确的验收标准，适合在上线前、大版本更新前或接入新支付渠道时使用。

支付集成检查

支付集成是整个支付系统的地基。网关配置错误、Webhook 丢失、异常处理缺失——这些问题在开发环境可能完全暴露不出来，到了生产环境才开始制造麻烦。

网关配置

支付网关的集成质量直接决定支付成功率。以下是上线前必须逐项确认的配置清单：

检查项验收标准常见陷阱
API Key 环境隔离测试环境和生产环境使用不同的密钥对，生产密钥未出现在前端代码中开发时将测试密钥写死在代码里，上线后忘记替换
Webhook 端点配置生产环境的 Webhook URL 已注册到支付平台，且指向正确的后端地址Webhook 地址指向 staging 环境，导致生产事件丢失
签名验证每个 Webhook 请求都经过 HMAC-SHA256 签名校验，拒绝未签名或签名不匹配的请求跳过签名验证「先跑通再说」，上线后留下伪造事件的安全漏洞
幂等性处理同一笔支付事件重复推送时不会重复处理，使用 event_id 或 idempotency_key 做去重Webhook 重试导致同一用户被开通两次会员
超时与重试支付请求设置合理的超时时间（通常 30 秒），失败后有指数退避重试机制无超时设置导致请求挂起，用户看到无限 loading
多币种配置结算币种与展示币种正确映射，汇率更新机制已就位用户看到美元价格但扣款按欧元结算

Webhook 可靠性

Webhook 是支付平台通知你的系统「钱到了」的唯一可靠通道。它不可靠，整个支付状态就会和实际脱节。

关键检查点：

  • 事件覆盖：确认已订阅所有必要的 Webhook 事件类型。对于 SaaS 产品，至少包括 payment_intent.succeeded、payment_intent.payment_failed、customer.subscription.created、customer.subscription.updated、customer.subscription.deleted、invoice.paid、invoice.payment_failed。
  • 顺序处理：Webhook 事件的到达顺序不保证与发生顺序一致。处理逻辑不能依赖「先收到 A 再收到 B」的假设，必须根据事件自身的状态做幂等处理。
  • 失败重试：如果你的端点返回非 2xx 状态码，Stripe 会在最多 3 天内进行重试，重试间隔指数递增。确保你的端点在遇到临时错误（如数据库连接池满）时返回 5xx 触发重试，而不是返回 200 吞掉事件。
  • 延迟监控：建立 Webhook 到达延迟的监控告警。正常情况下事件应在几秒内到达，如果延迟超过 5 分钟就需要排查。

错误处理

支付流程中的错误处理不只是「弹个 Toast 告诉用户失败了」。需要区分可恢复错误和不可恢复错误，给用户明确的下一步指引。

错误类型处理方式示例
用户可修复提示具体原因，引导用户修改卡号无效、CVV 错误、余额不足
临时性故障自动重试或提示稍后再试网关超时、网络中断、服务维护
风控拒绝告知用户联系发卡行，不暴露风控细节3D Secure 验证失败、交易被银行拒绝
系统错误记录日志并告警，向用户展示通用错误信息内部服务异常、数据库写入失败

定价检查

定价是产品与用户之间的「价值契约」。展示错误、套餐对比混乱、升降级计算出错——这些问题的影响远超技术层面，直接损害用户信任。

价格展示

检查项验收标准风险说明
币种符号价格展示的币种符号与实际扣款币种一致展示 ¥ 但扣款 $，用户会认为被多收费
价格精度不同币种的精度正确：日元无小数、美元两位小数、巴第四位小数精度错误导致显示金额与实际扣款不符
含税/不含税明确标注价格是否含税。面向 B2C 通常含税展示，面向 B2B 通常不含税欧盟要求 B2C 价格必须含税，美国各州规则不同
周期标注月付/年付周期清晰标注，年付折扣的计算基准明确「省 20%」的基准是月付 × 12 还是其他算法
价格变更已有用户的价格变更提前通知，新价格生效前用户有机会取消Stripe 要求对涨价用户提前通知，否则可能触发争议

套餐对比

套餐页面是用户做购买决策的关键节点。对比表的清晰程度直接影响转化率。

检查要点：

  • 功能对齐：每个套餐包含的功能列表完整、准确，没有遗漏或重复。
  • 差异高亮：套餐之间的差异项有视觉上的区分，用户不需要逐行对比才能看出区别。
  • 推荐标识：如果有推荐套餐，推荐理由明确，不误导用户选择更贵的方案。
  • 移动端适配：套餐对比表在小屏幕上的展示方式经过专门设计，不是简单压缩。

升级降级逻辑

SaaS 产品的订阅升降级涉及按比例计费（proration）、功能变更生效时间、账单调整等复杂逻辑。

场景预期行为需要验证的点
月付升年付立即切换，剩余天数按比例抵扣抵扣金额计算是否正确，功能是否立即生效
高级降级基础当前周期结束后切换，或立即切换并退还差额降级后数据是否保留，超出限额的数据如何处理
中途取消当前周期结束后停止服务，不退还剩余费用取消后是否还能访问已生成的内容
试用期升级试用期立即结束，按升级后的套餐开始计费试用期剩余天数是否按比例折算

退款检查

退款是支付流程的「逆向通道」。多数团队在开发阶段不会投入足够精力在退款流程上，直到第一笔争议出现。

退款流程

检查项验收标准说明
退款入口管理后台可以按订单号或用户维度发起退款，支持全额和部分退款部分退款的金额不能超过原订单金额
退款审批退款操作需要至少一级审批，大额退款需要额外审批防止误操作或内部欺诈
退款通知退款成功后自动通知用户，说明退款金额、原因和到账时间减少客服咨询量
服务降级退款后对应的服务权限在合理时间内被收回全额退款应立即停止服务，部分退款按比例调整
退款时限明确退款的时效窗口（如付款后 30 天内可退），超出时限需特殊审批与支付平台的退款窗口保持一致

争议处理

争议（Dispute / Chargeback）是用户通过发卡行发起的强制退款。处理不当不仅损失资金，还会影响商户信誉评分。

关键准备：

  • 争议响应时效：收到争议通知后，通常有 7-21 天的时间提交证据。建立提醒机制，避免超期自动败诉。
  • 证据收集：保留用户使用产品的日志、登录记录、功能调用记录、同意条款的时间戳。这些是争议申诉的核心证据。
  • 争议率监控：Stripe 和 PayPal 对争议率有明确阈值（通常 1%）。超过阈值会被罚款甚至关闭账户。建立争议率的实时监控和预警。
  • 根因分析：每笔争议都应记录原因分类——「未收到商品」「未经授权」「与描述不符」——并定期分析，从产品层面减少争议发生。

退款记录

所有退款操作必须保留完整记录，包括：退款发起时间、发起人、退款金额、退款原因、审批人、退款状态、关联的原订单号。这些记录是财务对账和审计的基础。

税务检查

对于出海产品，税务合规的难度不亚于支付集成本身。不同国家/地区的税种、税率、申报周期差异巨大，且规则持续变化。

税率配置

检查项验收标准复杂度来源
税种识别明确目标市场适用的税种：VAT（欧盟）、GST（澳大利亚/印度/新加坡）、Sales Tax（美国）同一产品在不同国家可能适用不同税种
税率更新税率变更时系统能及时更新，不因旧税率产生错误账单各国税率每年都可能调整
B2B/B2C 区分B2B 交易可以适用反向征收机制（Reverse Charge），B2C 按消费者所在国税率征收需要验证买方的 VAT 号有效性
数字服务税确认目标市场是否对数字服务征收特别税（如印度的 Equalisation Levy）数字服务税与传统 VAT/GST 可能叠加
免税阈值了解各市场的免税阈值（如美国各州的 economic nexus threshold）低于阈值可能不需要注册和申报

发票生成

发票不仅是给用户的付款凭证，也是税务合规的必要文件。

发票必须包含的信息：

  • 卖方信息：公司名称、注册地址、税务登记号（如 EU VAT Number）
  • 买方信息：公司名称或个人用户标识、地址（B2B 需包含 VAT 号）
  • 交易明细：商品描述、数量、单价、适用税率、税额、总额
  • 发票编号：连续编号，不可重复，不可跳号
  • 日期信息：发票开具日期、服务提供日期

税务报表

定期生成税务报表用于申报和审计。报表应支持按国家/地区、税种、时间段筛选，并能导出为税务机关接受的格式。

如果使用 Stripe Tax 或 Paddle 等 Merchant of Record 方案，税款的计算、收集和申报由平台代为处理，但仍需定期核对平台报表与实际交易数据是否一致。

支付系统检查流程

以下流程图展示了支付系统上线前的完整检查路径：

适读画布 · 130%
Mermaid 流程图加载中...

实际案例

案例一：AI 写作工具的订阅升级事故

一个面向北美市场的 AI 写作工具在上线高级套餐时，升级逻辑存在缺陷：用户从月付基础版升级到年付高级版后，系统按年付全额扣款，没有将月付剩余天数按比例抵扣。

问题在上线两天后被用户发现并投诉。影响范围约 200 名用户，涉及金额差异从 3 美元到 15 美元不等。

根因是开发团队在测试升降级逻辑时，只验证了「同周期类型升降级」（月付升月付高级），没有覆盖「跨周期类型升降级」（月付升年付高级）的场景。

事后修复措施：

  • 修正了 proration 计算逻辑，确保跨周期升级正确抵扣
  • 为受影响用户自动发起差额退款
  • 在测试用例中补充了所有升降级组合场景

这个案例的教训是：升降级逻辑的测试矩阵必须覆盖所有周期类型的组合，不能只测「同级」场景。

案例二：欧洲市场的 VAT 合规整改

一个 AI 图像生成工具在欧盟市场销售半年后，收到税务顾问的合规警告：产品一直按爱尔兰的 23% VAT 税率对所有欧盟用户开票，但实际应根据用户所在国适用不同税率（德国 19%、法国 20%、卢森堡 17%）。

问题根源在于产品使用了固定税率配置，没有实现基于用户地理位置的动态税率计算。虽然爱尔兰是公司注册地，但欧盟 VAT 规则要求数字服务按消费者所在国征税（除非销售额低于特定阈值，可以使用 OSS 简化申报）。

整改措施：

  • 接入 Stripe Tax，实现基于用户 IP 和账单地址的动态税率计算
  • 对历史交易进行税务差异核算
  • 建立 VAT 号验证接口，对 B2B 用户适用反向征收
  • 每月生成按国家分拆的税务报表

这个案例说明：出海到欧盟市场的数字产品，VAT 不是一刀切，而是需要根据用户所在地动态适配。使用 Stripe Tax 等自动化工具可以大幅降低手动维护的复杂度和出错概率。

综合检查清单

以下清单分为 5 个类别，共 22 项检查。适合打印出来在每次上线前逐项勾选。

一、支付网关集成（5 项）

  • API Key 环境隔离，生产密钥未出现在前端代码或版本控制中
  • Webhook 端点已注册到支付平台生产环境，签名验证已启用
  • 所有必要的 Webhook 事件类型已订阅，事件处理逻辑经过幂等性测试
  • 支付请求设置了超时和重试机制，超时时间不超过 30 秒
  • 错误分类已实现：用户可修复错误、临时性故障、风控拒绝、系统错误分别处理

二、定价与展示（4 项）

  • 价格展示的币种、精度、含税状态与实际扣款一致
  • 套餐对比表功能列表完整准确，差异项有视觉高亮
  • 月付/年付切换逻辑正确，折扣计算基准明确
  • 升降级的 proration 计算经过所有周期组合的测试验证

三、退款与争议（4 项）

  • 退款流程可用：支持全额退款和部分退款，有审批机制
  • 退款后服务权限在合理时间内被收回
  • 争议响应流程已建立：提醒机制、证据收集、提交时限
  • 争议率监控已就位，超过阈值前能收到预警

四、税务合规（5 项）

  • 目标市场的适用税种已识别，税率配置正确且可动态更新
  • B2B/B2C 税务处理已区分，VAT 号验证接口可用
  • 发票模板包含法定必要信息，编号连续不重复
  • 税务报表可按国家/地区/税种/时间段生成
  • 免税阈值和申报周期已明确，不会因超阈值而未申报

五、安全与审计（4 项）

  • 支付相关操作有完整的审计日志，包括操作人、时间、金额、状态变更
  • PCI DSS 合规：信用卡数据不经过自己的服务器，使用 Token 化处理
  • 退款和争议记录至少保存 7 年，满足审计要求
  • 定期（至少每季度）核对支付平台报表与内部系统数据是否一致

参考资料