整合积分红包话费流量，玩转多凭证支付流程
引言
现代支付系统中，单一的现金支付方式已经不能满足多变的业务营销场景，因此有了以各类非现金支付方式（积分、红包、话费、流量等）抵扣部分现金的需求，对产品经理进行支付流程与接口的设计提出了更高的要求。
本文主要提出一种多凭证支付的流程与接口设计方案，并考虑多凭证支付时的效率问题。
名词解释
为了方便读者在同一频道上沟通，先解释下列的名词。
- 现金支付：使用借记卡、信用卡或某宝某信的余额进行支付；
- 非现金支付： 使用积分、红包、话费、流量等等辅助方式进行现金抵扣；
- 多凭证支付： 同时存在现金支付及非现金支付（一种或多种）的组合支付方式。
![img_d13b56958b47b47c42964eae16006d49.jpe]()
原价100元的商品，使用 现金100元 支付，是为现金支付；也可以改为使用96元现金+1元红包+20积分+1元话费，是为多凭证支付，96元以外的部分称为非现金支付。
多凭证支付流程设计
进入正题，设计这个流程的最大挑战在于积分、红包、话费、流量等等凭证信息是分属于不同的系统，甚至是不同公司不同团队来开发与维护。
想要将这些系统整合成为支付系统的一部分，如何串联外部系统是个大问题，相信接到任务的同事已经死了不下二百个脑细胞。
分析
通过简单的分析能发现这个需求的要点，核心是要让现金支付与非现金支付的各个环节一齐成功，假如有某个环节失败，那么整个支付就应被判定为失败。与此同时，这些凭证信息又分布在各自的系统上。
等等！研发的同事笑了，这不就是一个典型分布式事务吗？对！我的思路就是参考分布式事务的设计思想来构建这个流程。
分布式事务思考
对于分布式事务，并不是本文所要描述的重点，各位前辈们早己为我们铺好了路，需要了解的可以查看以下连接。
漫画：什么是分布式事务？
聊聊分布式事务，再说说解决方案
微服务架构下分布式事务解决方案——阿里GTS
我们所要做的只是站在巨人的肩膀上去看问题。
两阶段提交（2PC）的支付流程
分布式事务最经典的模式莫过于两阶段提交（简称2PC）。其核心思想是先锁定资源，再提交变更。
运用两阶段提交的做法，可以将业务流程设计如下。
其过程可描述如下：
- 当用户提交支付请求以后，由事务管理器（这里其实是支付系统）锁定用户的各种非现金凭证资源，所有凭证资源锁定成功后，调起现金支付。
- 用户完成现金支付后，支付系统再向各个外部系统提交对各种支付凭证资源的变更操作。所有凭证系统返回变更成功后，支付被确认为成功。
- 在上面的过程中，任何锁定或提交失败，都认为支付失败，并归还被锁定的凭证资源，并回滚提交的变更。
以上的流程确保了的可用性和一致性，但存在重大的缺点：随着非现金支付凭证的增加，需要锁定的凭证越来越多，由于是外部系统，响应时长方面很难控制，造成用户提交支付请求后，等待跳转现金支付环节的时间越来越长，用户很容易失去耐心，造成支付半途而废。
根据TCC改进的流程
为了弥补上述缺点，参考金融系统常用的TCC机制（参考TCC型分布式事务原理和实现之：原理介绍），将流程略作改进，变成如下。
这里使用TCC机制的目的在于，将尝试资源操作和提交变更操作的驱动者分离，由不同的服务来执行。流程要点如下：
- 所有持有凭证资源的系统都必须实现Try，Confirm，Cancel三个功能接口。
- 用户在客户端上选择某个凭证时（比如勾选“使用积分支付”），此时立即使用Try接口锁定凭证资源。
- 用户点击“去支付”提交支付请求时，由于支付所需要的非现金凭证资源已经被成功锁定，可以立即进入现金支付的环节。
- 用户完成现金支付后，由支付系统提交所有凭证系统的Confirm接口，进行变更确认。由于Try阶段已经预留了资源，因此Confirm操作必然成功。
- 如果现金支付不成功或者用户超时未进行现金支付，则支付系统使用Cancel接口释放Try操作已锁定的凭证资源。
最终一致性保证
采用分布式事务不可避免的要面对各种不可预料的情况。作为支付系统，最终一致性是重中只重，因此，我们还需要通过每天对账确保各方系统最终一致。
设计回顾
综上，一个可落地的流程已经设计好了。简单回顾一下上述TCC流程，有以下优点：
- 各方系统可以保证最终一致性。
- TCC机制使得系统响应速度提升，用户平均等待时间变短，也降低了系统等待资源的开销。
- 此流程保留了较好的扩展性，理论上可以添加无数种非现金支付的凭证作为辅助支付手段。
当然，在具体实施过程中，以上的流程还需要有很多的机制需要完善与改进，比如需要为锁定的资源指定超时时间，又比如异步化处理提升效率，再比如要避免死锁设计等等。但这已经超出了产品设计的范畴， 所以本文也就到此为止了。
一点浅见，仅供参考，欢迎回复讨论。
