对接第三方支付的电商平台的合规实践
合规对于电商平台来说并不陌生，和“钱”有关的支付需符合监管要求。个人根据公司内部电商平台的“清结算”项目，初步总结对支付合规的基础认识。若刚好做电商，要对接第三方支付公司的话，可以通过本文做粗浅了解。本文内容为个人工作实践总结，如有不对之处，烦请留言友好指出，感谢。 01 实践背景 1.1 概述 背景：公司的员工福利电商平台，需引入支付渠道，满足合规要求，避免二清问题。 引出问题： 合规是什么？二清是什么？清结算是什么？ 下面从个人理解角度，结合我们平台（平台模式为自营+非自营）现存的问题，说明一下这几个关键词汇。 什么是合规？： 合规：电商平台和“钱”有关的支付需要符合监管要求，而监管要求目标是保障平台用户的资金安全，避免平台卷钱跑路（就像之前的 P2P）。 风险：我们公司存在的合规风险是因为平台在中间做了代收代付的业务，违反监管要求 具体如下图（平台现状图）所示： 02 交付产出：清结算方案（部分） 清结算一般都是支付机构、银行之间的交易记账、资金清算，涉及的机构包括中国人民银行、网联、 银联等，系统也涉及中国人民银行的大小额系统，和本次项目涉及平台无关。 建立虚拟户体系 梳理平台和钱有关的业务：充值、提现、消费业务 消费业务 （消费业务即用户需要付款的业务） 做好信息流记账，包括账户纬度记账（支出、收入等） 、交易记录纬度的记账（交易金额、交易双方、交易时间等） 2.1 虚拟账户的设计 前言：区分一下“账号”、“账户”概念区别，之所以作区分，是因为有的人会把二者认为是一个概念，实则不同。 账户与账号区别 账号：可以理解为就是电商平台用户的登录账号 账户：主要是和充值、提现、消费等业务有关的一个概念，账户是一个统称，可以有不同的分类，例如：支付宝的余额理解成“余额账户”，支付宝积分理解为“积分账户”，还有红包，可以理解为“红包账户”或“营销账户”。 本次平台对接第三方支付公司，引入虚拟户方案，建立商家、用户的账户体系 如上所示，认证成功后，平台用户可绑定银行卡，也可顺利开展充值、提现等业务。当然，账户体系管理后台，会同步记录账户的开户信息，如下图所示： 特别说明：在产出方案时，会要求产品人员通过状态机的形式表示各个支付节点的状态。比如：若账户状态为冻结状态，则需要梳理相关受到限制的业务，例如充值业务、提现业务、其他消费业务等，在用户操作相关业务时，给予一定的友好提示； 2.2 平台支付业务梳理 前言：主要是把平台中和账户余额有关的业务枚举，需要根据业务，判断应该调用第三方哪些接口实现资金流转或账户余额变动。常见支付业务包括充值、提现、支付。具体详见下文。 2.2.1 充值业务 财务关注的问题，如：避免信用卡套现。故在对接场景的渠道，例如使用支付宝扫码/微信扫码时，对接第三方支付，有个支付限制字段，需在传参的时候，屏蔽非贷记卡。还有一个关键点，平台获得的所有支付结果，均从所对接的第三方厂商获取，无需单独获取各个渠道（例如微信、支付宝等）的支付结果。 充值业务时序图 2.2.1 提现业务 提现业务时序图 2.2.3 支付业务（狭义） 前言：这里讲的支付，是狭义的支付，针对用户购买商品进行付款的支付场景进行说明。有三种方案 ，详见下文。 A, 方案一：直接使用账户余额支付 使用余额支付，顾名思义就是用虚拟户的余额进行支付，例如淘宝买东西，使用支付宝余额进行支付。 B, 方案二：通过账户余额之外的渠道进行付款，例如银行卡支付 方案2 可以从两个层面进行理解： 理解为充值即消费，先充值到余额，再立即消费的流程，和余额变动有关； 理解为使用其他渠道入金的方式进行支付，和余额变动无关 重点看业务需要的记账规则，公司平台在虚拟户方案之前，是“充值即消费”的记账思路。故此，对接虚拟户方案后，依然是采用这种记账思路。 例如:小明账户余额 0.00 元，购买商品需要支付 100 元，在支付收银台，用户选择银行卡123 支付成功，则该用户的账户流水如下： C, 方案三：组合支付 组合支付：使用多种方式结合进行支付，是主流购物场景常用的方式，例如：余额+银行卡、余额+优惠券等。 关于组合支付，一般和如下三种情况有关： 支付方式：不同支付方式，对组合支付的支持情况不同，但是大多数支付方式是支持组合支付的。第三方支付公司常见的入金支付方式就有多达10多种支付方式，例如： 订单POS、微信支付（APP支付、扫码支付、刷卡支付、公众号支付、小程序支付、H5 支付）、支付宝支付（扫码支付、刷卡支付、生活号支付、手机网站支付）、收银宝快捷、银联（扫码支付、被扫支付、JS 支付）等。 业务需求：充值提现业务场景，一般是不支持组合支付。但是有的提现业务场景，积分可抵扣交易手续费，因此，提现订单可能涉及组合支付，具体需结合业务诉求。 第三方支付公司的业务限制：例如我们平台所对接的第三方支付公司不允许充值提现订单的组合支付。 以上，不管哪种支付方式，都涉及交易验证方式，一方面需要根据自己的业务判断，交易验证方式应该采用无验证（类似免密支付）、还是采用密码或短信验证码等；另外一方面，需要根据第三方支付公司对接渠道的要求，确定所采用的交易验证方式。 2.3 交易记录设计 就像上述内容中，充值订单、提现订单都会在相关环节生成交易记录，因此系统需要根据业务订单进行记录的信息。交易记录的设计意图是基于平台的业务，记录账户相关的交易信息。核心是记清楚付款方、收款方，交易金额，相关商品或服务等，以便和第三方提供的商户对账文件对账使用。 举例1：例如微信支付的记录，重点需记录的字段信息如下： 交易记录编号、交易类型、付款方、付款方账户 ID、支付方式、备注、 交易时间（成功时间）、平台手续费、渠道手续费、第三方手续费、交易状态、所属订单编号（业务系统订单编号）、第三方单号、关联交易记录编号； 举例2：京东平台的商户对账单文件 涉及字段： 订单编号 企业PIN 企业名称 父订单号 PO单号 下单日期 订单完成日期 实付金额 售后状态 可开票金额 开票形式 作废次数 冲红次数 申请单号 订单类型 订单来源 订单状态 开票状态 对账完成时间 出库时间 出货机构 订单发票类型 商品金额 运费 应收优惠 支付优惠 退货 换货 原返 直赔 关闭 应退款金额 扣款金额 实际退款金额 实开发票类型 实开金额 财务单号 发票号 发票金额 开票机构 结算单位 发票收件人 注：不同平台返回的对账文件，字段、含义都不一致，需要产品进行辨别，如果涉及对账系统的设计，需要在对账系统中做对账文件的解析。后续也会分享对账系统。 03 总 结 以上内容，是个人认为电商平台对接第三方支付平台要覆盖的基本内容。本次清结算项目里面，还多了一些其他的业务辅助功能，例如：基于交易记录，定时统计账户余额，同时获取第三方的账户余额，方便及时发现两边账户余额不一致的异常账户；另外也做了关于日切统计，同步不同业务类型订单的数量、交易金额等，为和第三方统计的结果做对账使用。 总之，从 0-1 做一个项目，每一次方案的推敲、推翻、重新设计，都让目标都更加清晰，在这个过程也收获颇多 本文由 @RICK 原创发布于人人都是产品经理。未经作者许可，禁止转载 题图来自 Unsplash，基于CC0协议 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
合规对于电商平台来说并不陌生，和“钱”有关的支付需符合监管要求。个人根据公司内部电商平台的“清结算”项目，初步总结对支付合规的基础认识。若刚好做电商，要对接第三方支付公司的话，可以通过本文做粗浅了解。本文内容为个人工作实践总结，如有不对之处，烦请留言友好指出，感谢。
01 实践背景
1.1 概述
背景：公司的员工福利电商平台，需引入支付渠道，满足合规要求，避免二清问题。
引出问题：
合规是什么？二清是什么？清结算是什么？
下面从个人理解角度，结合我们平台（平台模式为自营+非自营）现存的问题，说明一下这几个关键词汇。
什么是合规？：
合规：电商平台和“钱”有关的支付需要符合监管要求，而监管要求目标是保障平台用户的资金安全，避免平台卷钱跑路（就像之前的 P2P）。
风险：我们公司存在的合规风险是因为平台在中间做了代收代付的业务，违反监管要求
具体如下图（平台现状图）所示：
02 交付产出：清结算方案（部分）
清结算一般都是支付机构、银行之间的交易记账、资金清算，涉及的机构包括中国人民银行、网联、 银联等，系统也涉及中国人民银行的大小额系统，和本次项目涉及平台无关。
建立虚拟户体系 梳理平台和钱有关的业务：充值、提现、消费业务
消费业务 （消费业务即用户需要付款的业务） 做好信息流记账，包括账户纬度记账（支出、收入等） 、交易记录纬度的记账（交易金额、交易双方、交易时间等）
2.1 虚拟账户的设计
前言：区分一下“账号”、“账户”概念区别，之所以作区分，是因为有的人会把二者认为是一个概念，实则不同。
账户与账号区别
账号：可以理解为就是电商平台用户的登录账号
账户：主要是和充值、提现、消费等业务有关的一个概念，账户是一个统称，可以有不同的分类，例如：支付宝的余额理解成“余额账户”，支付宝积分理解为“积分账户”，还有红包，可以理解为“红包账户”或“营销账户”。
本次平台对接第三方支付公司，引入虚拟户方案，建立商家、用户的账户体系
如上所示，认证成功后，平台用户可绑定银行卡，也可顺利开展充值、提现等业务。当然，账户体系管理后台，会同步记录账户的开户信息，如下图所示：
特别说明：在产出方案时，会要求产品人员通过状态机的形式表示各个支付节点的状态。比如：若账户状态为冻结状态，则需要梳理相关受到限制的业务，例如充值业务、提现业务、其他消费业务等，在用户操作相关业务时，给予一定的友好提示；
2.2 平台支付业务梳理
前言：主要是把平台中和账户余额有关的业务枚举，需要根据业务，判断应该调用第三方哪些接口实现资金流转或账户余额变动。常见支付业务包括充值、提现、支付。具体详见下文。
2.2.1 充值业务
财务关注的问题，如：避免信用卡套现。故在对接场景的渠道，例如使用支付宝扫码/微信扫码时，对接第三方支付，有个支付限制字段，需在传参的时候，屏蔽非贷记卡。还有一个关键点，平台获得的所有支付结果，均从所对接的第三方厂商获取，无需单独获取各个渠道（例如微信、支付宝等）的支付结果。
充值业务时序图
2.2.1 提现业务
提现业务时序图
2.2.3 支付业务（狭义）
前言：这里讲的支付，是狭义的支付，针对用户购买商品进行付款的支付场景进行说明。有三种方案 ，详见下文。
A, 方案一：直接使用账户余额支付
使用余额支付，顾名思义就是用虚拟户的余额进行支付，例如淘宝买东西，使用支付宝余额进行支付。
B, 方案二：通过账户余额之外的渠道进行付款，例如银行卡支付
方案2 可以从两个层面进行理解：
理解为充值即消费，先充值到余额，再立即消费的流程，和余额变动有关；
理解为使用其他渠道入金的方式进行支付，和余额变动无关
重点看业务需要的记账规则，公司平台在虚拟户方案之前，是“充值即消费”的记账思路。故此，对接虚拟户方案后，依然是采用这种记账思路。
例如:小明账户余额 0.00 元，购买商品需要支付 100 元，在支付收银台，用户选择银行卡123 支付成功，则该用户的账户流水如下：
C, 方案三：组合支付
组合支付：使用多种方式结合进行支付，是主流购物场景常用的方式，例如：余额+银行卡、余额+优惠券等。
关于组合支付，一般和如下三种情况有关：
支付方式：不同支付方式，对组合支付的支持情况不同，但是大多数支付方式是支持组合支付的。第三方支付公司常见的入金支付方式就有多达10多种支付方式，例如：
- 订单POS、微信支付（APP支付、扫码支付、刷卡支付、公众号支付、小程序支付、H5 支付）、支付宝支付（扫码支付、刷卡支付、生活号支付、手机网站支付）、收银宝快捷、银联（扫码支付、被扫支付、JS 支付）等。
- 业务需求：充值提现业务场景，一般是不支持组合支付。但是有的提现业务场景，积分可抵扣交易手续费，因此，提现订单可能涉及组合支付，具体需结合业务诉求。
- 第三方支付公司的业务限制：例如我们平台所对接的第三方支付公司不允许充值提现订单的组合支付。
以上，不管哪种支付方式，都涉及交易验证方式，一方面需要根据自己的业务判断，交易验证方式应该采用无验证（类似免密支付）、还是采用密码或短信验证码等；另外一方面，需要根据第三方支付公司对接渠道的要求，确定所采用的交易验证方式。
2.3 交易记录设计
就像上述内容中，充值订单、提现订单都会在相关环节生成交易记录，因此系统需要根据业务订单进行记录的信息。交易记录的设计意图是基于平台的业务，记录账户相关的交易信息。核心是记清楚付款方、收款方，交易金额，相关商品或服务等，以便和第三方提供的商户对账文件对账使用。
举例1：例如微信支付的记录，重点需记录的字段信息如下：
交易记录编号、交易类型、付款方、付款方账户 ID、支付方式、备注、 交易时间（成功时间）、平台手续费、渠道手续费、第三方手续费、交易状态、所属订单编号（业务系统订单编号）、第三方单号、关联交易记录编号；
举例2：京东平台的商户对账单文件 涉及字段：
订单编号 企业PIN 企业名称 父订单号 PO单号 下单日期 订单完成日期 实付金额 售后状态 可开票金额 开票形式 作废次数 冲红次数 申请单号 订单类型 订单来源 订单状态 开票状态 对账完成时间 出库时间 出货机构 订单发票类型 商品金额 运费 应收优惠 支付优惠 退货 换货 原返 直赔 关闭 应退款金额 扣款金额 实际退款金额 实开发票类型 实开金额 财务单号 发票号 发票金额 开票机构 结算单位 发票收件人
注：不同平台返回的对账文件，字段、含义都不一致，需要产品进行辨别，如果涉及对账系统的设计，需要在对账系统中做对账文件的解析。后续也会分享对账系统。
03 总 结
以上内容，是个人认为电商平台对接第三方支付平台要覆盖的基本内容。本次清结算项目里面，还多了一些其他的业务辅助功能，例如：基于交易记录，定时统计账户余额，同时获取第三方的账户余额，方便及时发现两边账户余额不一致的异常账户；另外也做了关于日切统计，同步不同业务类型订单的数量、交易金额等，为和第三方统计的结果做对账使用。
总之，从 0-1 做一个项目，每一次方案的推敲、推翻、重新设计，都让目标都更加清晰，在这个过程也收获颇多
本文由 @RICK 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
你的反应是什么？
