笔者作为一个支付清结算小白，经过一个公司内部“清结算”项目，初步对支付合规有了一定的认识，若小伙伴刚好做电商，要对接第三方支付公司的话，可以通过本文粗浅的初步了解一下。本文内容为个人实践总结，若有不对之处，烦请留言友好指出，感谢。

一、实践背景

初入公司，老大抛了一个作业给我，告知我公司要做合规，避免两清，所以需要做清结算。我人好懵，合规是什么？两清是什么？清结算是什么？带着这些对我而言陌生的词汇，先开始了我的学习之旅，因为这些应该都是基本概念，不可能让老大一一解释给我，然而，要写好这个作业，搞清楚这些术语，就明白作业目标是什么了。下面从我个人理解角度，结合我们平台（平台模式为非自营业务，商品归商家所有）现存的问题，说明一下这几个关键词汇。

合规其实就是电商平台和“钱”有关的支付需要符合监管要求，而监管要求目标是保障平台用户的资金安全，避免平台卷钱跑路，就像之前的P2P。我们公司存在的合规风险是因为平台在中间做了代收代付的业务，违反监管要求，具体如下图（平台现状图）所示：

看本文的小伙伴，想一想你们的电商平台是不是也有类似的问题？

二、我的“清结算”作业

下我上网看了不少清结算的介绍，还特意买了一本支付系统架构有关的书籍，发现清结算一般都是支付机构、银行之间的交易记账、资金清算，涉及的机构中国人民银行、网联、银联等，系统也设计中国人员银行的大小额系统，和我们平台貌似没什么关系，因为我们平台只是对接第三方支付公司，清结算到底应该做什么呢？其实做什么，还是基于问题现状去分析，就像第一部分的平台现状图描述，平台清结算主要解决的是平台面临的风险，经过思考，对平台清结算重点应该做的内容有了比较清晰的认知：

建立虚拟户体系梳理平台和钱有关的业务：充值、提现、消费业务1、消费业务2…（消费业务即用户需要付款的业务）做好信息流记账，包括账户纬度记账（支出、收入等）、交易记录纬度的记账（交易金额、交易双方、交易时间等）

具体，详见下文。

三、清结算设计的重点方案设计

3.1 虚拟户的账户设计

这里需要先区分一下“账号”、“账户”概念区别，之所以作区分，是因为有的人会把二者认为是一个概念，实则不同。账号可以理解为就是电商平台用户的登录账号，账户主要是和充值、提现、消费等业务有关的一个概念，账户是一个统称，可以有不同的分类，例如支付宝的余额理解成“余额账户”，支付宝积分理解为“积分账户”，还有红包，可以理解为“红包账户”或“营销账户”。我们平台这次对接第三方支付公司，引入虚拟户方案，就是为了账户而生。

虚拟户方案则基于原有系统的账号体系，创建1V1的虚拟户，说明一下，我们平台账号与虚拟户为一一对应的关系，实质上，我们对接这个第三方公司，1个账号可对应三个虚拟户。这次对接过程中梳理了对接第三方的开户流程，具体如下：

1）个人开户：即以个人主体作为认证依据

2）企业认证：即以企业为主体进行实名认证

如上所示，认证成功后，平台用户即可绑定银行卡，也可顺利开展充值、提现等业务。当然，账户体系管理后台，会同步记录账户的开户信息，如下图所示：

特别说明一下状态机，若账户状态为冻结状态，则需要梳理相关受到限制的业务，例如充值业务、提现业务、其他消费业务等，在用户操作相关业务时，给予一定的友好提示；

3.2 梳理平台的支付业务

主要是把平台中和账户余额有关的业务穷举，需要根据业务，判断应该调用第三方哪些接口实现资金流转或账户余额变动。比较常见的支付业务包括充值、提现、支付。具体如下：

3.2.1 充值

充值业务，我们财务比较关注的避免信用卡套现，故在对接场景的渠道例如使用支付宝扫码/微信扫码时，对接第三方支付，有个支付限制字段，需要在传参的时候，屏蔽非贷记卡。还有一个关键点，平台获得的所有支付结果，均从所对接的第三方厂商获取，无需单独获取各个渠道（例如微信、支付宝等）的支付结果。

充值业务时序图：

3.2.2 提现

3.2.3 支付

这里讲的支付，是狭义的支付，针对用户购买商品进行付款的支付场景进行说明。

这里的支付比较特殊，基本有三种方案：

第一种：直接使用账户余额支付

使用余额支付，顾名思义就是用虚拟户的余额进行支付，例如淘宝买东西，使用支付宝余额进行支付。

第二种：通过账户余额之外的渠道进行付款，例如银行卡支付。

这个方案有2个层面的理解：

理解为充值即消费，先充值到余额，再立即消费的流程，和余额变动有关；理解为使用其他渠道入金的方式进行支付，和余额变动无关;

重点看业务需要的记账规则，我们平台在虚拟户方案之前，是“充值即消费”的记账思路，故此，对接虚拟户方案后，依然是采用这种记账思路。举例子如下：

例如王一博账户余额100，购买商品需要支付100元，在支付收银台，用户选择银行卡123支付成功，则该用户的账户流水如下：

但是，一些平台会按照第二种思路记录交易，例如使用微信支付时，支付方式若选择的是银行卡，微信“零钱-零钱明细”不会产生入金流水，而“微信支付”的对话框中，则会记录支付方式为银行卡；

第三种：使用组合支付

组合支付即使用多种方式结合进行支付，是主流购物场景常用的方式，例如余额+银行卡、余额+优惠券等。

关于组合支付，和如下三种情况有关：

支付方式：不同支付方式，对组合支付的支持情况不同，但是大多数支付方式是支持组合支付的。我们对接的第三方支付公司，入金支付方式多达10多种支付方式，例如订单POS、微信支付（APP 支付、扫码支付、刷卡支付、公众号支付、小程序支付、H5 支付）、支付宝支付（扫码支付、刷卡支付、生活号支付、手机网站支付）、收银宝快捷、银联（扫码支付、被扫支付、JS支付）等。

业务需求：充值提现业务场景，一般是不支持组合支付。但是有的提现业务场景，积分可抵扣交易手续费，因此，提现订单可能涉及组合支付，具体需结合业务诉求。

第三方支付公司的业务限制：例如我们平台所对接的第三方支付公司不允许充值提现订单的组合支付。

以上，不管哪种支付方式，都涉及交易验证方式，一方面需要根据自己的业务判断，交易验证方式应该采用无验证（类似免密支付）、还是采用密码或短信验证码等；另外一方面，需要根据第三方支付公司对接渠道的要求，确定所采用的交易验证方式。

3.3 交易记录设计

就像上述内容中，充值订单、提现订单都会在相关环节生成交易记录，也就是系统需要根据业务订单进行记录的信息，交易记录的设计意图是基于平台的业务，记录账户相关的交易信息，其实就是记清楚付款方、收款方，交易金额，相关商品或服务等，以便和第三方提供的商户对账文件对账使用。例如微信支付的记录：

重点需记录的字段信息如下：

前台呈现层面，均为交易状态=交易成功/交易成功-发生退款的记录，便于财务和第三方下载的对账文件对账。

四、总结

以上内容，是我认为电商平台对接第三方支付平台要覆盖的基本内容。其实我们本次清结算项目里面，还多了一些其他的业务辅助功能，例如基于交易记录，定时统计账户余额，同时获取第三方的账户余额，方便及时发现两边账户余额不一致的异常账户；另外也做了关于日切统计，同步不同业务类型订单的数量、交易金额等，为和第三方统计的结果做对账使用。

总之，从0-1做一个项目，从无知小白，到项目投入研发，方案也被来来回回推翻了很多次，但是每一次推翻，让我们的目标都更加清晰，我在这个过程也收获颇多，希望大家遇到完全不懂的新项目，不要气馁，撸起袖子干就可以了～喜欢我的小伙伴可以关注我哇，我会持续分享自己的工作心得，可能有的是层面比较浅，希望大家支持～