电商技术架构--支付模块的那些事

几年前，刚做电商的时候，我开始做支付模块，负责去集成第三方支付接口，集成的接口有：微信（分两种，一种扫码，一种直接支付），支付宝（现在也分两种），易宝（据说快黄了），快钱（相对支付宝微信费率低，但提现周期长），北京农商银行网上银行等。

支付流程基本一致，这里拿快钱支付流程为例：

流程详解： 
1、消费者选择商品，商品参数传递给send页面。

2、Send页面将请求提交到快钱。 

3、Send提交后，跳转到快钱银行列表页面，快钱测试环境的银行是模拟的银行，支付不需要用真实银行卡做测试。 

4、支付完毕后，快钱会将支付结果反馈给receive页面，该功能在send页面中的bgUrl参数设置的，该地址要求是外网能访问到的地址，不能是localhost地址，商户技术可以参考send页面所给的例子。 

5、receive页面接收到快钱支付结果后，商户先做业务逻辑处理，比如更新数据库。之后再通知快钱已经接收到支付结果。通知快钱接收到支付结果的功能由<result>标签实现，该标签的值一定要为1，表示商户接收到通知。如果该值不为1，快钱会不停的向该receive页面发送支付结果，所以要求商户只要接收到快钱的支付结果，不管交易结果是成功还是失败， <result>的值都要返回1。 6、receive页面接收到快钱支付结果后，会自动将参数传递给show页面并跳转到show页面，该功能是由receive页面中的<redirecturl>标签实现，该标签中的值便是show页面的地址。代码中的<redirecturl>标签已经赋值，商户需要根据自己的实际情况做修改。同样，show页面不能是localhost的本地地址。

 

刚开始做的时候只为实现，并未考虑高并发、响应速度等因素。所以在第一版网站上线不久出现以下问题：

1.用户支付成功，但订单还处于未支付状态。

2.由于用户第一次支付成功，但订单处于未支付，导致用户以为未支付成功，又支付了一次。

3.做了秒杀和团购功能后，导致第三方支付接口回调网站接口io阻塞。

仔细分析问题主要出在调用receive页面发送支付结果（调用网站接口，通知网站此订单已支付。）

同一时间，我个人在京东618买书的时候，发现我的订单我已支付成功，但订单状态仍然为未支付状态，过了大概半小时左右，支付状态变为已支付并显示开始打包。相对而言，我们的网站和京东比都存在1中的问题，而我们只做到了给第三方提供接口而未考虑到大并发情况下程序的响应问题，拿微信支付举例子，微信在支付成功后，回对网站的支付回调接口回调三次，如果三次都未响应则微信不去再次回调，所以导致上面的问题出现。京东之所以过了半小时左右还能把状态改回来，并不是因为他们的服务器牛B、带宽牛B，而是他们加入了电商必备的一件利器----消息中间件，后来我查了一下他们的消息中间件用的是activemq。

 

补救措施：

1.加入消息中间件activemq。（现在有好多优秀的消息中间件，apache的activemq，阿里的rocketmq等）

2.加入定时任务–负责调用第三方支付查询接口，验证未支付的订单是否支付成功，将已支付成功但未及时更改为已支付的订单更改为已支付（补刀）

措施1可以有效解决1、2、3的问题，当第三方支付回调网站接口，网站接口收到消息直接插入消息中间件同时返回给第三方支付接口结果。第三方支付回调一次就得到响应，就不会去回调第二次，也侧面减轻多次回调代理来的访问量过多问题。

措施2，主要为了做订单验证和平帐作用，最开始用的spring+quartz，可以设定执行时间，开始为1小时执行一次，后期稳定后，改为每天后半夜2点执行。

3.增加调用及接收第三方支付的消息日志功能（主要为了出问题时候的分析排查），因为有时候也有可能第三方支付服务器挂掉了就真的没回调咱的接口（易宝支付多次出现此情况，对此我表示很呵呵）