快捷支付 / 协议支付 交易流程设计

背景

（本文所站的角度是第三方支付机构）
之前做过的支付类的快捷交易，各个银行开出的接口都不尽相同（包括签约和支付），有的需要 1 支完成（我们称之为签约确认/支付确认），有的需要 2 支完成（签约申请 + 签约确认/支付申请 + 支付确认），有的则需要 3 支完成（签约申请 + 签约短信 + 签约确认/支付申请 + 支付短信 + 支付确认）。

设计

以下所说的几支均是针对和银行侧的交互。
在签约和支付过程中，肯定少不了短信验证，那么在银行侧开的接口不同的时候怎么做到短信验证的呢？通过一个字段 smsSendState 来控制前端系统的发送短信是通过支付机构发送还是银行发送。
该字段取值如下：

一支完成

这种情况是将签约信息/支付信息一次性送至银行完成协议签约/扣款的动作，这种情况可能有些不安全，就需要支付机构来确保交易的安全性。

流程图

可以看到以下流程图只和银行有一次交互。

二支完成

这两支分别是申请 + 确认（一般签约申请交易也可以称之为身份认证，签约确认交易称之为签约），之所以这边分两支交易，就是通过确认交易上送验证码至银行（验证码为银行端发送），这种模式也是最多的，大多数银行都会用这种方式。

流程图

如下流程图就能看出来，支付机构和银行进行了两次交互

三支完成

三支交易的情况比较少，申请一次，驱动银行发送短信码一次，最终将银行短信验证码上送再一次，支付机构总共和银行有三次交互。

流程图

这种模式最为复杂，有三次交互。

总结

不管哪种方式都是为了支付安全着想，我所在的部门正好的整个公司最后端的系统，对这种差异化进行了屏蔽，通过字段进行控制整个流程，开给前端系统统一的三支交易（申请，短信，确认），其中申请和确认是必送的两支交易，通过申请的返回字段决定是否上送短信交易，整个快捷支付的流程大体就是这样吧。