1. 代扣代缴协议

支付系统是任何公司开展业务的基本支撑能力。

毕竟没有支付就没有现金，但由于每家公司开展的业务和用户场景不同，所需的支付支持能力也不同。

从今天开始我会跟大家分享我这几年设计的支付产品。

另外支付的内容相对比较复杂，毕竟关系到账户、风控、金融，甚至国家宏观政策，所以我分享的每一篇文章，都是从日常生活场景出发，帮大家解读支付产品设计的每一个细节。

好啦，废话不多说，今天我将开启支付系统产品设计的第一讲——免密码支付。

我之前在一篇文章中提出，任何互联网产品的设计都可以在现实生活中找到多模型的映射，反之亦然。

在讲免密支付之前，我想问大家一个问题：你在拼多多买过东西吗？或者你开过腾讯视频VIP会员吗？

反正我已经开通了腾讯视频的VIP会员了，还有我在拼多多买东西，只要金额在200元以下（可调整），不用输入支付密码就可以下单，你这样合适吗，哈哈。

我们以用户在拼多多APP上开通免密支付为例，来说明整体业务。

在了解下面的内容之前，需要先明确的一件事就是，微信里的支付密码是用来做什么的？

顾名思义，支付密码用于验证用户身份。

无论是在支付环节，还是在其他场景运用，本质都是对用户身份的验证。

我经常讲，手机和电脑没有眼睛、没有大脑，无法依靠生物系统来识别用户，只能通过认证系统来识别。

你设置1，下次登录的时候验证1，如果完全匹配，那么手机或者电脑就会认为是同一个人。

基于这个前提，我们来看看下面的截图：

如果你还未开通免密支付，可以尝试进入拼多多APP个人中心->设置->免密支付设置，选择微信或者支付宝，点击立即开通，按照流程操作。

好的，那么激活之后，用户就可以在拼多多上成功支付，不需要输入支付密码，这是为什么呢？

在回答这个问题之前，我们先来看一个现实生活中的例子：

老蒋接到合肥车管所的电话，让他​​亲自回去办理车辆过户手续，但他出差了，没能赶到合肥当地的车管所，这时候该怎么办呢？

这时老蒋想到了，他跟老李关系不错，而且老李这几天也要回合肥，所以双方就签订了一份委托代理协议。

老蒋委托老李去合肥市车辆管理所办理过户手续，并把相关材料交给老李。

于是，老李回到了合肥，带着老蒋的所有委托协议和相关文件，给老蒋办理了车辆过户手续。

这就涉及到一个场景：车管所怎么认出李先生呢？明明是蒋先生来办理车辆过户的吧？

从车管所角度看，当老李将老蒋的相关文件以及签署好的授权协议递交给车管所时，就相当于老蒋来到了车管所。

虽然名义上是老李在处理此事，但实际上是老蒋在处理，因为老蒋与老李之间已经形成了具有法律效力的代理关系（协议）。

好，我们再理一下这里的关系，是不是因为老蒋委托了老李，所以老李才能代替老蒋办事，对吧？

所以我们将相同的场景模型映射到线上。

现在回答上面的问题，用户开通免密码支付后，不需要输入支付密码就可以完成订单付款扣款。

正常情况下，用户每次支付都需要输入支付密码，以确保是用户本人操作。但为什么开启免密码支付后就不需要输入密码了呢？

同样的原因，因为创建了委托协议，它取代了用户的支付密码。

因为用户已经授权拼多多（即商家）可以在没有通知用户的情况下，直接从用户绑定的账户中扣款。

既然不需要告知用户，就没必要再要求用户输入支付密码了，对吧？这才是无密码支付的本质原理？

OK，接下来我们来定义一下免密码支付：

免密支付：从某种意义上也可以称为扣费或收款服务（与之相对的是代付代发），字面意思就是代扣费用，其实质是扣费服务（以前叫委托扣费），委托别人代你扣费。

委托扣缴可以适用于定期扣缴或者事后扣缴的情形，以提高效率。

例如但不限于：

会员缴费、水电煤气缴费、黄钻绿钻增值服务、打车软件、无人停车场或高速公路过路费缴费、理财基金投资、信用卡还款、乐视VIP月扣费（就是开头提到的腾讯视频VIP会员）等等，都是用户授权商家进行委托扣费的场景。

现在我们再回想一下，拼多多开通免密支付需要签署授权协议吗？

如下图（只是你没注意到）：

上面右边的图已经说的很清楚了，你授权商家（这里的商家是拼多多）向财付通（这里的财付通就是微信支付）发出扣款指令。

财付通无需验证您的支付密码、短信状态等信息，直接从您的银行账户或微信账户中扣除商户指定的金额。

这个就是一个典型的用户授权给拼多多的案例，契合了前面说的老蒋授权老李的业务场景。

我们来看一下用户开通免密码支付的流程：

从上到下、从左到右：

现在我们进入本文的正题：如何设计一款抵扣产品：

我们以拼多多开放微信免密支付为例来说明。

直接借记流程的设计涉及三方：用户、商家和渠道（渠道可以是银行或第三方支付）。

需要提前准备一些条件：

首先需要获取渠道的扣款服务文件，也就是微信的扣款文件。

拼多多毕竟是接入了微信的服务，商家如果想使用腾讯微信的刷卡服务，还是要遵守微信的规则。

所以需要商户（拼多多）工作人员提前持你的营业执照、法定代表人证明到深圳腾讯公司申请，但现在可以通过线上申请办理签到（签到流程请参考微信开放平台，此处不再赘述）。

商家加入微信平台之后，微信会给商家（拼多多）发放一个账号，相当于你去银行开户，银行给你一张银行卡。

这个银行卡号就是你在银行开的账户，所以微信也会给拼多多开一个账户，这个账户就叫商户号（一般是8开头的数字）。

第二，申请一个“模板ID”。

包括商户编号，key等参数。

这些参数在后续流程中都会用到，所以需要提前向微信工作人员申请。

如果要连接支付宝，需要向阿里巴巴申请。

申请完微信相关参数之后，还需要获取微信的扣款接口文档（微信工作人员会提供），该文档也是网上公开的。

微信支付接入流程：.

微信协议签署及扣款接口文档：。

以上是完成产品设计的前提，作为产品经理，必须要会看接口文档。

完成上面的准备工作之后，就需要开始设计推演流程，这是重点。

在设计流程之前我们先明确几个系统角色，当然只是举例：

移动应用程序：用户注册直接支付服务的移动应用程序，或商户应用程序。

移动应用：一般是指移动应用程序对应的后台处理系统，需要实现支付相关的接口支付系统。

公司内部支付系统又称支付网关服务系统，连接移动应用端与第三方支付系统，封装了第三方支付系统的协议签署、合同解除、查询等接口；

渠道系统：第三方支付机构或者银行。

总体系统流程如下：

当然，每个公司的系统架构都不一样，这里只是举个例子，我们来看看微信需要哪些资料（参数）：

好的，上面两张图就是微信需要的文件素材，放到计算机世界里就是数据或者参数，上面图片都有解释，这里就不细说了。

需要细化的是这些参数如果给出错误的话该如何处理，我们来一一分析一下：

应用ID、商户ID、模板ID：这三个参数如果填错了会怎么样？不用说，交易肯定失败。

因为这个是需要提前申请的，就像你出国之前要办理护照一样，这个护照就是你的身份证。

如果拿到错误的护照或者假护照，就不能出国了，对吗？

回调通知URL：如果提供了错误的URL会发生什么？

我们先来看看微信是如何解释这个参数的：

回调通知URL为接收签名成功消息的回调通知地址，以http或者 开头，通知UR​​L必须外网可达，且不能携带参数。

那么问题来了，如果因为开发者或者电脑本身的原因导致地址错误，那么平台系统（什么是平台系统？请看上图）是收不到任何协议签署结果的通知或者返回的。

这样就会导致两边数据不一致（微信系统端签名成功，但是平台系统端签名失败），这时候该怎么办呢？

这时候就需要平台系统主动发起查询。

我们再看一下这张图片：

这张图清楚的表明了，外部（也就是拼多多）App在启动微信客户端发起合约之前，要先在后台调用预合约接口，完成预合约的发起，并获取到。

然后打开微信客户端，完成签名，返回App。

那么微信的要求是商户首先要获取一个预签名ID()，怎么获取呢？

我们试着画一个获取预签名ID的流程图：

好的，我们来思考一下这个过程，有什么问题吗？

接下来当商家也就是拼多多获取到预签约ID()。

接下来该怎么办？

拼多多APP需要跳转到微信客户端APP吗？这个过程该如何设计？

我们把上面的流程进一步细化，完整的签名流程如下：

这就是结局吗？当然不是。

我们的设计流程不只是为了开发，我们也为自己设计流程。

我问你一个问题，如果这个流程设计好了，产品经理怎么去追踪每个用户的签约情况？没有办法去追踪。

所以，请先考虑一下，不要急着继续阅读。

你怎么做呢？

我们为合约添加了几个状态值（已创建、进行中、合约成功、已过期、合约失败），以便跟踪和查询每个用户的合约签署过程。

有两个好处：

因此我们将上面的签名流程翻译如下。

通过此图将已签名的协议ID做成节点状态，方便后台查询和问题定位。

好的，到此为止，一个完整的签署协议的流程图已经设计好了。

好，我们看下面的流程图，跟上面的微信签名对比一下，有什么不同呢？

我们回到上面的问题，如果因为开发者或者计算机程序本身的原因导致参数有误，平台系统将收不到通知，也无法返回协议签署的结果，这样就会导致双方数据不一致（微信系统端签署成功，但平台系统端签署失败）。

这时候我应该做什么呢？

OK，要主动发起查询，我们来看一下微信需要哪些参数：

说白了，微信需要三个关键参数：商户号、协议号、应用ID，那流程该如何设计呢？

以上流程是在渠道方未返回或者平台方未收到任何签约结果时，平台方主动发起协议号签约查询的流程图。

好的，上面介绍了一个用户签名并查询从商户APP发起的免密码支付或直接扣款的流程图，这里面也涉及到支付流程中常见的幂等性原理，这里就不详细讨论了。

合同签好了，接下来就是付款。

那流程该怎么设计呢？首先我们来看微信扣款接口文档：

2. 保留设计

之前有讲过注册支付产品收取费用的流程，对应的，当用户开启免密码支付后，就可以不需要支付密码就可以完成订单支付，整个流程应该如何设计呢？

同样的，我们还需要先预设几个系统角色：

那么，用户签署直接付款协议之后，按照之前的接口文档，渠道会返回一份签署好的协议，公司内部支付平台需要及时记录这个ID；

然后我们在上一篇文章中提到，它相当于老蒋授权给老李的一个委托协议，为了方便问题定位，更好的完成产品设计和后端查询业务的可视化，增加了协议号的创建、处理、签约失败、签约成功、过期、终止签约等不同的状态节点（过期状态是必须的，拼多多在和微信签订业务合作协议时，需要明确签约之后协议的有效期，可以是一年也可以是三年）；

以下是示例流程图（需根据公司实际系统架构灵活调整）。

3. 平台系统终止（扣留终止）

首先我们来看一下合同解除的业务场景，如下图所示：

上面两张截图是拼多多端用户的截图，上图是微信端的截图。也就是说，用户可以在拼多多端关闭免密服务，也可以在微信端关闭免密服务。那么这个流程应该如何设计呢？

直接上图：通道侧终止：

平台端终止流程：

好了，签约、扣款、平台方解约、渠道方解约的流程已经推送完毕，我们再来思考一个场景，就是用户平时付款的时候，会签名（开通）免密支付，也就是付款签约的场景，这个流程应该怎么设计呢？还是先看微信接口文档：