支付業務體系之會員系統
很榮幸給大家做這次的分享。我先自我介紹一下，我叫龔正，目前在滴滴金融工作。也是剛來不久，之前在美團和美麗說做支付相關的工作。所以今天 給大家介紹一下支付業務中支付會員相關的內容。
我們都知道，支付體系中 如何識別一個用戶 是有多種策略的。第三方支付也好 電商也好。但是這個維度的不同所建立的會員體系也是不同的。一般看來 第三方中的支付會員體系獨立于 電商等業務，所以 我們下面對三個方面進行講解：
業務系統在接入支付系統后，一般來說是需要做一個支付賬戶轉換。會員系統中的會員 代表著這個用戶在支付系統中的唯一身份。而以這個身份來產生的所有信息，都是這個會員的資產。一般來講 一個或多個用戶 對應一個支付會員。
而會員信息 分為兩種：(ppt上不夠細化)第一種是 資產;第二種是 信息。
資產 一般包含用戶的身份信息 昵稱 會員密碼等 也包含用戶的手機號等。
信息一般認為是會員的狀態 如激活 凍結以及他產生的一些動作等信息。
好了 我們對支付會員所擁有的信息有了了解 我們再深入一下 細節：
支付密碼我們都非常的了解，每天都在用。所以我們來聊聊支付密碼。
圖上是我們最常用的支付寶和微信的支付密碼輸入圖。當然還有線下的ATM啦，等等，都在使用6位支付密碼。所以 大家都會有疑問，為什么我們的支付密碼都是六位呢?
PPT中分了三點：防止暴力破解、增加用戶體驗、方便記憶。之前的支付寶以及銀行都嘗試過不同位數的支付密碼，但是由于長度過長的不方便 ，效率低下，長度過短的，太容易破解 ，都使用了6位支付密碼。
一般來說，支付密碼驗證的過程是這樣的：前端通過加密密碼，傳遞到后端解密，然后使用hash算法算取hash值與后端保存的密碼hash進行比較，最后返回成功還是失敗。而在密碼傳輸、密碼hash中，都是用了安全級別比較高的算法。PPT中簡述了一般加密使用的算法。而密碼的保存，一般也是使用隨機鹽的方式，保證會員密碼的安全性。
我們現在使用iphone非常的多 所以指紋支付也是非常的普及。很多android手機也大部分普及了指紋支付，這對我們的用戶體驗有了更大的提升。
指紋支付流程很簡單。通過硬件判斷是否成功，優勢和劣勢大家一想便知。所以，在風控方面考慮。指紋密碼驗證的安全性要低于6位支付密碼的驗證。
手勢密碼我們也很常用。
還有一種是免密支付。雖然不需要輸入密碼 但是依然是通過用戶的行為“指紋”來進行判斷。
實名體系對于支付系統，乃至第三方來講都是非常重要的。
為了保證資金安全，實名對于第三方公司來說，是至關重要的。包括監管要求、用戶安全、以及深度業務的拓展。
第三方支付中，實名賬戶分成三類，每種類型都有不同的限額。
一般支付公司實名主要通過銀行卡、通過銀行通道對用戶進行實名。但是我們發現，越來越多的第三方需要我們傳遞身份證信息，這也是為了增加三類實名的比例。
當然啦，通過其他證件如港澳通行證等，以及 查詢公積金、繳納電費等，都可以實名。
這個是提供實名查詢功能的公司。價格和實名級別都有所不同。
如下案例：
雖然本次分享沒有完全把支付系統中的支付會員相關的知識完完全全的講述給大家，但是從本次分享中 我們也知道了會員系統在支付系統中是至關重要的。
對于我們支付系統的發展 以及配合監管 是不可或缺的一部分。
Q&A
Q：戶賬分離 是怎么做的，電商會員和支付賬戶的分離?
A：根據對支付系統的設計，是通過映射的方式進行分類 電商會員屬于業務，而支付賬戶在支付賬戶里面，根據需求來定。
Q：一個或多個用戶 對應一個支付會員，有例子嗎 ?
A：有些公司是通過自然人來做的。
Q：比如風控系統識別出近期行為接近危險的會員，預先在登錄時就要求驗證 ，有這種流程沒?
A：是有的
Q：會員中的會員，和支付會員的具體區別場景，能不能再列舉下?
A：會員中的會員是業務，可能分了很多類，很多號，但是支付時，對應的號可能會不同，因為支付代表的是資金，二會員是業務。
Q：會員的黑白灰名單機制是在支付會員系統中么
A：這個在風控和會員體系中都有
Q：如果凍結了會員，還會影響正常業務不?交易的資金會走到其他戶里還是怎么處理，可以講下這些么?
A：凍結也分級別,最高的級別是不允許做任何資金操作的,比如監管下發凍結指令，那么用戶的所有資金操作都不被允許。
Q：會員中會員和支付會員，兩套單獨維護?
A：淘寶賬戶和支付寶賬戶應該不是一個吧。
Q：大家怎么看待指紋，不說手機上驗的有多可靠，只說對服務端來說指紋就等同于免密，怎么宣傳上都把指紋看作是個無比安全的東西。
A：指紋確實比較安全，但是由于是手機黑盒，所以對于我們來講，我們沒有辦法防止蘋果偽造指紋。手機root了也可以修改指紋，畢竟返回的只是true和false。
Q：一個或多個用戶對應一個支付會員中多個用戶怎么理解的
A：有些公司的策略不同 有些是按照自然人來看的 有些是業務線不同賬戶 但是支付時是一個的。
Q：那么那種在途交易的資金那樣你們會怎么處理?是會原路返回么?還是會在中間戶? 回答：我一般放在中間戶
自由討論
PM1： 賬戶會有賬戶類型
P2： 比如風控系統識別出近期行為接近危險的會員 預先在登錄時就要求驗證 有這種流程沒
P3： 首先感謝分享，會員中的會員，和支付會員的具體區別場景，能不能再列舉下
P4： 自然人在不同商戶下的支付動作
P4： 應該在第三方支付中對應不同的會員吧
P5： 會員的黑白灰名單機制是在支付會員系統中么
P6： 我的理解，會員就是客戶，一個客戶有多個登錄賬戶也就是用戶，一個用戶又有多個記賬賬戶
P5： 還是常規的會員系統里面
PM1： @龔正 就是你們遇到風控監控異常的時候，會對交易進行凍結，還是會對會員整體的進行異常處理。如果凍結了會員，還會影響正常業務不?交易的資金會走到其他戶里還是怎么處理，可以講下這些么?
P7： @P6 我的理解，會員就是客戶，一個客戶有多個登錄賬戶也就是用戶，一個用戶又有多個記賬賬戶
P7： 我們也是這樣理解的
P3： 會員中會員和支付會員，兩套單獨維護?
P7： 客戶、用戶
P8： 類似司法凍結了 那
P9： [玫瑰]
P10： 大家怎么看待指紋，不說手機上驗的有多可靠，只說對服務端來說指紋就等同于免密，怎么宣傳上都把指紋看作是個無比安全的東西
P11： 一個或多個用戶對應一個支付會員中多個用戶怎么理解的
P2： 會員對應到實名的人 只是個記錄信息 實際操作和業務發生在登錄帳號上
PM1： @龔正，那么那種在途交易的資金那樣你們會怎么處理?是會原路返回么?還是會在中間戶?
P8： 問個支付會計的問題：到會計落分錄，聽大家說一般 是業務屬性+支付賬戶屬性 來確認落到什么科目，你們這層到科目是怎么做映射的?
P10： @龔正?，對啊返回的只是true、false。對于網絡報文來說，只能依賴客戶端不被破解，本質和無密也差不多
P3： 淘寶賬戶和支付寶賬戶應該是打通或者一樣的吧。如果單獨維護，兩套體系會產生一個議題，就是會不會涉及到信息同步的問題?或者說，有些信息，比如userId應該是一樣的，還有實名認證信息，是共享的。
P11 [強]感謝ark的分享和解答
PM1： [強]感謝ark的分享和解答
P6： 支付寶和淘寶不是一個，只是綁定關系
P12： 淘寶賬戶和支付寶賬戶 一個是業務的 一個是底層的
P15：: 聯合登錄后在庫中是怎么存的，這塊能說說么
P8： @龔正 賬戶記賬映射到科目 是怎么做的
P10： 淘寶賬戶和支付寶賬號不同，我猜是個悲傷的故事，不知道有沒有阿里的人
龔正： 聯合登錄后在庫中是怎么存的，這塊能說說么 聯合登錄是什么意思
P6： 支付寶和淘寶是兩個體系，只是賬戶打通
P10： 謝謝分享
龔正： 賬戶記賬映射到科目 是怎么做的 在賬戶中存科目唄
龔正： [陰險]
P16： 淘寶只管訂單方面，支付寶只管支付方面的，這個不沖突吧
P8： 哈哈
P6： 聯合登錄是一種授權登錄
龔正： 淘寶賬戶代表的是電商相關的資產 支付寶賬戶代表自己資產
龔正： 資金資產
P8： 賬戶中直接存了科目?
P12： 支付寶服務對象不只有淘寶 是面向全行業的商家 大家不要搞混淆了
P8： 支付寶是自己的 客戶-賬戶
P17： 淘寶和支付寶做的應該是賬戶互通
P6： 淘寶是阿里巴巴的，支付寶是浙江螞蟻金服的
龔正： 其實我感覺聯合登陸和微信登陸 微博登陸等等差不多吧
龔正： 多個對應一個
P12： 支付會員的場景 只有會員支付嗎?
P3： 好的，學習了。
P18： OAuth2.0 認證授權 挺流行的吧
P19： oauth嚴格意義沒認證 只是授權
P19： 目前最好的解決方案了
P10： 阿里、支付寶都是一家，淘寶可以用支付寶登錄。我行用戶體系被強制統一，理由之一就是阿里兩套用戶帶來許多麻煩
P6： 是一樣的，用戶在微信登錄時再在別的系統登錄，傳密文到目標系統，目標系統找到映射用戶號，查出相關信息，存入緩存
P2： 會員是身份證號 帳號是手機號 業務都發生在帳號上 要封號應該從會員上封
P20： 淘寶和支付寶賬號也沒打通吧?還是需要相互授權吧?
P15： 聯合登后和自有的用戶是分開存的吧?
P16： OAUTH2.0就是單點登錄登錄的一種，不用區分是哪家企業的
P21： 淘寶和支付寶賬號是分開的 有一套映射規則 淘寶uid是底層基礎庫的標識
P16： 你在網易云音樂照樣可以用微信登錄，只要去微信那邊注冊下就行了
P6： 聯合登錄就是一張映射表
P20： OAUTH2.0接入時已經區分接入的是哪家企業了
P8： @P10 “我行用戶體系被強制統一” 能否介紹下這個
P19： oauth聯合登陸 只是授權登錄信息 這算最基礎的應用了
P22： 淘寶和支付寶是綁定關系，且支持多對一的綁定
P20： oauth最終是獲取accesstoken，授權只是第一個階段
P19： 銀行都建有統一會員系統吧
P6： 銀行是cif
P22： 各位是怎么處理金融和支付賬戶的
龔正： [動畫表情]
P18： 支付會員由于人行監管問題，等級上明顯要高于電商會員，通常高等級向低等級上授權， 一個電商會員去了支付系統，沒各種實名認證，啥也不能做。
P2： 風控統計這些要考慮會員下所有帳號了 至于相同會員不同帳號共享登錄這些根據不同公司喜好吧
P22： @龔正?比如信貸業務和支付賬戶的關系有什么建議嗎
P23： 這些會員和電商會員區別在哪里
龔正： 信貸一般是自然人為基準吧
P19： 會員系統 和支付系統 之間 登錄統一授權就好了
P6： 信貸支付兩個業務，支付賬戶用來處理資金轉移通道，如提現，還款
P19： 建立會員系統 和授權中心 通用授權的注冊一次性授予 其他的單獨授權也可以
P19： 有了這個 多少系統 都是一樣的吧
P22： 感覺這樣容易出問題，我們現在好幾款信貸產品，賬戶沒打通，結果部分客戶出現了多頭負債@P6?@龔正?
P22： 當然也有可能是單個自然人沒有最高限額導致的[捂臉]
P20： 肯定是借貸記賬不平導致的??
P24： 淘寶和支付寶是綁定的關系，可隨時解綁和環綁，沒有打通。
P24：
P6： 信貸是基于客戶的，應先建客戶系統，全業務系統共享客戶系統
P20： 是的，都是獨立的
P25： 信貸產品之間互相的關聯關系也有問題
P22： 謝謝幾位，看來我想復雜了
P26： @龔正?請問現在指紋支付這塊，指紋數據都是存在本地，服務端只能授信于硬件，除了授信之外，有沒有其他辦法保證指紋數據正確?謝謝
P6： 信貸產品掛在客戶身上
龔正： 指紋關鍵設備
龔正： 并判斷手機是否root
P24： 金融和支付賬戶打通會有很多麻煩，監管對支付賬戶的各種要求會導致金融產品也得被迫「合規」改造，建議采用綁定方式。
龔正： 目前也只能這樣了
P22： @P6?目前是這么做的
P26： 謝謝
P2： 風控應該控制會員而不是帳號 一個會員小有多個帳號
P18： 會員就是一套系統的用戶體系，電商系統、支付系統、P2P系統一般都獨立會員體系，登錄賬戶可以共享，業務上差別很大的，拆開來比較合適，這樣就不會人行支付監管需求，要影響P2P系統，完全共用的話，就相互影響咯。
P6： 那就是授信問題了
P27： 開始說到在賬戶中存科目，存的是一級科目吧，后面做總分對象平衡用到，這么理解不知道對不對?
龔正： 存的是末級科目
P6： 我們以前的會員體系是分業務的，用戶分主副用戶，副用戶可以用主用戶密碼登錄，用付用戶做業務
P10： 判斷手機是否 root不夠，因為請求可能根本沒來自合法的客戶端，當然這又是另外一個很大的話題
P28： 設備指紋
P24： 指紋支付對風控要求比較高，服務器端要驗證 設備指紋，IP等客戶信息，防偽造，同時要保證網絡傳輸的安全性，防篡改。
P28： 對的
P12： [強]
P18： 一個賬戶的正常資金和凍結資金 你們一般怎么設計的? 一條記錄， 還是分開?
P28： 一個用戶有多個賬戶
P2： 一會員多帳號這樣會大大增加系統的復雜度 實名認證后應該合并成一個帳號 其實最終也是方便用戶
P28： 一個用戶對應多個賬戶
P28： 每個賬戶操作 都會對應相應的分錄
P2： 可以保留登錄用戶名 登錄后操作都在應該帳號上
P6： 賬戶的凍結解凍是有登記簿來管理的
P6： 一會員多賬戶，賬戶實名時只實名當前賬戶，別的賬戶需要歸并或簽權合并，才能合到同一會員下
P29： 支付系統中叫會員合適還是叫客戶合適?
P30： 會員
P2： 允許多帳號實際上是破壞了關系數據庫的范式約定 呵呵 不實名應該不允許產生業務數據 沒實名前的帳號系統應該預留會員關聯位置
P29： 會員比客戶含義貌似寬泛很多
P6： 支付寶的會員含個人客戶和商戶，央行的客戶指個人或買方
P6： 不實名也應該能做業務
P2： 如果帳號下已經跑了業務 那么關聯數據會分散在各個地方 合并時風險就大了
P6： 業務是跟著賬戶的，沒問題
P31： 你們所謂的一會員多賬戶是什么意思，能不能舉個例子
P29： 余額 余額寶
P6： 一客戶多用戶，一個人有多個支付寶
P2： 我說的是理想狀態 實名現在有快捷途徑操作很容易了 用戶有能接受 這樣減輕系統復雜度
P11： 那怎么判斷多個支付寶對應一個人
P6： 理想是這樣的，流程往往是業務說了算啊
P29： 可以用一份實名認證吧
P29： 支付寶是這樣的
P31： 一個人有多個支付寶?跟一賬戶多用戶有什么關系，在銀行卡沒改制之前我一個銀行也有多張銀行卡，關鍵是系統也不見得把我分成一個人呀，都是一對一的關系
P11： 即使實名的話，在數據庫中認定也是不能體現的
P11： 要根據唯一標識查詢才能得到這個結果了
P6： 銀行肯定是一對多的
P2： 風控就有漏洞了 前面敦煌那個人也是
P6： 銀行要cif就是干這個的
P31： 問題是這玩意你們認為的那種一對多有什么好處?
P31： 就好像我在這張銀行卡猛消費，跟我另外一張銀行卡有什么關系
P31： 在銀行卡沒改革之前
P6： 是和你本人有關
P6： 客戶是現實自然人在系統中的建模
P31： 有什么關系，這個資金也不互通，積分也是，活動也是，想不出有什么關系
P6： 信用
P6： 授信，風控都會參考這些
P6： 還有就是客戶行為分析
P31： 那如果你們搞這種一賬戶多用戶的，系統里面單賬戶余額就是所有用戶總額咯
P31： 錯了，是一會員多賬戶，會員余額就是多賬戶總額?
P2： 業務可以存在多個帳號 但第一級關聯必須是會員 之后二級關聯到帳號 也沒問題 說的是理想狀態 不需要合并 但必須明確主體關聯
P6： 當然還有更多，可以這么說:相同姓名+身份證號視為同一個人，不論在哪個系統里，都是現實中的你，你在中行上了黑名單，招行也不會給你做業務
P29： 余額好像一般是分開的，額度是一起共享的
P6： 余額是另一個概念，資金賬戶
P6： 額度是會員的資金賬戶，余額是用戶的資金賬戶
P32： 想請教下支付會員下會有哪些賬戶分類，分類的標準一般會有啥
P31： 這個額度跟余額有什么關系沒有
P31： 還有這個額度代表什么，最高限額?
P6： 我們先把概念統一了。 額度就是授信，類似于信用卡額度
P29： 會員是身份證號，用戶是身份證+手機號?
P32： 在支付系統應該是限額，在消金領域即有限額又有授信
P31： 哥們你一口氣說完吧，我就看你的了，這些名詞說實話每個人都不一樣，我就看看你怎么說，按你標準理解
P32： 估計不會這樣，因為現在手機號就只能實名認證一張身份證
P6： 用戶一般用手機號區分
P29： @P6?我的理解對嗎
P32： 用組合標志去標識一個用戶，拓展可能受限制
P6： 等一下，我整理一下
P2： 有業務就有風控要求 而風控對應會員 所以有業務前需要做實名認證
P6： 我們的個人會員系統分三層:客戶，用戶，賬戶，客戶就是一個自然人建模，用戶常指一個注冊用戶，即系統使用者，也叫登錄賬戶，賬戶，指存放資金的實體，用貨幣來計量
P6： 客戶通常通過其用戶來使用系統，比如一個手機號注冊的用戶
P29： 那會員這個概念呢?等同于客戶嗎
P6： 對， 一個人有多個手機號，也就導致了同一個人在一個平臺有多個用戶
P6： 一般是先有用戶再有客戶，用戶通過實名認證產生客戶，一個客戶在系統中只有一個唯一標識:客戶號
P29： 明白了
P6： 兩個用戶實名，如果證件號和姓名相同，我們認為是同一個客戶下的兩個用戶在做實名
P6： 第一個用戶沒問題，一對一產生了客戶，當第二個用戶實名時，由于客戶已經存在，不能再創建了，或者說即使創建了也要合成一個，我們稱為歸并
P29： 支付密碼是在用戶緯度是嗎
P2： 反正業務數據產生前必須找到客戶 否則第一筆業務都可能產生風險 多個帳號沒問題 加個登錄用戶也沒關系 主要是業務安全上考慮
P6： 可以在用戶上。 歸并一般是這樣做的:當第二個用戶實名時，系統檢測到客戶已經創建，會讓第二個用戶輸入已實名用戶的支付密碼來進行簽權歸并
P6： 支付寶以前是只有當你提現時才讓你找客戶，畢竟用戶體驗也要考慮
P29： 現在用戶發起交易的前提必須實名嗎?
P6： 我接著說歸并，當第二個用戶密碼通過后，會把第二個也掛在此客戶下，即:將客戶號填入當前用戶域中
P6： 實不實名要看業務，也要看監管
P2： 說影響體驗看個人理解吧 除非跑的是無關緊要的數據 要不也是對客戶不負責任[呲牙]
P6： 基本上就這些吧，比較簡單的。 從管控角度上說 客戶凍結了，其下所有用戶禁入，用戶凍結了，用戶下所有賬戶禁入
P6： 一個原則:寬進嚴出
P29： [強]感謝
P6： 你們聊吧，我看會黃金現貨
P2： 客戶用戶帳號之間就是兩種關系表 業務表上存帳號id 統計就麻煩了
P6： 業務表上同時存兩個id
P2： 客戶的嗎 用戶沒意義的 就是登錄用
P6： 都存，用戶當然有意義了，你的操作是基于用戶的
P2： 再說吧 從關系表可以查到用戶 用戶可以看做是客戶一個屬性 無意義 有空聊吧 呵呵
P6： 你考慮一下一個客戶多用戶時場景吧
P6： 而且賬戶是在用戶下的……
P9： 其實最簡單的我就是現在銀行的系統下歸集所有的銀行卡的信用卡
P31： 你那句會讓已實名用戶輸入支付密碼來進行歸并是什么意思
P31： 同一會員不同用戶必須支付密碼一樣?還是說什么
P6： 歸并是要有驗證的，否則我知道了你的證件，把自己用戶掛你名下，如果你名下有信貸，錢就容易被我拿走。
P6： 同一會員不同用戶密碼應該不一樣
P2： 知道 用戶除了登錄用處不大 業務已經關聯帳號id了 這時的用戶只是客戶的暫時代表 在沒實名前 實名后從關系可以找到客戶那才是有用 業務要么多存客戶id 要么不存就只有帳號id也可以 個人理解 數據存了終究要怎么用 風控時定位都用戶還不夠 要找到客戶才行 不說了
P8： 群里有沒有做過資產證券化的?
P6： p2p么?
P8： 信貸 ABS業務
P33： 我·行·正在做ABS
P8： @P33
P31： Abs最好套個資管計劃，不然資金池很穩定
P31： 用戶密碼不一樣但是支付密碼一樣?
P6： 不一樣，只有你知道另一個用戶的密碼的時候，才能確認另一個用戶也是你
P34： 在途資金、凍結資金、可用資金，需要通過多賬戶方法來實現嗎?
P2： 用戶是虛擬的 客戶帳號業務才是真正實體
P31： 你這個流程我大概了解了，那我能不能說你這玩意其實是根據參照物來看的
P31： 比如在中國人民銀行看來的用戶在商業銀行看來可能是會員
P20： @P34?不需要多賬戶，賬戶中有賬戶余額，可用金額和凍結金額，賬戶余額=可用金額+凍結金額，一般只有出賬賬戶需要凍結金額，凍結額度會存在一個凍結單，記錄凍結的哪筆交易，哪個賬戶，凍結金額，凍結狀態等，同時更新賬戶可用金額和凍結金額，交易成功做解凍出賬，否則做解凍處理，恢復可用金額
P34： 如果一筆交易，T日更新余額(在途狀態)，T+1轉可用，如何在賬戶層面實現在途轉可用的過程呢?
P19： 余額 是 好幾個值： 可用余額、 未確認余額、 凍結余額。當前 余額 是 這幾個的總和。
P20： 我認為在途金額處理方式跟凍結金額是一樣的，在途金額轉可用首先是這筆交易的最終狀態肯定是確定的，要么成功要么失敗
P34： 如果通過支付賬戶掛子賬戶的方式實現?是不是很啰嗦?區分在途資金賬戶、凍結資金賬戶、可用資金賬戶。可用余額=可用資金賬戶。不可用余額=在途資金賬戶+凍結資金賬戶;總余額=可用+不可用
P19： 有很多處理方法
P6： 在途資金不應該和余額統一處理
P34： 在請教問題：管理辦法支付公司不允許為證券、信托等開戶。
P19： 有些交易是依賴凍結的 有些依賴中間賬戶
P34： 那可否有業務往來?資金如何處理?
P6： 余額是指已到賬不可撤消的資金
P34： 這個是呀
P31： 民生哥們，我剛剛的比喻對不對
P6： 差不多吧
P31： 支付公司是盡量別跟那些玩意打交道，不然死的快，特別是證券[捂臉][捂臉][捂臉][捂臉]
P20： @P34?在途資金我剛才說法有誤，請@P6?幫忙解答下[抱拳]
P6： 余額和在途不是一個維度
P6： 我想知道業務場景
P6： 如果一筆交易，T日更新余額(在途狀態)，T+1轉可用，如何在賬戶層面實現在途轉可用的過程呢?
P34： 代扣一筆，支付確認實時。
P6： 是這個吧
P34： t+1，資金到備付金賬戶，轉可用
P34： 如何在賬戶層，實現資金在途到可用的變化捏?
P34： 嗯那
P18： 在途一般在中間戶體現
P35： 一個賬戶內設兩個子賬戶，一個現金，一個在途
P34： 看來每個公司賬戶設置都不一樣啦[偷笑][偷笑]
P34： 通用方案，或者說“準標準”方案，是啥咧?
P36： 你定的在我眼里就是標準的
P18： 供參考，一筆收單涉及2個結算，銀行T+1結算： 渠道待清算賬戶(在途) -》 銀存賬戶(備付金余額); 商戶T+1結算：結算中間戶(在途)-》 商戶結算賬戶(余額);
P34： [呲牙][呲牙][呲牙][呲牙][偷笑][偷笑][偷笑]
P6： 關鍵是有沒有特殊處理
P6： 你說的場景還是不是很清楚
P20： 商戶結算賬戶是不是就是在途資金賬戶?只有t+1結算賬戶金額被轉到余額賬戶才能操作
P36： 本質在于 我們給商戶結算 是否應該依賴于通道方給我們結算
P6： 不應該
P36： 如果通道方沒給我們結算 但是到了我們給商戶結算的時間點 我們不想自己墊資給商戶……
P6： 這是兩筆賬
P36： 這就是她的需求
P36： 嗯 我也認為兩者應該分開
P6： 合同呢?
P18： 信息流和資金流本來就是分開的。。
P6： 如果通道不給你們結，你們永遠不給商戶結?
P36： 現狀是 通道方t+1結算給我們 我們跟商戶的合同也是t+1 然后我們計算商戶手續費 還要依賴于通道的對賬文件
P36： 嗯 如果通道沒結 就先去追錢……因為額度太大 墊不起
P6： 流程有問題
P18： 墊資是因為這2個之前差異造成的。比如商戶T0 銀行T1
P36： 嗯 應該完全隔離 通道和商戶對吧
P6： 對賬流程有問題
P36： 或者把商戶結算周期拉長 或者自己墊資 就不會這么痛苦了
P34： 如果有好的渠道可實時識別類別，可提前扣，不依賴于對賬文件
龔正： 一般都是商戶周期很長啊
P6： 對，對商戶你們要自主對賬，對于通道，以通道為主
P34： 俺們特殊[呲牙]
龔正： 厲害
P36： 業務場景決定我們不能留錢……
P38： 個人認為這個的記賬完全根據業務來，在電商業務的余額體系里面，用戶充值，支付渠道返回成功交易結果后，就該給用戶顯示余額。普通電商此時都不會有在途資金賬戶。高級一點能有這個賬戶。
P36： 說白了 就是業主著急要錢!
龔正： 著急要那為啥過你們。。[憨笑]
P6： 分開處理就對了
龔正： 還走第三方
P6： 流水好看啊
P34： 嗯嗯。
龔正： 你們是房產交易嗎
龔正： 這種交易如果過第三方 時間是個問題啊
P36： 是先過戶 還是先給錢 ～我們就解決這個問題客戶先拿出錢給我們就過戶 過戶后就給錢到業主
P37： 房地產交易的支付寶
P6： 分開處理，日終清算時，你們同時算好通道手續費及應收備付金，商戶手續費及結算資金，對于雙方都是對賬打款，差錯后期處理
龔正： 厲害
P36： 嗯 以后肯定要規范到這種正規流程
龔正： @小北-理房通-資金?你們自己是第三方唄
P34： 嗯
P6： 給通道方送個禮，上午給你們打款，你們下午打給業主
P34： [呲牙]
P36： [動畫表情]
龔正： [動畫表情]
龔正： 房產的特點是客單量小 客單價大
龔正： 普通電商的套路確實有點搞不定啊
P36： 系統壓力比你們小多了 我們可以慢點 ～不出資損就好
龔正： 哈哈 要不你們就快一天 多收點手續費啥的
龔正： 有墊資風險 就多點風險收益
龔正： [動畫表情]
P36： 木錢～
P38： T+0流水貸，提前結算
P8： 賬戶中有賬戶余額，可用金額和凍結金額，賬戶余額=可用金額+凍結金額，一般只有出賬賬戶需要凍結金額，凍結額度會存在一個凍結單，記錄凍結的哪筆交易，哪個賬戶，凍結金額，凍結狀態等，同時更新賬戶可用金額和凍結金額，交易成功做解凍出賬，否則做解凍處理，恢復可用金額
P6： 如果是這種情況，就用在途資金賬戶，因為一旦計入余額，就會納入資產類，沒人備付金，你納入資產就有問題了
龔正： 流水貸是啥意思啊
龔正： [驚恐]
P34： “銀行系流水貸”???
P8： 看到這個回答，記得還有一套類似模型。可用余額、預凍結金額、未達金額 、系統中金額
P38： @龔正?基于交易流水的貸款，也算是應收帳款貸款，同時基于企業資質。通常由收單支付公司或者合作資產方提供。
P36： 學習了
龔正： 奧 這樣啊
P32： 供應鏈金融?
龔正： 厲害啦
P8： 系統中金額用來處理A轉給B 同時B轉賬給C
龔正： 才看到你是ping++的
龔正： [色]
P6： 應收賬款的扺壓貸款
P38： 和供應鏈金融性質形似;流水貸是支付公司嘗試的增值業務。
P31： 你玩這種風險太大，個人建議小心為好
P31： 你這種不是供應鏈金融，是信用貸款
P6： 都有
P31： 供應鏈金融必須有明確的標的，要么是應收賬款類型，要么是預付款，要么存貨，他這種流水貸其實跟阿里的借唄沒啥區別
P6： 不是有扺押么?純信用?
P38： 資方和第三方支付公司合作，或者第三方支付公司自己做，風險是很小的。原本通過第三方支付公司收單的資金T+1結算給商戶，商戶在第三方支付公司這開通流水貸，T+0就拿到對應的結算資金;對第三方支付公司而言，就是基于成功交易的交易流水提前一天向商戶結算資金。
P31： 不懂，我就往前反了一下，沒看全
龔正： 這種貸款一般問題不大
P34： 您說的是特約商戶t0業務
P6： 基于結算資金抵押
龔正： 回籠資金挺快 不過小公司作假就悲劇了
龔正： 還是看信用
P25： 這個也叫貸款?
P31： 哦，這個叫流水貸[捂臉][捂臉][捂臉]，這個不就是D0業務嗎
P6： 我們叫D0
P25： 一臉懵逼[尷尬]
P31： 你看看又是名詞定義不一樣的結果
P31： [捂臉][捂臉][捂臉][捂臉][捂臉]
P34： [呲牙][呲牙][呲牙]
P34： 哈哈哈哈哈
P28： 這對于第三方來說 就是貸了結算款 t+1第三方不給商戶結算 是這意思么
P6： 墊資D0結算
P38： [Facepalm][Facepalm]
P25： 對商戶來說提前結算是好事
P18： 全支付公司自己墊資是D0，區別引入了其它資產提供方?
P25： 但不會是便宜事吧
龔正： 提前結算還是有風險的
P38： 收費標準不一
P25： 利息是多少
P6： 手續費就高
P25： 拿個標準來思考下
龔正： 所以實力雄厚才墊資 要不就找放貸方 放貸同時又買了保險
P6： 我知道的有10%手續費
P25： 這種業務場景也是真實存在的
P28： 這沒啥風險吧
龔正： 也有
P18： 銀行一般萬五?
龔正： 風險肯定還是有的
P6： 有，上游不給結就是風險
P28： 該結多少就貸多少還是每天給商戶貸的都一樣?
P28： 上游不就是銀行嗎
P18： POS T0結算很多都這么干吧，商戶自己出手續費
P25： 這種對應到線下有沒得類似的實際業務
P6： 銀行卡套現業務
P25： 感謝，不過銀行卡套現和這個還不是很貼合
P6： 睡了，大家繼續
P18： 套現都是急著想拿到錢的…
P36： [月亮][月亮]
P25： 不是很清楚商戶付相對較高的手續費來要求T+0清算的需求根源
P25： [月亮][月亮]
P8： @P6?你們說的這種提前收款和保理模式的提前收款是一類么?
P31： 不可能百分之十的哥們，最多百一百二頂天了，百十的那是洗錢
P18： 商戶T0實時代發，通過線上充值一般是要墊資的，可以商戶直接銀行轉賬，系統實現自動登賬，都能省點。
【本文為51CTO專欄作者“鳳凰牌老熊”的原創稿件，轉載請通過微信公眾號“鳳凰牌老熊”聯系作者本人】
