大家好，今天给大家分享一下，我们公司现在支付系统上的一些分享，主要是从早期的裸代扣时代变到协议支付时代的一些过程和兼容流程；最后再简单介绍一下，我们目前支付系统的业务架构的情况；
我之前整理了一下资料，所以接下来的分享，可能会比较格式化。。
一、概述
协议支付业务是为了概述满足不同业务需求，符合监管流程，在用户首次进行快捷支付或者代扣时，需要证明该银行卡为用户本人所有，所以需要通过第三方渠道或者银行对用户信息校验。
二、签约条件
签约条件(流程中兼容非协议支付渠道)： 商户通过第三方渠道鉴权接口提供用户四要素:姓名、身份证号(目前三方鉴权证件类型仅支持身份证)、 银行行卡号、银行行预留手机号信息。 鉴权时，向用户银行行预留手机下发短信，需根据渠道的是否绑卡和是否平台自发短信属性来判断，签约短信的下发方和验证方(本公司或第三方渠道或银行)。
三、代扣与协议支付
用户在支付时，先路由决策出渠道，然后根据渠道属性，判断是代扣渠道or快捷支付渠道。 若是快捷支付渠道，需要确认用户是否在渠道绑卡，若绑过卡则直接调用渠道做充值业务，若没有绑卡，则先走签约流程再做充值。
四、主要流程
接下来再介绍一下，我们目前接入协议支付的主要流程
协议支付鉴权申请流程：
鉴权确认流程：
接下来是支付申请流程（这个逻辑里面会包含协议支付必须鉴权的这个业务逻辑）：
支付确认：
最后，是我们目前整体的一个业务架构的情况：
我的分享结束。。。。比较快，大家先看下，有问题可以提出来~
本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
