现在的网络支付，不少都是从用户先到平台，再由平台结算给商户，形成了事实上的“二清”。这种情况下，产品和系统该如何设计呢？这篇文章，我们来学习一下
什么是二清：二清就是无支付牌照的公司，没有资质做资金的二次清结算； 像我司电商业务pop模式，有商家入驻卖货的流程，平台收取用户资金，再给商户做结算，就涉及二次清结算（一清是清分，二清是结算）；这是违规的，极大可能会受到监控处罚；
二清的官方阐释：无证机构以平台对接或者大商户接入支付机构或商业银行，留存商户结算资金，并自行开展商户资金清分结算。具体到线上平台型机构的网络支付，“二清”的表现形式就是“大商户结算”模式，即用户支付资金先划转至网络平台账户，再由网络平台结算给其平台入驻商户。这在结算过程中形成了事实上的“二清”。
为什么做这个项目：目的就是为了规避结算链路的违规风险，保障支付渠道交易稳定；
那需求是如何被我发现的：
①对公司业务现状的理解，发现我司pop模式的结算链路有二清风险；
②基于我对这方面的行业经验，以及网上各种被处罚的新闻，发现我司存在有被处罚的可能；
项目价值：通过产品系统搭建，规避公司交易链路的风险，保障每年几百万的支付收单，以及几亿的资金流的稳定流转；
我的价值提现：发现问题所在，调研给出解决方案，联合各部分，协调资源，推动项目落地，来解决公司电商交易链路的风险；
我的角色：对项目进行调研、确认方案、规划节奏、业务流程梳理、产品架构设计、项目落地、结果复盘、持续迭代；
下面是如何进行：业务调研、市场调研、给出解决方案的示例；
业务调研：
业务调研：对核心部门的核心角色进行调研：主要是财务部、采销部、商管部、技术部等；
业务调研现状是：电商的业务模式分为三种pop、自营代销、自营自研；
其中pop有国内和海淘；
支付渠道：主要是微信和支付宝；
pop的收单流程：平台在微信开通普通商户号 – 用户支付到平台 – 平台给商户做一清分账和二清结算（这里就二清违规了）；
市场调研：大致三种解决方案
调研：①直接对接微信收付通/支付宝直付通分账解决方案；②对接三方聚合支付公司（汇付、宝付、易宝等等）；③与对接银行（估计需要内部有人）；
最终方案：最终选择直连收付通/直付通分账系统，主要原因是考虑资金安全、系统稳定、用户体验；
资金安全：大平台，不跑路；
系统稳定：正规支付平台系统稳定；
用户体验：三方公司支付有的要唤起小程序，链路慢，体验差；
规划节奏：【一期】接通微信境内收付通，【二期】接入微信境外收付通，【三期】接通支付宝直付通；
接下来是协调资源进行推进…..
如何推进：道和术的层面；
道 – 联合各部分，达成一致目标；
首先是部门内部向上拉齐leader、总监等，其次是拉通财务、业务核心部门目标，最后拉其业务各部门共同目标；
开发资源如何协调：
p：分两部分内力和外力
r：①内力就是我在一直推进，调研，宣导，排期。
②外力是微信主动联系我司推广接入收付通，否则有下架支付渠道的风险，另外是一些被处罚的新闻。
P：所以就很快拿到开发资源。
如何推动项目（术）：
1、制定明确的目标和规划：确保项目具有明确的目标，并根据项目规划制定详细的计划和时间表；
目标：帮助公司规避二清风险，保障支付渠道的正常收单；
节奏：【一期】接通微信境内收付通，【二期】接入微信境外收付通，【三期】接通支付宝直付通；
2、分配任务和责任：将项目拆解成具体的任务，并明确每个人的责任和角色。
比如：申请平台商户号，由财务部门负责，具体到某某，什么时间节点完成，目前进度；
3、管理沟通和协作：建立良好的沟通渠道，确保团队成员之间能有效地快速沟通；
比如：统一大群，每天日会，每周有周会，遇到问题及时沟通处理；
业务流程 – 产品架构：
业务流程：平台申请资质（微信服务商） – 商家开通微信二级商户号 – 用户下单支付 – 系统分账补差 – 出结算账单 – 商户对账确认 – 提现结算；
系统架构图：
表现层： 收银台
业务层：商户开户管理、分账系统、结算系统、对账系统、提款系统、保证金系统；
数据底层：商户、商品、订单、支付、财务；
信息架构 — 具体功能：产品流程
产品list
二级商户进件（开户）流程图：
商户在后台填写对应资料、授权平台申请商户号、提交微信审核、商户进行签约确认、商户进行账户验证、开通成功；
分账流程图：
用户支付时打上分账标识，支付后先做资金补差，然后做准实时（支付成功后30s）分账（冻结），提现时做分账解冻；用户退款时先做分账退回，然后在退款给用户；基于平台对于二级商户实现账期和平台抽佣、分润等诉求，平台收付通提供分账能力。二级商户发起交易时，可授权平台传入订单需要分账的标识，交易资金进入二级商户账户并处于冻结状态（默认冻结180天）；平台向微信支付发起分账指令，微信支付根据指令对指定交易订单进行分账处理，并进行交易资金解冻，从而实现二级商户的账期和抽佣、分润等场景；（默认最高分账比例30%）支持一笔订单多次分账，同时支持分账回退功能。对于平台营销补贴的场景，支持平台补贴资金转入二级商户账户后，再进行统一分账。
pop海淘境外流程：这里不做过多补充，主讲国内业务
业务资金流：
支付流程：
为什么要更换支付sdk：
因为原接入的微信支付SDK，是支付收单到平台申请的普通商户号，然后再给商家清结算；
现在接入微信收付通分账系统后，商户号变成服务商模式，支付收单到对应二级商户号里，但平台有购物车需要不同店铺间的商品合单支付，所以需要更换新的合单支付sdk满足业务场景；
更换之后：有原来的一个父单对应一个流水号，变为现在的每个子单对应一个流水号；
目前平台仅支持两种支付方式，微信和支付宝；
支付路由：①一层是优先微信，后支付宝； ②二层是依据用户上次使用的方式，推荐下次路由；
补差系统：
补差和补差退回
平台的补贴（平台承担的费用）都要补差，比如平台优惠券、现金券等； 举个例子：商家1有个商品a售卖100元，平台发了一张满100-10元的优惠券，承担方为平台，用户实际支付90元，但订单的分账基数是100元，所以要补差10元，然后在分账；若用户发生退款，还有补差退回； 而且补差金额是从运营账户扣除，需要平台预先充值；
退款：
退款是资金流的逆向，原则是资金入哪里，从哪里出；比如：用户支付后，资金会分账进入三个账户（平台、商户、微信），退款逆向要从三个账户分别退回的入金，以及有补差金额的回退；
退款失败的处理逻辑：
①比如平台账户资金不足，退款失败订单挂起，待充值资金后，重新申请；
②比如用户微信账户异常，退款失败，支持用户更换账号；
异常场景：确认收货后发生退款如何处理：
①调用商家账户资金，进行退款；
②若商家账户无资金，调用平台指定账户垫付账户资金；然后在找商户进行垫付回补（从保证金账户扣除）；
另外：当二级商户退款账户余额不足时，可发起垫付退款，从电商平台指定账户垫付退款资金。当二级商户退款账户余额充足时，可把退款垫付的资金回补到电商平台账户。垫付退款需要向微信支付申请开通权限，开通权限时需要指定一个垫付出款账户。
分账系统：
1、记录分账过程：每笔订单分账的走向，比如某个商户，某个订单分账的明细；
比如小A支付成功一笔订单，支付金额、商户留存金额，分账时间，分账明细（微信的手续费、平台的佣金、商户的余额）；
2、分账退回：某一笔订单用户发送退款完成，需要分账退回，退回时间，退回账款的来源等；
结算系统：
结算系统主要是给商家做资金清结算的，统计每笔订单和退款的资金流水明细，汇总生成账单；
结算模式：抽佣结算、供货价结算；
结算系统关联到：支付系统、订单系统、开票系统、提现系统；
结算周期：周结和月结；
结算数据统计：确认收货的订单 – 退款完成的订单；
结算状态：待结算、已结算、无需结算状态；
结算流程：到结算周期系统生成结算账单，财务审核，商家审核对账，确认无误发起提现，生成提现单进行打卡，申请佣金发票；
账单模块：
一、佣金汇总表：
二、发货明细表：
1、规则：数据统计发货节点
2、字段：子订单、下单日期、发货日期、支付方式、商品、数量、商品销售金额、优惠券优惠平台、优惠券优惠商家、促销平台、促销商家、订单销售金额、运费、结算基数、佣金率、平台抽佣、手续费、结算金额、应付金额；
三、退货订单明细表：
1、规则：数据统计退货完成的节点；
2、字段：子单、退货单、退款单、退款时间、退款方式、商品、退货数量、实际退款金额、结算基数、退货优惠平台、退货优惠商家、促销平台、促销商家、退货佣金、退手续费、退货结算金额
四、补偿、运费、商家惩罚等；
账单状态：待业务审核、待财务审核发布、待商家对账确认、商家已确认、商家退回
提现
1、商家申请提现；
2、 生成平台应付单、财务申请付款，生成付款申请单，财务付款；
3、财务手动打款、推送nc付款；
4、微信自动打款；
开票
1、商家申请开票；
①维护开票基本信息；②根据账单选择应该开票的数据；③提交申请发票；
发票状态：待申请、待审核、开票中、已开票、开票异常；
2、平台开票；
3、财务系统开票，线上电票；对接的国信电子票据平台信息服务有限公司
如果再次迭代的话，会有以下思路？
p：设计动态周期系统、商家账户系统，提升商家体验；
r：现在阶段只是完成了业务闭环，给商家出账单，商家可提现；但问题是出账周期长，打款审核周期长等；
e：
动态账期系统：根据不同商家的入驻时间、店铺评分等综合评定，不同商户的不同账期，而不是统一标准；商家账户系统：有了账户系统，就可以给商家根据周期每日出结算账单，每日汇总金额到账户系统，商户可对账户实时提现；减少打款审核周期，做到系统自动对账单，减少财务人员的人工操作；
p：总体看可以极大提升商户体验，目前我们已经规划了，准备推动这个项目；
项目最难的地方
p：项目的开发资源，以及业务侧的支持；
r：①由于项目是风控类项目，开发资源占用非常多，且暂时不做影响也不大；所以优先级一直很低； ②由于不能帮业务直接提供赋能，还要协助我做事，所有就很难推进；
p：如何解决的呢？①需求优先级低，咱就一直持续推进，给产品组长、产品总监普及二清的风险，并举实际罚款案例给他们；持续推进几个迭代终于拿到技术资源；②业务方协助，拉着产品老大和财务老大，向业务老大一起汇报这事，得到业务老大支持，那业务部门人员就很好的协作；
p：结果：微信支付侧已全部对接完成，业务也非常配合推进，商家开通率95%；
另外：文中提到的prep，是指point/reason/example/point，是一种结构化表达的方法：结论、原因、举例、汇总；
日常分享一些电商相关的心得和体会，一起成长；
本文由 @阿辉 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务