支付系統設計:移動端應用的錢賬系統設計
這里我們討論的支付,其實并不是指支付行為本身,而是在整體產品邏輯之下,錢賬系統該如何規劃。
隨著移動端應用的崛起與滲透,越來越多的支付場景由web端轉移到了移動端,同時傳統的銀行卡支付已經不能滿足簡單便捷的移動體驗了。在這樣的大背景下,應運而生的各類第三方支付服務提供商便有了生存空間。移動支付幾乎在各種場景中出現:外賣,電商,直播,社區等等。
這里我們討論的支付,其實并不是指支付行為本身,而是在整體產品邏輯之下,錢賬系統該如何規劃。項目的復雜度主要產生于如何將自身的支付訴求與第三方服務結合,給用戶帶來安全可靠,明確易用的支付體驗。
背景與需求
錢賬系統中最基本的元素是賬戶,帳戶之間資金的流動就構成了交易,發起交易的一方,被稱為交易主體,資金從該主體所擁有的賬戶中流出,交易主體可以是個人或企業。而接收資金的一方,被稱為交易對手,同理也可以是個人或企業。
普通企業是沒有支付牌照且不具備清算資質的,所以我們必須通過接入第三方服務商來實現交易,所以本質上,真正的支付過程是由我方系統調用服務商的接口來實現資金轉移的。這些第三方服務商也被稱作渠道,他們就像機器人的搖臂一樣替我們實現交易。當然,渠道會在這個過程中收取一定的費用。
就像規劃任何新的產品一樣,首先應該明確需求,這里我們不討論具體的用戶需求,而是以錢賬業務的服務對象(資金流)為核心,常見的資金流有以下幾種類型:
- C to B to C - 淘寶店鋪
- C to B -京東自營
- C to C -打賞轉賬
- B to B - -企業級服務
C 代表個人帳戶,B代表企業賬戶。退款屬交易異常處理,所以不在此處討論。
無論是以上哪一種資金流模式,涉及的交易動作都是無外乎支付和提現兩種,站在渠道的角度,也被稱作收款和付款。
除此之外,在項目前期還應確定產品支持的手機平臺及形態,以保有后期的拓展性。
目前常見的手機平臺有:Apple公司的iOS系統及各品牌的安卓系統;
常見的產品形態有:手機app,手機wap頁,web網頁,微信公眾號。
支付與提現
支付是指用戶將平臺外的資金轉移至平臺內賬戶的過程,本質為個人賬戶向對公賬戶進行轉賬。(也存在一些特殊形式,比如p2p企業和銀行合作的資金存管)
提現是指用戶將平臺內賬戶的資金轉移出去的過程,本質為對公賬戶向個人賬戶(或對公賬戶)進行轉賬,與支付相逆。
通常情況下,支付需求比提現更多,所以支付商支持的場景也更豐富。
支付渠道
目前主流的渠道有支付寶、微信、銀聯、蘋果。(海外市場暫不討論)
適用性
標記代表支持,空白代表不支持。
支付渠道適用性
關于支付寶,微信,銀聯相信大家都比較熟悉。需要特別指出的是,蘋果公司目前提供兩種截然不同的支付方式,Apple Pay和 IAP,區別在于前者適用于現實存在的服務和商品,而后者僅用于購買虛擬物品,根據Apple的規定,二者是嚴格不可混用的。這也要求pm在定義好自己售賣的物品特性后再選擇合適的支付方式。
支付費率
大同小異,除了蘋果公司的IAP支付方式需要支付30%的費率,其他渠道均穩定在0.5%-1.2%左右。此處列舉了微信和支付寶的費率明細,蘋果支付的底層服務也走銀聯,且銀聯的支付通道費率均是可談的,大約在0.8%左右,具體請參考中國銀聯商戶中心網站。
在產品設計上,支付手續費通常由平臺抹平,所以用戶是感知不到的(單客利潤應大于支付費率)
支付寶-支付費率
微信-支付費率
提現費率
相較于支付,提現功能所要支付
各渠道提現費率
規劃與設計
當做好了前期準備后,我們就可以push團隊動起來了。需要注意的是,各種渠道的申請所需材料,審核時長都不一樣,建議在確定大方向后的第一時間就先進行渠道申請,以避免影響項目的排期。(此處建議阿里的B端pm好好梳理下業務邏輯,同時優化下無比雞肋的QA系統)
附上三大支付平臺的鏈接:
鑒于不同產品的支付需要不盡相同,錢賬系統的展現形式也可以是多種多樣的,我們采取QA的形式來解決一些設計過程中的要點:
Q1 是否有必要設計應用內的錢包?
錢包的本質是預充值,即用戶已經將資金轉入平臺,當要進行其他購買操作時只完成平臺內的一步資金劃扣就可以了,這個體驗優于拉取站外支付。缺點是要求用戶對平臺具有一定的信任度,這給部分用戶造成了負反饋。
基于以上,當交易行為具有高頻小額,易受刺激(沖動型消費)的特性時,比如直播應用,付費社區,錢包將會給用戶帶來十分便捷的支付體驗。
同時,錢包會帶來更多的運營促活手段,比如充值返贈,強運營型的產品可以將錢包做為一個著力點。
Q2 如何保證平臺內的賬戶安全?
賬戶安全包括很多方面,除去技術手段上對于系統健壯性的保護,產品層面,我們以下幾個要點需要把握好:
1 身份驗證
敏感操作前,需要對用戶的真實身份進行認證,常見的認證要素有:真實姓名、手機號、銀行卡號、身份證號(護照),根據業務所需來調用相應的鑒權接口來驗證所需字段,值得一提的是,對于實名要求很高的場景,還應引入復雜驗證,比如人臉識別,視頻驗證,上傳照片等。支付寶和國政通都提供相關的欺詐驗證接口服務。
2 操作安全
操作安全主要為了防止用戶誤操作,他人操作,或用戶隱私泄露。常見的方法有:應用內手勢鎖屏,支付密碼,關鍵信息的部分遮罩處理等。
Q3:還有什么其他需求嗎?
當完成了以上的產品設計后,基本上主線流程已經明確了。但同時不要忘記數據統計的需求,因為數據是用戶行為的客觀體現,也是我們迭代優化的重要依據,例如:
數據監控需求,通常這部分數據也為運營和財務部門服務,屬于后臺系統設計的范疇,包括但不限于支出、充值、轉賬等流水信息。
用戶行為數據,這部分數據主要依賴前端打點統計得出,用來驗證用戶和界面交互式是否符合預期。
關鍵轉化率漏斗,這部分數據為復合型數據,使用起來會包含以上兩種類型,用來衡量核心模塊,比如充值,提現,消費的轉化效率。
其他需求,根據團隊的需要,PM提供的個性化需求。
安全
安全性是錢賬系統第一優先級的需求,在上線前一定要經歷嚴密的測試,保證用戶和平臺的資金安全。一方面技術層面要進行規范的開發和自查,規避漏洞;另一方面對潛在的外部安全隱患有預警和應急方案,以備不時之需:
信用卡盜刷
如果你的支付系統支持信用卡消費,那么一旦發生了信用卡盜刷我們期望系統可以第一時間做出反應,及時止損,這里可以采取的措施主要是判同一用戶是否有連續多筆的大額消費,并在風險出現時進行相關驗證。
洗錢
理論上來說,任何一個完整支持資金流閉環的錢賬系統都可以洗錢。即不法分子使用非法收入進行支付后再提出,從而將非法收入合理化。尤其是當系統的資金流閉環支持無損提現(無手續費,無抽成)時更應考慮到洗錢的風險。當然,大多數洗錢案件都涉案數額較大,一般的互聯網產品不會被這類人使用。規避的辦法主要是把控資金出口,進行高門檻的身份鑒權。
本文由 @?阿廝 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
關于支付,很業余的。蘋果不是支付公司,銀聯也不需要千吧,2C代付更不需要一塊五···
最毒的一點,錢包涉嫌資金池,違規哦。
感謝大家的打賞,收藏和贊。 ??