產品經理要如何應對商戶支付難題，提升商戶體驗？這篇文章裏，作者從收單機構的角度深入解讀商戶賬戶體系，一起來看看本文梳理的體系架構。
支付是所有商業模式的剛需，作為產品經理你是否想輕松應對商戶支付難題，提升商戶體驗？我們今天就從微信、支付寶等收單機構的角度，為你深入解讀商戶賬戶體系。讓你在搭建過程中少走彎路，為商家提供更為流暢、高效的支付體驗。
如果覺得比較啰嗦，建議直接翻到最後第六節看總結。
一、商戶賬戶介紹
圖1：商戶服務流程
商戶的服務過程還是蠻長的，主要分為事前、事中、事後三個階段；
1）事前階段：
包含了三個步驟「商戶進件、商戶稽核、商戶對接」。其中「進件」就是送出資料給金融機構申請處理。稽核透過就會給商家開通賬戶進行收款。開通後如果是線上場景的商戶需要接入開發，線下場景的商戶需要申請支付機具和物料。
2）事中階段：
包含了支付和交易風控，這兩個過程商戶系統主要是輔助作用。支付過程需要獲取商家的簽約產品、繫結銀行、資金賬戶號、對敏感資訊進行加解密。風控過程需要對商戶操作、賬戶交易風險進行辨識，防止盜卡盜刷。
3）事後階段：
包含了結算和商戶操作。商戶可以選擇自動結算和主動提現，同時也在商戶系統中進行日常的交易、賬戶、產品的管理操作。
二、系統架構設計
1. 客戶、使用者（會員、商戶）和賬戶
如果剛接觸支付，你肯定被「會員、商戶、客戶、賬戶」一堆名詞搞暈過。所以搭建商戶系統之前，我們先把一堆概念給大家做個辨析。
1）使用者視角：
會員、商戶其實都使用者的身份。例如你在電商平台銷售商品收到錢你就是商戶（賣家），你下班了去買買買你就是會員（消費者）。
（註：由於會員概念在支付行業沿用以久，為了保持統一，本文所指會員如沒有特殊說明是對「商戶、會員」統稱。）
2）客戶視角：
客戶是個社會層面的管理視角。例如你要入職一家公司、日常工作和商務交流、去政府部門辦事他們只關心你身份證上的客戶資訊，而不會問你微信昵稱這樣的使用者資訊。
3）賬戶視角：為不同使用者存放資金和資產就是賬戶。
把以上會員、商戶、賬戶統一管理起來的系統的就是一套客戶系統。因此介紹商戶系統層面的設計，你得先了解什麽是客戶系統。
圖2：客戶系統的三個視角
2. 賬戶組織架構
在討論客戶關系的時候，必須要明確在什麽樣的組織架構關系下來開展業務，因為組織架構決定了你的業務模式。組織架構必須要清晰而明，否則業務開展就會職責不清亂七八糟。
我們采用了C端為個人使用者，B端支持特約商戶、服務商的SaaS賬戶組織機構。如果收單機構多個分支機構或者多個業務線來單獨管理商戶（例如有卡收單和網絡兩個牌照），可以透過調整商戶歸屬的組織來管理。
這個架構兼顧個人和商家賬戶體系，同時透過賬戶授權的方式支持「平台商、服務商」的SaaS賬戶模式。這種方式主要被微信、支付寶、飛書等大型平台所采用。
圖3：SaaS賬戶組織結構
3. 架構位置
圖4：客戶系統在支付架構中的位置
在整個支付架構中，我們可以看到客戶系統緊挨著「閘道器、交易、賬戶」，他是客戶管理的核心系統，我們平時所說的各種賬戶、錢包其實都是客戶系統對外的一層業務展示。
1）閘道器與客戶
閘道器是把客戶系統的能力開放給外部商戶使用，包括了登入、註冊、開戶、資訊修改、余額查詢等。
2）交易與客戶
交易系統在使用者進行支付時驗證客戶身份、簽約產品或綁卡資訊、獲取付款賬號。
3）賬戶與客戶
賬戶分為客戶賬戶和內部賬戶，客戶系統就是客戶賬戶的外層包裝。他包括了賬戶的開銷戶、充轉提和資金結算。
4. 業務架構
圖5：客戶系統業務架構
從整個業務架構來看，這是一個標準的B2C/B2B結構的客戶系統，包含了使用者端的會員和商家端的商戶。客戶系統內部份為四層「會員套用、會員閘道器、客戶系統、公共設施」。
2.4.1、會員套用：
會員套用提供給最外層的app和網站套用，最常見的就是面向C端的錢包套用和面向B端的商戶服務平台。
2.4.2、會員閘道器：
閘道器是一層對外開放的客戶API，他作用就是把賬戶能力輸出給SaaS平台、交易平台，讓賬戶能力嵌入到場景的流程中使用。使用者無需持有牌照也能具有持牌機構相似的賬戶能力。
2.4.3、客戶系統：
客戶系統是這裏的最重要的內容他分為了三部份，「使用者管理、商戶管理、客戶管理」三部份。
1）使用者管理 ：這是面向個人錢包使用者的核心服務。同時會員帳號也是個人、企業、商戶對外統一存取的帳號。
2）商戶管理 ：是面向B端商家的管理服務，為商家提供「交易管理、產品管理、賬戶管理、操作員管理、許可權管理」等商戶的套用服務。
3）客戶管理 ：這是為了統一客戶身份管理，也是為了提供金融客戶的KYC/KYB的客戶身份辨識，以及風險合規的統一管理。
2.4.4、基礎設施：
這是客戶系統的相關的公共基礎設施，包括「認證服務、標記化服務、賬戶關系管理、產品配置、通知類套用」等。
三、客戶體系設計
1. 用例模型
圖6：客戶系統用例模型
3.1.1、客戶系統邊界
1）「會員服務」是統一接入
會員服務對接來自「會員閘道器、收單閘道器、交易系統、錢包套用、商戶平台」的所有的外部套用請求，透過會員賬號對系統內的所有用例進行存取。
2）實名認證
實名認證模組配合使用者管理對錢包會員、商戶、操作員等進行營運商的認證，包括手機號、身份證、銀行卡的認證和綁卡。
3）登入驗證
登入驗證負責操作員、聯系人的統一登入、密碼管理，以及初始化他的存取許可權。
4）客戶管理
客戶管理系統統一客戶身份，並與風控和反洗錢系統對接，對資訊進行KYC認證和風險標簽辨識，必要時進行商戶風險處置。
5）簽約產品
客戶系統需要存取產品管理系統來進行產品簽約和配置，並且校驗產品對應的協定關系、綁卡關系等。
6）資金賬戶
客戶系統也為使用者提供開銷戶、賬戶操作的服務。
3.1.2、使用者管理
客戶系統核心是使用者管理（也叫會員管理），可以看到使用者系統是圍繞使用者使用的角度來組織和管理各類服務的。這也是以真正使用產品的人為核心的一種服務理念。
3.1.3、客戶管理：
客戶資訊將客戶身份唯一身份進行了統一的管理，這樣有利於內部份支機構管理、合規KYC管理的風險辨識和控制。
3.1.4、商戶管理：
商戶管理是客戶入網後，為其提供交易、結算、賬戶、操作員等管理功能。
2. 數據模型
3.2.1、客戶ER模型
圖7：客戶ER模型
我們客戶系統的數據模型，是按照三戶模型的範式來進行設計的，其中三個主要物件是「客戶、使用者、賬戶」。其中使用者又分為「會員和商戶」。
3.2.2、客戶模型的主要規則
1、客戶模型規則
1）統一客戶資訊：客戶數據只有一份，他分為個人客戶和企業客戶，他存放了客戶所有的KYC資訊。
2）客戶資訊合並：如果有多場景的使用者資訊，數據需要合並到客戶系統內。
2、使用者模型規則
1）使用者分為會員和商戶，會員預設是個人使用者，企業預設是商戶。
2）會員賬號：使用者使用統一的使用者賬號（即使用者賬號）。
3、賬戶模型規則
1）個人賬戶：預設開通「一般戶」；
2）企業賬戶：預設開通「一般戶、結算戶」。
3. 控制流程
圖8：客戶系統主流程
客戶系統的規則很多，我們把核心的主流程分成四種場景給大家介紹下。
3.3.1、客戶進件流程
1）使用者賬號存取：客戶進件時先建立使用者賬號，首次註冊將建立統一客戶資訊。
2）客戶資訊合並：建立賬號時，若已有客戶資訊，則按同一法人資訊合並。
3）開戶方式：開戶分間接和直接兩種，間接是商戶簽約產品後開戶，直接則是開通錢包產品時預設開戶。
3.3.2、客戶支付流程
客戶支付流程主要進行以下三方面的處理。
1）驗證客戶身份：
使用者支付前或者支付中，都要透過使用者賬號存取客戶身份來驗證客戶許可權和風險，如果透過才能讓客戶繼續支付。
2）獲取產品資訊：
下單前需要透過使用者賬號獲取商戶的簽約產品資訊來展示收銀台。使用者選擇支付產品後要獲取商戶號對應的協定號來完成支付。（微信、支付寶是獲取openid，快捷是簽約協定號等）
3）獲取賬戶資訊：
進行收款和付款時都要獲取賬戶資訊，這個過程同樣也要判斷賬戶的狀態是否止入/止出/釘選。如果校驗透過才能進行支付。
3.3.3、風控處置流程
接觸過微信、支付寶風控的同學可能知道，他們了解你所有賬戶的風險情況，可以對你單個賬號風控，也能對你所有賬號進行風控，一個賬號出現風險會對相關的其他賬戶進行警告。 這就是統一客戶身份的作用，你的任何一個賬戶的風險資訊，都會影響你整體的風險評級 。
平時只對單個使用者賬號（使用者）進行交易辨識和攔截。如果要進行全面風控，透過統一客戶資訊將關聯同一法人下的所有賬戶，全部進行統一風控。
4. 使用者授權模式
為了實作有大量消費者和商戶的SaaS平台和電商平台使用者入駐，需要透過產品授權來建立上下級關系，因此采用了四種授權角色「會員使用者、特約商戶、平台商、服務商」。
3.4.1、四種授權角色
1）會員使用者： 這類屬於直接在支付機構開通錢包賬戶的使用者。比如我們在微信、支付寶開通的錢包一樣。
2）特約商戶： 這類屬於直接在支付機構開通支付產品的商戶，例如我們在微信、支付寶申請碼牌收款時開通的商戶賬戶。
3）服務商： 主要面向不同行業的SaaS平台，他們有大量小商家入駐，為這些小商家提供小程式、公眾號、企業網站等服務。例如有贊、付唄、小程式電商等。這類平台的特點是支付產品需要小商家自己去申請，然後授權給服務商。
4）平台商： 主要是面向電商平台這類既有商家、又有消費者的平台。例如淘寶、美團、抖音、快手、拼夕夕等。這類平台的特點是平台統一申請支付產品後共享給平台內的使用者使用。
下面我們來介紹下這四類角色的區別：
圖9：四種授權角色
3.4.2、授權處理流程
圖10：授權處理流程
商戶之間的授權關系主要是「平台商、服務商」這兩種角色。
1）平台商共享模式：
平台商戶需要申請特約商戶，平台申請的支付產品可以共享給入駐商家使用。並且這些商家開通的支付產品都是平台提前申請好的。
2）服務商授權模式：
服務商先申請特約商戶，並對接支付機構SaaS平台。然後引導子商戶線上入駐、簽約產品，並授權給服務商。支付機構為子商戶完成開戶後，服務商可為子商戶提供支付結算服務。
四、商戶端的進件設計
有了上面設計思想的鋪墊，我們來看下具體的商戶端進件是如何處理和展示給使用者使用的。商戶進件主要分為「商戶入駐、商戶登入、找回密碼」三部份。
圖11：商戶端功能清單
1. 商戶入駐流程
商戶入駐細分為「商戶開戶、修改資訊、修改綁卡」三個子流程。
4.1.1、商戶開戶流程
4.1.1.1、商戶開戶流程：
圖12：商戶開戶流程
商戶開戶流程分為五個階段，操作員註冊、商戶實名、統一客戶身份、產品簽約、賬戶開戶。
1、操作員註冊
商戶分為個人、個體、企業三類，他們登入註冊的賬號都是操作員身份，透過操作員來開通商戶賬號（即使用者賬號）和申請支付產品。
2、商戶實名和簽約產品
商戶填寫實名認證資訊、選擇簽約產品、送出對應經營資料後，需要送出後台進行稽核。
3、統一客戶身份
商戶資訊稽核透過後如果是新增商戶會建立和登記「客戶資訊」，如果是增量商戶會將他的客戶資訊進行合並，進行客戶的統一身份管理。這個過程都是系統自動完成的。
4、產品簽約配置
稽核透過後需要有後台營運人員給產品進行簽約配置。
5、賬戶開戶和啟用
稽核送出後就自動開戶，但是此時只是「待啟用」，等到使用者完成打款，賬戶就可以正式啟用。
4.1.1.2、商戶送出資料
圖13：商戶送出資訊和資料
商戶按照角色分為「小微（即個人）、個體、企業」三個主要類別。不同角色送出的資料、申請的產品，結算卡也各不相同。
小微申請的產品最少，但是可以繫結個人結算卡；個體的特點是既可以結算到對私法人卡，也能結算到對公企業戶；企業的稽核是最嚴的，申請的產品也最多，但是必須結算到對公賬戶。
4.1.1.3、商戶開戶互動
講了這麽多設計和流程，我們來點互動切實感受下一個商戶到底是怎麽完成一個開戶的吧。
圖14：商戶開戶互動主流程
如果你第一次在三方平台上申請支付產品，你首先需要註冊申請一個可以收款的商戶賬戶。這個過程你要經歷「操作員註冊、商戶資訊填寫、賬戶啟用、簽約確認」四個步驟。下面我們來分別看下對應的頁面是什麽樣子。
4.1.1.4、商戶申請單
商戶申請過程有「實名、啟用、確認」三個過程，並且每個過程都有重新填寫和修改，因此為了讓商戶能夠順暢的完成各種操作，需要設計一個「申請單」將商戶的整體流程進行串聯起來，在商戶被駁回，商戶延期送出等情況下都能讓商戶重新進行處理。
1）申請實名認證：
申請單分為「實名認證、賬戶啟用、完成簽約」三個步驟；
實名認證階段，使用者可以查詢稽核進度，如果申請被駁回，會郵件或者短訊通知客戶，客戶登入後可以透過申請單檢視駁回資訊，並繼續修改申請資訊。
圖15：實名認證申請
2）賬戶啟用處理
實名認證透過後，企業對公賬戶由於不能像快捷一樣透過銀行短訊驗證碼綁卡，因此需要透過開戶行做打款驗證，完成賬戶的繫結和啟用。如果未在規定時間內完成當前申請將作廢，需要重新送出實名認證資訊。
圖16：賬戶啟用申請
3）簽約結果確認
完成賬戶啟用後，需要商戶確認簽約產品和授權資訊，然後就能開始使用賬戶了。
圖17：完成簽約
4.1.1.5、商戶資訊填寫
有了閉環的管理，下面最重要的就是填寫申請資訊了，商戶的申請資訊要填寫的資訊還是比較多的，其中申請不同的產品、不同的行業，需要送出相應的資訊和影像資料，填寫完成後送出後台進行稽核。
1）商戶主體和聯系人
首先要選擇對應的主體，主體類別分為「個人、企業、個體」三個主要類別。如果是企業和個體，需要送出營業執照資訊。個人商戶需要填寫和上傳身份證資訊。
聯系人一般是預設註冊時送出申請的者資訊為聯系人，同時他也是系統的預設管理員角色。
圖18：填寫主體和聯系人資訊
3）法人資訊填寫
企業申請開通商戶賬戶需要填寫法人資訊，如果是個人法人就是其本人。
圖19：法人資訊填寫
4）場景和申請產品
下面就來到了最重要的一步，商戶資訊和簽約產品的申請。這裏需要根據申請的產品，送出對應的場景資料，並且也要填寫自己所屬的行業資訊，以便於進行不同的風險辨識。這裏的場景資料是整個申請是否能夠順利透過的關鍵，也是稽核最為嚴格的部份，因此一定要準確的填寫。
圖20：產品申請和場景資料送出
5）結算資訊填寫
商戶收錢後結算到什麽銀行卡，就需要填寫結算資訊。
圖21：填寫綁卡和結算資訊
6）補充資料填寫：
一些特殊行業例如醫療、教育、公共事業、社會福利、金融等需要有特定資質，因此在場景稽核的標準資料之外還要填寫送出補充認證資訊。當然送出補充資料的場景不限於此，對於稽核員有異議的地方都可以透過補充資料來送出。
圖22：補充資訊送出
4.1.2、商戶資訊修改流程
商戶的資訊送出後有很多情況下需要修改，例如申請時稽核被駁回、註冊後需要申請新的支付產品、需要補充實名認證資訊等。這些場景都會涉及商戶資訊的修改。
所以商戶資訊的修改可以在入駐的時候發起，也能在商戶平台上發起。他主要分為「使用者資訊修改、客戶資訊合並」2個必選流程和「新增簽約產品、新增開戶」兩個可選流程，當然每次修改都需要後台稽核透過之後才能透過。（詳情見下圖）
圖23：商戶資訊修改流程
4.1.3、重新綁卡流程
在商戶場景下，申請的卡主要是結算銀行卡，一般情況下一個結算賬戶只能繫結一張結算銀行卡。當卡異常的時候就需要商戶重新繫結。為了避免商戶損失，繫結的結算銀行卡需要與商戶同名，並且要進行實名認證、商戶主動確認。
對私卡的主動確認是透過快捷的開戶銀行短訊驗證碼來完成。企業賬戶要復雜些，實名認證需要人工稽核，並且機構要隨機金額打款確認賬戶是可以正常結算的。
圖24：重新綁卡流程
2. 商戶登入流程
4.2.1、登入主流程
商戶註冊成功後你就可以登入你的商戶賬戶進行操作了，登入過程會有三種情況。「直接登入、多法人登入、密碼重設」。處理流程見下圖。
圖25：登入主流程
4.2.2、登入和多法人登入
商戶登入實質上是「操作員」登入。當操作員輸入註冊時所用的登入賬號（本例中為手機或郵箱）時，需考慮到現代企業的復雜結構，特別是擁有多個分公司的企業。在這樣的背景下，操作員可能需要跨越不同的法人商戶進行操作。因此，在登入設計時，務必融入多法人登入的功能。
在單一法人情境下，系統應預設直接登入以簡化流程。然而，當操作員面對多個商戶賬戶時，系統應提供多法人登入選項，允許他們從中選擇一個特定的商戶賬戶進行登入。這樣的設計既滿足了企業的實際需求，又提升了操作員的使用體驗。
圖26：商戶的登入和多法人登入
4.2.3、操作員密碼找回
圖27：密碼找回
操作員找回密碼是一個兜底流程，在操作員忘記密碼的情況下提供密碼的重設處理。我們這裏的密碼重設需要透過註冊時的手機號或者郵箱獲取啟用碼，輸入無誤後才能進行密碼重設。
五、營運端管理設計
介紹完了商戶端的流程和互動設計，我們再來介紹下神秘的商戶的管理後台。
圖28：營運端客戶管理的整體互動
客戶管理包含了「客戶管理、商戶稽核、會員管理」三部份，其中 「使用者管理」是銜接內外部客戶管理的核心內容，他對外承接「客戶申請」的接入，對內與「客戶管理」協作進行KYC管理 。
圖29：營運端功能清單
1. 使用者管理
會員管理包括「個人會員、商戶管理」兩部份內容。我們前面也介紹過了，企業預設就是特約商戶，因此它屬於商戶管理的內容。
5.1.1、商戶稽核
收單機構日常營運做的最多的事情就是每天稽核商戶的註冊申請，對商戶進行KYC稽核，為商戶配置支付產品、開通賬戶盡快的開展業務。這個過程效率越高自然就越快賺到錢。
圖30：商戶稽核功能
商戶稽核功能是提供給稽核員使用的，稽核員可以透過工作台訊息通知和主動查詢的方式處理客戶的申請單。
圖31：稽核的四個步驟
整個稽核過程有四個步驟組成「商戶稽核、合規稽核、產品配置、完成開戶」，其中前三個步驟一般需要人工介入稽核，稽核完成後的最終開戶由系統根據使用者啟用操作後自動完成。
5.1.1.1、商戶稽核詳情
1）客戶基本資訊
首先是對客戶送出的基本資訊進行稽核。在這裏我們可以看到「使用者賬號」和「企業基本資訊」部份，這裏的使用者賬號就是客戶未來會開通的商戶賬號。企業資訊將來會登記到客戶資訊中，進行統一的辨識。
圖32：客戶基本資訊
2）證件稽核資訊
前面商戶送出的影印件資料也會同步傳給後台稽核人員進行稽核。
圖33：證件資訊稽核
3）操作員資訊
操作員就是填寫申請單的使用者，預設是當前申請者的資訊。
圖34：操作員稽核
5.1.1.2、合規稽核詳情
客戶基礎資訊稽核透過後進入下一個稽核節點「合規稽核」，合規稽核包括了申請的「簽約產品、場景資料、結算銀行」等場景資料。
1）經營場景稽核
前面介紹了，這部份是稽核的重點，因為申請什麽樣的產品，就要提供對應的場景資料和備案資訊。經營資訊的稽核包括場景的稽核，簽約產品的覆核。如果場景和申請的產品不符則會被合規駁回。
圖35：場景資料和簽約產品稽核
2）綁卡和結算稽核
商家的繫結的銀行卡是用來結算的，因需要設定它的結算方式和結算周期，一般情況下這些結算方式都是預設的「自動提現、D1結算」。
圖36：綁卡和結算資訊稽核
5.1.1.3、產品配置詳情
1）簽約產品配置
合規稽核之後就會轉到營運部門進行產品配置、費率配置。這裏也是比較麻煩的，因為中小支付機構很難像微信、支付寶這樣統一產品、費率。需要營運人員根據申請的產品和簽約的合約來逐項進行核對配置。
圖37：簽約產品配置
2）賬戶開立設定
完成配置後就是開通賬戶，賬戶一般都是預設的，收單開通結算賬戶、付款開通一般賬戶。
圖38：開通賬戶配置
5.1.2、商戶管理
5.1.2.1、商戶管理列表
對已經入網的特約商戶、服務商、平台商戶進行管理。這裏企業預設就是商戶，個人商戶只有透過平台商、服務商才能入網。企業要跨法人入駐其他平台服務商，需要重新註冊一個商戶賬戶。
圖39：商戶管理功能
從上圖商戶入網的形式有以下四種情況：
1）特約商戶入網：入網的商戶均為企業使用者，收款開通一般戶、付款開通結算戶。
2）平台商：平台商戶首先要入網開通一個特約商戶，然後申請產能為平台商戶，隨後引導平台內的商戶和消費者註冊開通賬戶，平台商戶申請的支付產品可以共享給入駐的消費者和商家使用。
3）服務商：服務商也是需要先入網開通特約商戶，然後引導子商戶透過服務商平台發起產品申請，申請透過後把產品授權給服務商使用。
4）商戶跨法人入駐：如果一個商戶需要在其他服務商平台註冊，需要重新申請一個特約商戶然後授權給服務商。
5.1.2.2、企業商戶詳情
企業預設是特約商戶，他只是因為授權關系不同形成了平台商、服務商、子商戶的關系。
圖40：企業商戶詳情
從上圖看到，企業賬號是透過「會員賬號」來統一管理的，然後關聯「客戶資訊、操作員、經營資訊、銀行卡、結算資訊、簽約產品、賬戶等資訊」；
1）會員賬號：會員賬號管理著「客戶、產品、賬戶」三者間的關系。
2）客戶資訊：這裏商戶客戶資訊是透過會員賬號關聯的統一客戶號從客戶系統查詢過來的資訊。
3）登入資訊：操作員、登入號、登入密碼等登入資訊
4）簽約產品：簽約產品由商戶自行申請，自己使用。
5）資金賬戶：根據企業商戶簽約產品開通資金賬戶，收款預設開通結算戶、充轉提和付款產品預設開通一般戶。
5.1.3、個人會員
個人會員主要是開通個人錢包的使用者，個人錢包使用者按照個人支付賬戶進行實名認證。由低到高分為三類，其中等級最高的是III類賬戶，需要五條實名認證通道，年交易額可以20w，同一人最多開五個賬戶。
圖41：個人會員錢包賬戶管理
2. 客戶管理
5.2.1、客戶管理
對客戶的統一身份進行內部管理，可以按機構內部的組織架構來管理客戶，有利於績效考核，分片區管理和統一的客戶身份辨識、風險控制。對於集團型客戶，透過組織架構對客戶總部和分公司之間也能進行統一的管理。
圖42：客戶管理
從上圖可以看到，客戶資訊不僅包含了入網稽核時填寫的資訊，還包含了風險等級和客戶評級，透過這種方式可以對客戶風險和行為進行更加有效的辨識和管理。
5.2.2、客戶詳情
客戶資訊需要統一身份登記，因此多個商戶、會員的資訊都會統一合並為一套客戶資訊。客戶的風險等級、客戶標簽也能進行統一的收集和管理。
圖43：統一客戶資訊
如果客戶申請了多個會員和商戶，可以透過關聯會員來進行查詢和管理。
圖44：關聯使用者資訊
5.2.3、風控處置
如果同一客戶出現了風險時間，可以透過客戶管理，發起批次和指定會員的風險控制管理，可以及時的對風險時間進行快速和準確的處置。處置結果也會自動透過郵件發送給商戶。
圖45：客戶風險處置
六、商戶賬戶總結
SaaS商戶賬戶的內容非常多，總結下來就是「3個戶、3套資料、3個流程、4個商戶角色」。
1. 三個戶
附圖1：三個戶之間的關系
6.1.1、客戶模型規則
是內部管理的視角，其目的是為了KYC合規辨識，以及內部組織機構對統一客戶能夠進行銷售和代理的績效考核、成本統計。
6.1.2、會員模型規則
1）會員就是使用者的角色，他包含了個人會員、商戶兩部份的角色。
2）會員賬號是使用者統一使用的「使用者賬號」
3）企業預設就是商戶，因此不嚴格區分企業會員和商戶。
6.1.3、賬戶模型規則
開通的賬戶與會員的角色有關系：
1）個人會員：開通一般戶，賬戶要按照個人支付賬戶按照「三級分類」來做實名認證和限額管理。
2）企業/商戶：按照申請的支付產品來開戶，申請收單產品開通「結算戶」、開通錢包和付款產品開通「一般戶」。
2. 三套入網資料
附圖2：三套入網資料
3. 四個商戶角色
商戶的各種復雜場景，透過四個授權關系來進行管理。
附圖3：商戶的四種授權關系
4. 三張流程圖
1）開戶流程圖
附圖4：開戶主流程
2）修改流程圖
附圖5：修改主流程
3）換綁卡流程圖
附圖5：換綁卡主流程
作者：剛哥，公眾號：剛哥白話
本文由 @剛哥 原創釋出於人人都是產品經理，未經授權，禁止轉載
題圖來自Unsplash，基於CC0協定
該文觀點僅代表作者本人，人人都是產品經理平台僅提供資訊儲存空間服務。
