VPN支付接口与订阅系统应该如何设计？

先确定谁在销售和收款

支付系统设计的第一步不是选择SDK，而是确认销售主体、目标地区、商品说明、退款规则、账单名称和Merchant of Record。客户需要知道向谁购买，谁负责交付、退款和争议。

VPNDevelop默认提供技术集成，客户持有自己的商户或应用商店账号。若平台代商户收款再结算，责任和合规范围会明显扩大，需要单独评估。

用内部订单连接不同支付渠道

内部订单用于记录用户购买什么、金额、币种、套餐和有效期；渠道交易用于记录外部服务商的某次付款尝试。一次内部订单可能包含失败重试、支付方式切换、退款或争议。

因此不应只保存一个支付成功布尔值。订单、支付、订阅、退款和争议应各自保存状态、原始标识和时间，并通过明确的状态转换关联。

浏览器返回页面不是付款凭证

用户从收银台返回网站只代表前端流程到达某一步，不能证明资金已经最终确认。异步支付、网络中断和伪造请求都会使前端状态不可靠。

系统应在后台验证支付事件的签名、事件ID、对象、金额、币种和订单关联，处理成功后再向权益系统发出业务事件。

Webhook必须支持重复与乱序

支付服务商可能重复发送事件，不同事件也可能因重试而改变到达顺序。处理器需要保存事件ID、使用幂等键，并让重复执行得到相同结果。

回调入口应快速确认接收，把耗时业务放入队列；失败任务需要退避重试、告警和人工重放，但人工操作同样必须留下审计记录。

权益系统与支付状态分离

订阅状态描述渠道关系，权益状态描述用户当前可以使用的VPN能力。套餐可能包含有效期、设备数、流量、节点范围或功能，两者不能直接等同。

退款、拒付、取消续费和到期对权益的影响也不同。例如取消续费通常不应立即终止已付周期，而退款或确认争议可能需要按规则回收权益。

分别适配网站、Apple和Google

网站托管收银台、App Store自动续订和Google Play订阅具有不同的产品配置、交易标识、服务器通知、恢复购买和地区规则。可以统一内部模型，但不能丢失渠道差异。

应用商店政策会更新，外链和替代支付也可能按地区和资格变化。上线前应以目标地区的当前官方规则和实际开发者账号状态为准。

用异常路径完成验收

验收至少覆盖付款成功、付款失败、重复回调、回调乱序、延迟确认、续费失败、宽限期、取消、到期、退款、拒付和恢复购买。

同时检查密钥隔离、权限、日志脱敏、对账差异、告警、失败补偿和回滚。只有正常演示流程通过，不能证明支付系统可运营。

检查清单

• 明确销售主体、Merchant of Record、账单名称、退款和拒付责任
• 确认网站、Apple与Google各自适用的支付入口和销售地区
• 为内部订单、渠道交易、订阅、退款和争议设置独立标识
• 定义pending、processing、paid、failed、refunded和disputed等状态
• Webhook必须验签、保存事件ID、幂等处理并支持安全重试
• 只有后台确认的付款或有效订阅能够创建或延长权益
• 取消、到期、退款、拒付、宽限期和恢复购买有明确权益规则
• 测试密钥、生产密钥、回调密钥和操作权限相互隔离
• 客服、财务和技术能够查询订单、事件、权益和人工处理记录
• 对账、告警、失败补偿、密钥轮换和回滚流程已经演练

相关专题、服务与场景

参考资料

• App Review Guidelines：Payments 与 VPN AppsApple Developer
• Google Play Payments PolicyGoogle Play Console Help
• Understanding Google Play's VpnService policyGoogle Play Console Help
• Best Practices for Securing E-commercePCI Security Standards Council
• Receive events in your webhook endpointStripe Documentation
• Understand the merchant of recordStripe Documentation