某站以二次元社区著称，15年开启了用户端商业化之路，主营收入来自番剧、直播打赏、游戏联运等，各个业务为了快速迭代，自行定制实现支付系统，随着业务的迭代，原有的支付系统维护成本高到难以扩展。下文称为老支付，改版后的支付称为新支付。
笔者 17年加入某站，作为技术人员，之前在支付系统的经验可谓寥寥，因此本文分享仅是个人针对改版过程的遇到的一些问题交流，难免有很多思考不完善处，请诸位专家们多多指点。

为什么要改版

老支付系统设计所有消费基于虚拟币 X币系统，用户的一次支付，在内部系统实际经历的是充值并消费过程，且虚拟余额系统、支付网关系统完全耦合在一个服务中，难以拆解，系统经常会出现充值但未消费等情况。总结一下老支付问题：

  1. 没有网关系统概念，新增支付渠道开发完全独立，成本高。
  2. 没有统一收银台概念，各业务自行开发收银台，支付系统迭代配置升级困难。
  3. 所有支付、消费通过 X 币结算，不适合电商、周边、游戏等业务。
  4. 业务接入需要同时注册业务与商品，类似 IAP, 支付商品注册，制约业务新增商品迭代。
  5. 系统组件陈旧、迭代升级困难

在此背景下，我们决定全新搭建一套全新的支付平台。

新支付聚合收银台设计

1. SDK 模式

为了统一支付体验，我们提供了三端收银台，业务直接调用收银台完成支付。采用类似支付宝的SDK,直接下单功能，业务服务端不直接与支付服务端交互。这与老支付不同，老支付恰巧采用的是预下单模式。

这么做，我们考虑的好处是，将下单的成本交给 SDK 来进行迭代。未来支付服务访问相关的优化都交给 SDK 来完成。 有个前提是，一旦业务接入并正常使用支付，未来的支付相关的迭代，让业务来配合一定是一个推动的过程。还不如一开始就完全收拢。

2. 流水单模型

一个业务订单对应多笔流水单，每笔流水单对应一笔渠道订单，一个业务订单同时只允许支付成功一次。聚合收银同时对接多个支付通道，意味着用户可能使用多个支付通道支付多次。为了降低业务关注成本，通过多支付退款，已支付成功不允许发起等方式保证一个业务订单只有一笔支付成功订单，业务无需关心通道情况。

遇到的一些问题以及处理方式

1. 回调延迟问题

三方渠道回调偶尔会因为线路抖动情况超时，比如支付宝，第一次回调失败，下一次通知在4 分钟后。对于业务来说，就算偶发的一例回调超时，用户基本都会来进行投诉。 在这里，我们做了三项工作，

  1. 联合支付宝排查了回调失败的原因，发现部署的部分 CDN节点有一定几率丢失请求。摘掉这些故障节点后，回调超时有明显的改善。
  2. 增加主动查询渠道功能。主动查询渠道存在个问题是，支付发起后并不知道用户是否真的在第三方完成了支付，所以需要不停的轮询渠道。这会造成时效性和性能的均衡问题。过于频繁的查询会给系统造成压力；过于稀疏的又无法保证时效性。我们的解决思路是，统计过去不同渠道用户发起支付后到支付完成的时间分布，在分布高的时间阶段密集查询，分布低的时间稀疏查询，进而在牺牲一定时效性的情况下达到一个时效与性能平衡。
  3. 一般支付渠道 SDK 会有个同步回调，在同步回调中访问后台直接查询渠道完成支付，这个大大提升了回调的时效，用户体验较好。

2. 基础设施稳定性差如何高可用

某站的基础设施是自建机房，出口和专线可用性只有 99.9%, 这给支付可用性带来了很大的挑战。我们采用了双机房，三出口容灾的方式，将用户实际感知可用性提高到了99.99% 以上。

片描述

3. 苹果 IAP 支付

虚拟类绕不过的坎是 IAP ，IAP 因为其特点有很多细坑。

老支付的掉单率奇高，新支付则对掉单做了特别的优化，取得的良好的效果。主要工作有

4. paypal

paypal 支付采用同步回调方式，部分用户会利用银行漏洞，比如某德国银行paypal 支付完成后， paypal 会返回验证成功，但子状态为 pending, 代表正在和银行沟通，老支付之前有个漏洞就是直接将 paypal 大状态作为是否支付成功依据，导致用户利用银行与 paypal 结算间隙撤回扣款申请造成的商户损失。

5. X币余额系统微服务化

新支付与老支付最大的一个区别是，新支付将余额系统独立剥离，作为支付网关的一个渠道，余额系统的两项指标，

  1. 多用户下的交易 qps,
  2. 单用户的交易 qps。

1 很容易做，2不容易，恰巧我们有单用户的场景，目前单用户最大能做到 50 qps, 更高的提升方案正在尝试。通过redis 缓存扣减，定时刷新进数据库，这存在redis 故障的风险。如果 redis故障，恰好变化的余额还未能同步进数据库。一方面提高 redis可用性，另外一方面每次记录日志和余额变动消息，一旦redis失效，我们将会迅速从日志和余额变动消息中恢复余额。带来的缺陷是 redis故障时无法支撑高 qps, 但考虑的 redis本身的可用性，我们觉得这个问题可以接受。

改版后话由于的支付经验非常有限，很多问题是在边摸索边解决的道路上前行，对于很多问题的考虑和思考都有很多欠缺，感谢老熊的公众号给予的指点。欢迎各位多多指正

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。