编辑导语：支付体系对于任何一家公司开展业务都是一项基础支撑能力。但每家公司开展的业务和用户场景都不同，因此所需要的支付支撑能力也不同。支付产品的设计设计非常多的步骤，今天我们来看支付产品设计的其中一道程序——代扣签约，我们一起来看看吧。

支付体系对于任何一家公司开展业务都是一项基础支撑能力。

毕竟没有支付就没有现金，但因每家公司开展的业务和用户场景不一样，所以需要的支付支撑能力也不一样。

从今天开始，我将结合过去几年设计过的支付产品来给大家做个分享。

另外因支付的内容相对比较复杂，毕竟这玩意跟账户、跟风控、跟财务，甚至跟国家的宏观政策都有关，所以每一篇分享的内容，我都是从日常的生活场景出发，帮你诠释支付产品设计的每个细节。

好，废话不多说，今天推出支付体系产品设计的第一讲-免密支付。

我之前在文章中提出，任何互联网产品的设计都能在现实生活中找多模型映射，反过来也是一样。

那么在讲免密支付之前，同样，先来问大家一个问题：大家有没有在拼多多上买过东西？或者有没有开通腾讯视频VIP会员服务？

反正我是开通过腾讯视频VIP会员的，另外在拼多多上买东西，只要金额在200元以下（可以调整）都是不用输入支付密码就能下单的，你们是不是，哈哈。

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

在理解下文内容之前，有一点需要提前明确的是，微信里面的支付密码是用来做什么的？

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

不管是在支付的过程还是用于其他场景本质都是校验用户身份。

我之前经常提到，手机、计算机没有眼睛没有大脑，它没办法去靠生物系统去识别用户，所以只能通过认证系统去识别。

你设置了1，下次再登录，校验一下1，完全吻合，那么对于手机或者计算机，它就认为是同一个人。

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

如果你们没有开通免密支付，可以尝试进入拼多多APP的个人中心->设置->免密支付设置，选择微信或者支付宝，点击立即开通，走一遍流程。

好了，那么开通之后用户就可以拼多多上买东西的时候不用输入支付密码就能支付成功了，这是为什么？

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

老江接到合肥车管所电话，需要自己亲自回去办理车辆过户手续，但因自己出差在外地，无法赶到合肥当地车管所，这个时候怎么解决？

这个时候老江就想到了，自己和老李关系比较好，又赶在老李最近几天要回合肥，然后双方签署了一份委托协议。

老江委托老李去到合肥车管所办理过户手续，并且把相关的材料给老李。

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

这里面就涉及到一个场景，车管所是怎么认可老李的，明明是老江要去办理车辆过户是不是？

从车管所的角度来看，老李将老江的相关证件和签署的委托协议递交给车管所，那么车管所就等同于是老江到了车管所的现场。

虽然名义上是老李在办理，但实质上依然是老江在办理，因为老江和老李之间形成了具有法律效应的委托关系（协议）。

好，这个里面的关系，我们再来捋一捋，是因为老江委托了老李，老李才能代理老江去办理，对不对？

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

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

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

同样的道理也是因为产生了委托协议，这份委托协议就代替了用户的支付密码。

因为用户已经委托许可了拼多多（商户）直接在用户绑定的账户里面扣钱而不用告知用户。

既然都不用告知用户，固然就没必要让用户输入支付密码，对不对，这就是免密支付的本质原理？

好，接下来，我们来给免密支付下个定义：

免密支付：某种意义上也可以称之为代扣或者代收服务（与之相反的是代付代发），从字面意义上理解是代为扣费，本质上就是扣费服务（原名委托代扣），委托他人代为扣费。

委托代扣可应用于定期扣款或需事后扣款以期提高效率的场景。

例如但不限于：

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

现在我们再来回想下，你在拼多多上开通免密支付是不是要签署委托协议。

如下图（只不过你没注意罢了）：

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

财付通在不验证您的支付密码、短信动态吗等信息的情况下直接从您的银行账户或者微信账户中扣划商户指定的款项。

这个就是典型的用户授权拼多多，符合前文讲的老江授权老李的场景业务。

我们再来看下用户开通免密支付的过程：

自上到下，从左到右：

第1个界面：在拼多多的免密支付设置界面（下文统一为：商户或商户的移动应用）；第2个界面：从第1个界面：跳转到微信（下文统一为：渠道）；第3个界面：微信输入支付密码界面；第4、5个界面：开通成功界面；第6个界面：回跳至拼多多的界面，更新开通状态。

下面我们进入本篇文章的正题，代扣产品怎么设计：

我们还是以拼多多开通微信的免密支付为例来说明。

代扣流程的设计涉及到三方：用户、商户、渠道（渠道可以是银行也可以是第三方支付）。

有些条件需要提前准备：

第一，要拿到渠道的代扣服务文档，也就是微信的代扣文档。

毕竟拼多多接的是微信服务，商户要想使用腾讯微信的代扣服务，还是要按照人家微信的规矩来。

所以商户（拼多多）的工作人员需要提前带着你的营业执照、法人代表的证件到深圳腾讯公司去申请，只不过现在都可以线上申请入住了（入住流程请查阅微信开放平台，这里不在描述）。

当商户入住微信平台之后，微信会给商户（拼多多）颁发一个账号，等同于你去银行开户的时候银行给你一张银行卡一样。

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

第二，申请“模版ID”。

包括appId、商户号、密钥等参数。

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

如果接入的是支付宝，就需要向阿里巴巴申请。

把微信的相关参数申请下来之后，还要拿到微信的代扣接口文档（微信那边的工作人员会提供），网上也有公开的。

微信支付接入流程：https://pay.weixin.qq.com/wiki/doc/api/wxpay_v2/papay/chapter2_6.shtml。

微信协议签约和扣费接口文档：https://pay.weixin.qq.com/wiki/doc/api/wxpay_v2/papay/chapter1_1.shtml。

以上是完成产品设计的前提条件，作为产品经理要会阅读接口文档。

以上准备工作完成之后就需要着手开始设计代扣的流程，这个是重点。

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

移动应用：用户签约代扣业务的移动APP，或商户APP。

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

公司内部支付系统，又称支付网关服务系统，连接移动应用server 端和第三方支付系统，对第三方支付系统协议签约、解约、查询等接口进行封装；

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

大概的系统流程如下：

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

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

我们需要提炼的是这些参数如果给错了，怎么处理，我们一个一个的来分析：

应用ID、商户号、模板id：这三个参数如果给错了会有什么结果？不用说交易肯定会失败。

因为这个都是提前申请的，就像你去国外之前要办理护照一样，这个护照就是你的证件。

如果你拿了一个错的护照或者假的护照，也是去不了国外的，对不对。

回调通知url：这个如果提供错了，会怎么样？

我们首先看看，这个参数人家微信那边是怎么解释的：

回调通知url是用于接收签约成功消息的回调通知地址，以http或https开头，通知url必须为外网可访问的url，不能携带参数。

那么问题来了，如果这个地址因为开发人员或者因为计算机本身的原因搞错了，那么就会导致平台系统（什么是平台系统？请看上面的图）收不到协议签约结果的通知或 。

就会导致两边的数据不一致（微信系统那边签约成功，而平台系统的签约失败），这个时候怎么办？

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

我们再来看看这张图：

这张图中，明确说明外部（也就是拼多多）App拉起微信客户端发起签约前，需先后台调用预签约接口完成预签约，获取pre_entrustweb_id。

再拉起微信客户端，完成签约， App。

所以微信的要求是商户先拿到预签约ID（pre_entrustweb_id），怎么拿呢？

我们来尝试画下预签约ID获取的流程图：

好，思考下这个流程有没有问题？

接下来，当商户也就是拼多多拿到这个预签约ID（pre_entrustweb_id）了。

接下来，怎么处理？

拼多多APP是不是要跳转微信客户端APP，这个流程怎么设计？

我们把上面的流程再进一步细化一下，完成的签约流程如下图：

到此是不是就结束了？当然不是。

我们设计流程不是单纯的为开发设计流程，还要为自己设计流程。

我来问大家一个问题，如果这个流程设计结束了，产品经理怎么跟踪每个用户签约的签约状态，没法跟踪吧。

所以呢，你先思考，不要着急往下看。

你怎么做呢？

我们给签约增加几个状态值（已创建、处理中、签约成功、已过期、签约失败），用于跟踪和查询每个用户签约的过程。

有两点好处：

每笔签约都有过程节点，方便在出现问题的时候能迅速定位问题；针对所有签约免密支付的用户我能通过直观的原型设计展现签约记录。

所以我们再把上面的签约流程翻译一下，如下图。

通过这个图，把签约的协议ID做成节点状态，方便后台查询和问题定位。

好了，到此为止，一个完整的签约协议的流程图就设计完毕。

好了，再看下面的流程图，对比上面微信签约，有什么区别？

再回到上面的问题，如果因开发人员或者因为计算机本身程序的原因搞错参数了，导致平台系统收不到协议签约结果的通知或 ，就会导致两边的数据不一致（微信系统那边签约成功，而平台系统的签约失败）。

这个时候怎么办？

好，要主动发起查询，查询的接口，我们再来看下微信需要的参数：

说白了，微信需要的是商户号、协议号、应用ID三个关键性的参数，流程怎么设计？

上面的流程是针对当渠道侧没有 或者平台侧未接收到任何签约结果，平台侧主动发起协议号签约查询的流程图。

好，上面描述了一个用户从商户APP发起开通免密支付或代扣的签约和查询流程图，这个里面还会涉及到支付流程常见的幂等原则，这里不再细说。

签约完毕了，接下来就是支付扣款了。

流程怎么设计？首先依然看微信代扣的接口文档：

本文由 @产品研究站 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pexels，基于CC0协议