起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識“二清”影響的清結算系統重構
現在的網絡支付，不少都是從用戶先到平臺，再由平臺結算給商戶，形成了事實上的“二清”。這種情況下，產品和系統該如何設計呢？這篇文章，我們來學習一下
什么是二清：二清就是無支付牌照的公司，沒有資質做資金的二次清結算； 像我司電商業務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協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論，等你發揮！
