电子钱包/支付系统设计与分析

1、背景

因为印度尼西亚的某众筹机构须要开发一个站内电子钱包系统，因此基于此需求特地作了一番调研。

现在，一些平台如：P2P理财、旅游、游戏等平台都有自身的虚拟钱包系统，像这种站内的电子钱包系统应该如何设计呢？

首先让咱们搞清楚什么是站内电子钱包？和商业的支付系统有什么区别？

站内电子钱包，就是用于站内支付的、非商业的、仅限于为公司内部的业务提供支付支持的支付系统。

商业的支付系统，如：支付宝、微信支付、京东支付等，设计一套完整的商业支付系统是很是复杂的。

和商业的支付系统相比这类系统没有开放平台、开放接口、商户注册等。

因此站内电子钱包，本质上就是一套小型的支付系统。麻雀虽小五脏俱全！下面让咱们看看主流的支付系统是如何设计的。

2、支付系统

2.1 什么是支付系统

支付系统是链接消费者、商家（或平台）和金融机构的桥梁，管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号，支付金额等），金额对帐等功能，根据不一样公司对于支付业务的定位不一样大概有几个阶段：

第一阶段：支付做为一个（封闭）的、独立的应用系统，为各系统提供支付功能支持。通常来讲，这个系统仅限于为公司内部的业务提供支付支持。

第二阶段：支付做为一个开发的系统，为公司内外部系统、各类业务提供支付服务，支付服务自己应该是和具体的业务解耦。

下面让咱们了解下支付系统的总体架构体系，以及主要功能模块。

2.2 主流支付系统总体架构

每一个公司根据其业务和公司发展的不一样阶段，所设计的支付系统也会有所不一样。咱们先看看互联网公司的一些典型的支付系统架构。

支付宝
先看看业内最强的支付宝系统，支付宝的支付系统总体架构设计

京东金融

来自京东支付平台整体架构设计 。

去哪儿

来自去哪儿公司分享的支付产品架构

美团

来自美团的支付平台规划架构 。这是2015年的文档。 2016年美团才拿到支付牌照。

这些架构文档所有来自互联网公开资料。 对于架构是否真实反映实际系统状况，须要你们自行判断。

参考架构

通常来讲，支付系统典型架构会包含以下模块：

支付系统从架构上来讲，分为三层：

支撑层： 用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。
核心层： 支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。
产品层： 经过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。

支付基础设施

支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括以下子系统：

运维监控： 支付系统在下运行过程当中不可避免的会受到各类内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件做出响应，又不可以一天24小时盯着。这就须要一个运维监控系统来协助完成。
日志分析： 日志是支付系通通计分析、运维监控的重要依据。公司须要提供基础设施来支持日志统一收集和分析。
短信平台： 短信在支付系统中有重要做用： 身份验证、安全登陆、找回密码、以及报警监控，都须要短信的支持。
安全机制： 安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。
统计报表： 支付数据的可视化展现，是公司进行决策的基础。

远程链接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里再也不一一详细介绍。

2.3 支付系统的主要功能模块

上面这些大厂的支付系统因为已经商业化了，因此比较复杂。让咱们简化下一个支付系统的主要功能模块有哪些。

应用管理: 同时支持公司多个业务系统对接。
商户管理: 支持商户入驻，商户须要向平台方提供相关的资料备案。
渠道管理: 支持微信、支付宝、银联、京东支付等多种渠道。
帐户管理: 渠道帐户管理，支持共享帐户（我的商户）及自有帐户。
支付交易: 生成预支付订单、提供退款服务。
对帐管理: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（一般T+1），确保交易数据的准确性和一致性。
清算管理: 计算收款交易中商户的应收与支付系统收益。
结算管理: 根据清算结果，将资金划拨至商户对应的资金账户中。

Ok，到此咱们已经了解了一个支付系统的基本架构和主要模块。那么接下来如何从零开始设计一个支付系统呢？这个我以为应该从帐户体系开始。

一个好的支付系统，离不开一个好的支付帐户体系，而一个支付帐户的设计又依赖于帐户体系，因此在开始设计支付系统以前应该先了解并梳理清楚帐户体系。

3、帐户体系

帐户是用来记录会计科目所反映的业务内容的工具，它根据会计科目来开设的。帐户有多种维度的分类。 按照经济内容来讲，帐户分为资产类帐户、负债类帐户、全部者权益类帐户、损益类帐户、成本类帐户和共同类帐户。 按照会计周期内期末是否有余额，也分为实帐户和虚帐户。

既然支付帐户的创建和和会计科目有关，那咱们首先来了解下这些会计科目。

3.1 资产类帐户

用来反映资产增长、减小以及增减变更结果的帐户。和支付系统相关的主要资产类帐户有： 银行存款、应收帐款、预付帐款、库存商品、发出商品等。 资产增长登记在借方，减小登记在贷方，期末有余额的话，通常出如今借方。 在一个会计期间，全部借方金额的累加为“借方本期发生额”，全部贷方金额的累加为“贷方本期发生额”。

资产帐户的余额=借方期初余额+借方本期发生额-贷方本期发生额。

为了跟踪在每一个银行的存款变动状况， 须要对公司在各个银行开通的收款帐户设置对应的银行存款帐户、应收帐款帐户。在小明购买会员卡的案例中，资产类帐户包括：

1. 银行存款，这是一个总帐帐户，记录电商公司在各个银行的总存款。
2. 应收帐款，这是一个总帐帐户，记录在银行的应收帐款，这是虚帐户，期末无余额。
3. 银行存款-工行，这是一个明细帐户，对应在工行的对公帐户的存款变化；
4. 应收帐款-工行，这是一个明细帐户，记录在工行的收款状况，这是虚帐户，期末无余额。

3.2 负债类帐户

负债类帐户也是实帐户，记帐规则跟资产类相反，负债增长记为贷，负债减小记为借，期末若有余额，通常在贷方，代表期末有债务实有额，负债类帐户的余额计算：

贷方期末余额=贷方期初余额+贷方本期发生额-借方本期发生额。

从支付系统的角度， 电商公司的自有帐户，包括针对我的的帐户和针对商户的帐户，通常放在负债类帐户下，此外，应付帐款、预收帐款、应交税费等，也是负债类帐户。

3.3 全部者权益类帐户

全部者权益类帐户用来反映全部者权益增长、减小和变更结果的帐户， 记帐规则跟负债类帐户一致：全部者权益增长记为贷，减小记为借。和支付系统有关的所权帐户包括 本年利润、利润分配等帐户。 企业取得的收入最终会使得全部者权益增长，所以收入类帐户的记帐方法跟全部者权益一致：增长记为贷，减小或者转销记为借，一般该帐户期末无余额（由于期末收入都会转为全部者权益，如未分配利润等），属于虚帐户。

3.4 损益类帐户

损益类帐户分为收入类和费用类帐户。

收入类帐户指各类收入、补贴、投资收益，如主营业务收入、其余业务收入和营业外收入等，增长记为贷，减小记为借。

企业在平常经营活动中会发生各类各样的耗费，这些耗费在会计学上称为成本费用，它们是收入的抵减项目，在抵销收入以前，能够视为一种资产，所以成本费用类帐户的记帐规则跟资产类同样：增长记为借，减小或者转销记为贷。费用类帐户包括：主营业务成本、其余业务成本、营销费用等。

按照企业会计制度的规定，损益类帐户的科目余额，应该结转入利润分配科目，期末余额为零，为虚帐户。

在本案例中，损益类帐户包括：

1. 主营业务收入，这是总分类帐户。
2. 主营业务收入-会员卡，针对会员卡业务的收入。
3. 营销费用，这是总分类帐户。
4. 营销费用-优惠券，用来跟踪优惠券相关的支出。
5. 渠道费用，这是总分类帐户。
6. 渠道费用-工行： 用来跟踪在工行的渠道费用支出。

3.5 成本类帐户

有成本核算的企业须要设立的帐户，包括生产成本、劳务成本等，本文暂不涉及。

3.6 共同类帐户

这是反映特殊经济业务的帐户， 本文暂不涉及。

3.7 帐户体系

Ok, 科普了帐户体系，那么接下来须要考虑如何设计支付帐户了。

4、E-Wallet 系统设计

4.1 准备工做

开通备付金帐户

对于支付平台来讲，首先应在银行设立一个或多个帐户，用于归集客户或商户的备付金（粗俗地能够理解为，客户/商户充值、支付、交易等待结算的资金）

其次，对于首次申请开户的用户，支付平台为每一个用户（基于用户身份证）开通一个惟一的主帐户，和一个余额帐户（子帐户），主帐户下能够添加多个子帐户。

以支付宝为例，一个身份证能够认证6个支付宝帐户，除其中1个主帐户外，其余5个都是子帐户。

为何须要有备付金帐户？

若是用户钱包里的钱都存放到企业对公帐户，那么这部分钱是企业的收益呢？仍是用户的存款呢？根本分不清楚。企业会将用户的存款挪为他用，这样用户的资金没发监管，风险极大。

备付金管理办法的核心是什么？

核心就是三种帐户，分别为存管帐户、收付帐户、汇缴帐户。

存管帐户就是大老婆，每家支付公司只能有在一家银行开立存管帐户。你选择了工商银行，就不能选择华夏银行。存管帐户里的钱能够跨行划款、同行划款、用起来和普通的对公帐户彻底如出一辙，不受限制。但通常存管帐户只能开一个，也有的支付公司，会选择在同一个银行不一样地区的分行之间开帐户。

收付帐户就是姨太太，每家支付公司能够在每一家银行都开立一个收付帐户，但收付帐户不能跨行划款，除非收款帐户是存管帐户。收付帐户只能同行划款，A支付公司能够在工行开一个收付帐户、在农行也开一个收付帐户，但一旦在农行上海分行开一个帐户，就不能在农行深圳分行再开收付帐户了。

汇缴帐户就是一晚上情的情人，随便在哪家银行随便开几个，可是这个帐户日终清零，只能把这个帐户里的钱天天归集到本行收付帐户或是跨行归集到存管帐户，好可怜。有的人问，那汇缴帐户有啥用？好比某个支付公司和某家分行合做了一个网上收单业务，那么这个汇缴帐户就是这家银行天天把收单的钱结给这个支付公司的帐户。

备付金帐户之间头寸是如何调拨的？

存管帐户、收付帐户、汇缴帐户之间的钱是如何调拨的？

首先明确的一点，这个钱不会走银联的系统的，这事情和银联没有啥关系。那么汇缴帐户到收付帐户，就是经过每家银行的行内转帐进行调拨。汇缴帐户、收付帐户到存管帐户，就是经过人行的大小额系统、跨行清算系统（俗称超级网银）或是同城系统进行调拨。

固然咱们说的系统，都是背后的系统，实际上前端的产品就是各家银行的企业网银、银企直联，甚至极端点，你去柜台把这个钱完成调拨都没问题。

每家银行如今陆续的都上了备付金管理系统，这个系统对接了每家支付公司，让银行可以掌握支付公司在本身银行开设的全部备付金帐户的每日余额和资金调拨明细，而且作到汇缴帐户能每日清零，控制收付帐户、汇缴帐户的跨行转帐权限，而且每日能生成报表报送给人行。

这些措施都上了的话，基本能够杜绝支付公司卷款跑人的问题了。

4.2 支付帐户

先来解释下什么是支付帐户？

支付帐户是指支付机构根据客户的真实意愿为其开立的，用于记录预付交易资金余额、客户凭以发起支付指令、反映交易明细信息的电子薄记。（摘自《非银行支付机构网络支付业务管理办法》） 例如咱们熟悉的支付宝余额帐户、微信钱包帐户。

还有另外一个容易混淆的概念--用户帐号。用户帐号是用户在支付机构的惟一识别编码，通常是用户登录时使用的帐号，例如你的支付宝帐号。

同一个用户帐号下，能够有多个不一样用途的支付帐户，即1 ：N的关系。例如余额帐户、储值卡帐户。

4.3 三户模型

实际上不一样公司对底层帐户体系的搭建依托于自己的场景及帐号基础服务等，但大致上都是围绕三户模型作的设计。

三户体系架构

客户：为天然人或法人，分为我的、企业、商户等，不依托于第三方企业属性；须要一些具备法律效应的证件去佐证客户是真实存在的，所以须要有身份证、护照、营业执照等做为证实。互联网2C和2B的业务会有针对客户的实名认证、资质审核等以便作客户管理。一个天然人可能会有多个帐号，如一我的同时有微信、支付宝或京东帐号；也可能会有多个帐户，如一我的有多张银行卡、白条或小金库帐户。

用户：为帐号层面的属性，依托于第三方企业属性。如小明是用户，须要知足注册/登陆体系条件，注册为用户，登陆密码、昵称、帐号等级、联系方式等都是基于帐号层面的管理。一个帐号下能够有多个帐户；同时用户层面会有基本信息，如实名信息等。

帐户：通常是对资金信息的管理，如资金余额、资金帐。对于金融科技而言，通常都是虚拟帐户管理而非真实的资金（真实资金通常都经过银行帐户管理）。帐户系统跟帐务系统挂钩，有单式记帐法和复式记帐法，通常会结合交易订单管理及相关场景（信贷仍是储蓄等）。

支付平台为了方便管理不一样场景的资金或不一样客户的资金，会有主帐户、子帐户之分，这样也有利于不一样子业务的灵活开展。支付平台一边连着用户，一边连着银行，为了方便归集管理资金，支付平台不会为用户一一对应的设计银行帐户，而是在银行设立一个总帐户管理不一样场景的用户资金。

因须要严格的记帐及对帐逻辑，因此要有虚拟资金账管理及结算系统管理。不一样支付平台采用的方式不同，有的采用资金池模式（基于总虚拟帐户管理），有的采用虚拟帐户模式。

4.4 支付帐户体系设计

能够说支付帐户体系的设计是整个支付系统中最重要的一块，由于它是整个系统的基石。

4.4.1 支付系统数据结构

Ok，了解了三户模型，如今咱们须要根据三户模型构建帐户结构了。

支付帐户结构图

根据此结构关系，下面先给出总体的、关键的数据结构设计。

帐户相关表结构

交易相关表结构

以上基本是最核心的数据结构了，固然，不是所有的。

接下来须要梳理下我的、企业开户、充值、支付的流程，以及结合上面的数据结构作一些讲解。

4.4.2 开户

每一个用户必须开通支付帐户，开通支付帐户必须进行实名认证。帐户按照全部权能够区分为我的帐户、商户/企业帐户、内部支付帐户。

我的帐户：是面向我的用户开设的电子帐户。
企业帐户：是面向企业、机构等开设的帐户。
内部帐户：是平台为自身业务开展的需求而为本身设立的帐户。

除此以外，支付系统还能够根据业务须要设置各类不一样的帐户类型。

因为咱们是开发一个内部使用的电子钱包，将来有可能会对外提供支付服务。因此在设计上我尽可能兼容之后的业务。

开户会设计到如下4张表

客户实体：是彻底独立的我的、企业身份信息，是须要认证的。

客户帐号：支付系统相对于整个平台来讲，是做为独立的基础服务系统存在的，因此会有自身的独立帐号体系，而业务平台业务须要，平台业务的passport系统帐号，能够和支付系统帐号绑定。另外，客户帐号ID，能够看做是主帐号。

客户实体-客户帐号关系：是1:N的关系。

客户账户：是客户帐号下的资金帐户，能够是有多个帐户。特别注意的是，要事先约定好帐户ID的规则。好比头三位用来表示帐户类型，后几位用来表示帐户编号等。务必保证根据帐号号可以快速肯定帐户类型，而且保证帐户号是不重复的。

客户帐号-客户帐户关系：是1:N的关系。

在支付帐户体系中，以客户为惟一要素，关联不一样的帐户。 客户有惟一的用户 ID，余额帐户、理财帐户，每一个帐户有各自的帐户 ID。一个用户 ID 关联多个帐户 ID。

支付帐户体系内的全部涉及客户的资金，本质上是属于客户，而不属于开发帐户体系的互联网公司。第三方支付机构的帐户系统设计和帐户真实资金的管理，要求每一种帐户体系，支付机构都会在银行开设一个备付金帐户，由银行来管理备付金帐户的资金。备付金帐户的资金是这个帐户体系的所有资金，帐户体系内每一个实体（如：收款商户、充值用户）所对应的资金金额，由第三方支付机构内部系统进行记录和管理。

4.4.3 设置

用户对帐户的设置

• 资金密码（用于提现和支付）
• 申请注销帐户

平台对帐户的设置

• 是否容许充值；
• 是否容许提现；
• 是否容许透支；
• 是否激活；
• 是否注销；

4.4.4 绑卡签约

为何要求用户绑卡？这和快捷支付有关。

快捷支付指用户在电商网站上执行支付时，不须要输入卡信息，仅根据短信或者其余的验证方式确认身份后，就能够执行扣款的支付方式。 这是目前电商网站采用的主要支付方式。 在快捷支付中，用户首次支付，须要提供卡的信息，以后就能够凭短信验证码，甚至不须要密码，也能够执行扣款。

接口概述

通常来讲，快捷支付须要提供以下接口：

1. 签约， 也叫“绑卡签约”、“开通交易”等，指用户在商户网站上开通快捷支付的功能，他须要将银行卡相关信息提供给电商。
2. 解约， 也叫“解绑卡”， 指用户取消在该网站上的快捷支付功能。通常也会删除该用户在该网站上的相关的银行卡信息。
3. 扣款， 也叫“支付”， 指用户使用签约的卡来执行一笔扣款。
4. 退款， 针对已经扣款成功的交易执行退款操做，通常同时也会把用户权益或者对应的订单撤销。并非全部订单均可以执行退款。
5. 查单, 查询某次交易的处理状态。
6. 签约查询， 即检查某个用户是否已经开通了签约功能。

咱们以支付宝绑卡为例，通常支付机构对用户进行实名后，用户只能绑定本身的银行卡，这主要从安全角度考虑。

1 .输入卡号

用户输入卡号，系统对卡号进行初步验证。验证是基于卡bin和LUHN算法。固然，有些系统提供了OCR功能，便可经过扫描方式获取卡号信息。通常来讲，你能够经过卡bin知道哪一个银行，由于每一个银行都有本身的卡号规则，你能够经过这些规则知道是哪一个银行

2 得到银行卡信息

第一次绑定须要卡的信息。借记卡须要卡号，用户的真实姓名和身份证，全部的都是同样的。信用卡是复杂的。一些渠道验证信用卡还须要提供CV码和信用卡有效期。

3 .验证预留手机号

这里有一个四要素验证的概念。因为实名制，全部银行卡都是实名，银行能够核实姓名、身份证号码、银行卡号码和电话号码。若是验证经过，就会发一条短信到你的手机。
注意：

1. 关于预留手机号。咱们都知道，银行预留的手机号码一般都是办卡时候留的。几年后，许多人换了手机号，忘记了去银行更改手机号。所以，许多银行就不验证电话号码。
2. 关于短信验证码，电话号码有时候都是没必要要的，短信可能就不会发送。那么银行不发，支付机构就能够本身发；
3. 重复绑卡问题。若是系统支持多个账户，那么一我的必然会被绑定到多个账户。有些渠道支持重复绑卡，有些渠道不支持；

4 进行绑定
用户输入短信验证码并确认绑卡。支付机构就会将用户的银行卡信息和短信验证码组合发送给银行进行签约操做。在银行成功签约后，它将把签约号码返还给商户。这种处理逻辑是在支付渠道方面引入的。银行将返回如下结果:

1. 签约成功：这意味着能够创建签约关系。下次就可经过签约号来进行扣款操做。
2. 重复签约：按照业务考虑是否支持重复签约。 通常针对一个银行卡仅保留一个签约关系。
3. 签约失败：会提示具体失败缘由。

4.5 充值

以用户在第三方支付平台（支付宝）用银行卡给本身虚拟帐户在线充值为例，为简化流程，均以最理想状况进行说明：

1. 用户在第三方支付平台执行充值操做。
2. 平台根据用户充值指令，跳转到银行网关进行支付。
3. 用户支付成功后，银行会实时从用户的银行帐户上执行扣款操做（资金转移到第三方支付平台在银行的存管帐户）。
4. 银行网关通知支付平台用户支付成功（成功扣款）。
5. 支付平台在本身帐户体系中给对应用户虚拟帐户增长对应资金。
6. 平台通知用户充值成功。

银行和支付平台而后按照约定的结算周期（例如T+1）进行对帐、清结算等操做，将用户充值的资金结算给支付平台在银行设立的帐户（备付金帐户，平台在银行开设一个实体对公帐户）。

以上只是简化的充值流程，其中在第三步通常银行只扣划用户款项，待到日终才会将款项划转到支付宝备付金帐户，第五步通常也不会增长支付宝备付金帐户，而是先经过中间帐户，如充值待清算帐户，等到日终银行头寸和对帐文件下发时，经过对帐逻辑进行处理，若涉及到异常流程，会更复杂些。

从简化的流程图里仍是能够看出支付平台只处理虚拟资金，实资金仍在银行体系内。

从帐户关系也能够看出，实资金变更从我的银行卡划转到了支付平台的银行帐户，虚资金是支付平台为每一个注册用户创建的虚拟帐户，与用户的银行卡能够说没有直接关系；说的再直白些，用户充值的款项都划转到支付平台在银行开立的大帐户，业务主体为“某支付平台”，而后支付平台在系统内为每一个用户创建台帐。

上面的充值，若是绑定了银行卡，充值会很方便。为何要求用户绑卡？这和快捷支付有关。绑卡是将用户卡信息提供给电商，之后电商就用这个信息去银行完成支付。绑卡其实是一个受权，让用户容许商家自动从他的帐户上扣除资金。因此绑卡也叫签约，用户和银行，商家的三方签定的支付合约。

4.6 使用E-Wallet支付

当开户及充值完成后，接下来就是使用E-Wallet做为支付渠道了支付了。

Ok, 下面是一个常见的电子钱包支付流程。

做为支付系统，这个过程一共分两步：收单和支付。

4.6.1 收单

用户在业务平台上提交支付订单后，支付系统收到用户的订单支付请求并验证请求后，并记录下来。

一般状况下，根据用户使用的终端是h5仍是app应用，支付系统会返回二维码或者deeplink链接。

不过若是是内部钱包支付，收单和支付能够同时进行，可是为了之后的扩展性，流程和结构仍是要分两步。

具体参见上面的“统一收单”表。

4.6.2 支付

这里须要同步和异步处理收单表里的订单，处理完以后须要事务写入支付记录和帐户帐单流水。

这里以支付宝的支付流程为例说一下：

整个支付流程就是这五大块之间的交互，具体的实现上图也给的很清晰了，下面对图中重要的步骤简单的介绍：

• 添加购物车，生成待支付订单，产生惟一订单号
• 请求商户服务端（本身的后台），在后台对订单信息进行签名操做，这里应用为了安全考虑，会把似钥放在服务端，客户端只要报订单号传给服务端，具体签名在后台进行。
• 服务端把签名好的订单信息返回给客户端
• 调用支付接口，把签名好的订单信息，经过调用支付宝API，发送给支付宝客户端SDK
• 支付宝客户端发起向支付宝服务端发起支付请求
• 支付宝客户端输入支付密码。完成支付
• 返回同步结果给支付宝客户端
• 支付宝客户端将接口返回支付结果给咱们的商户端口，9000支付成功
• 同时也将支付结果发送给了商户服务端。验签，解析支付结果。将客户端与服务端的支付信息进行比对，确保订单支付正确无误
• 确认订单无误以后，返回最终支付结果给商户端
• 客户端将订单支付完成信息在界面显示，告知用户支付完成

4.7 API 列表

既然支付帐户已经开通，那么做为一种支付渠道，天然能够用于各类场景的消费。做为支付渠道，就须要提供相应的SDK，用于消费场景的支付流程开发。

此列表包含支付平台电子钱包系统所涉及的几乎全部接口，参考支付宝：

接口英文名	接口中文名
alipay.trade.page.pay	统一收单下单并支付页面接口
alipay.trade.refund	统一收单交易退款接口
alipay.trade.fastpay.refund.query	统一收单交易退款查询接口
alipay.trade.query	统一收单线下交易查询接口
alipay.trade.close	统一收单交易关闭接口
alipay.data.dataservice.bill.downloadurl.query	查询对帐单下载地址

参考

https://zhuanlan.zhihu.com/p/58624171

http://doc.cocolian.cn/essay/account/2017/02/03/clearing-account/

https://zhuanlan.zhihu.com/p/31198490

https://zhuanlan.zhihu.com/p/55592943

https://juejin.im/post/5c2345c0518825235a0554bb

https://zhuanlan.zhihu.com/p/33897440

https://kuaibao.qq.com/s/20181026G0D0WV00?refer=spider

https://www.banana.ch/doc/zh-hans/node/3826