支付系統設計：移動端應用的錢賬系統設計

隨著移動端應用的崛起與滲透，越來越多的支付場景由web端轉移到了移動端，同時傳統的銀行卡支付已經不能滿足簡單便捷的移動體驗了。在這樣的大背景下，應運而生的各類第三方支付服務提供商便有了生存空間。移動支付幾乎在各種場景中出現：外賣，電商，直播，社區等等。

這裡我們討論的支付，其實並不是指支付行為本身，而是在整體產品邏輯之下，錢賬系統該如何規劃。項目的複雜度主要產生於如何將自身的支付訴求與第三方服務結合，給用戶帶來安全可靠，明確易用的支付體驗。

背景與需求

錢賬系統中最基本的元素是賬戶，帳戶之間資金的流動就構成了交易，發起交易的一方，被稱為交易主體，資金從該主體所擁有的賬戶中流出，交易主體可以是個人或企業。而接收資金的一方，被稱為交易對手，同理也可以是個人或企業。

普通企業是沒有支付牌照且不具備清算資質的，所以我們必須通過接入第三方服務商來實現交易，所以本質上，真正的支付過程是由我方系統調用服務商的接口來實現資金轉移的。這些第三方服務商也被稱作渠道，他們就像機器人的搖臂一樣替我們實現交易。當然，渠道會在這個過程中收取一定的費用。

就像規劃任何新的產品一樣，首先應該明確需求，這裡我們不討論具體的用戶需求，而是以錢賬業務的服務對象（資金流）為核心，常見的資金流有以下幾種類型：

• C to B to C － 淘寶店鋪
• C to B －京東自營
• C to C －打賞轉賬
• B to B ­ －企業級服務

C 代表個人帳戶，B代表企業賬戶。退款屬交易異常處理，所以不在此處討論。

無論是以上哪一種資金流模式，涉及的交易動作都是無外乎支付和提現兩種，站在渠道的角度，也被稱作收款和付款。

除此之外，在項目前期還應確定產品支持的手機平臺及形態，以保有後期的拓展性。

目前常見的手機平臺有：Apple公司的iOS系統及各品牌的安卓系統；

常見的產品形態有：手機app，手機wap頁，web網頁，微信公眾號。

支付與提現

支付是指用戶將平臺外的資金轉移至平臺內賬戶的過程，本質為個人賬戶向對公賬戶進行轉賬。（也存在一些特殊形式，比如p2p企業和銀行合作的資金存管）

提現是指用戶將平臺內賬戶的資金轉移出去的過程，本質為對公賬戶向個人賬戶（或對公賬戶）進行轉賬，與支付相逆。

通常情況下，支付需求比提現更多，所以支付商支持的場景也更豐富。

支付渠道

目前主流的渠道有支付寶、微信、銀聯、蘋果。（海外市場暫不討論）

適用性

標記代表支持，空白代表不支持。

隨著移動端應用的崛起與滲透，越來越多的支付場景由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%左右，具體請參考中國銀聯商戶中心網站。

在產品設計上，支付手續費通常由平臺抹平，所以用戶是感知不到的（單客利潤應大於支付費率）

隨著移動端應用的崛起與滲透，越來越多的支付場景由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%左右，具體請參考中國銀聯商戶中心網站。

在產品設計上，支付手續費通常由平臺抹平，所以用戶是感知不到的（單客利潤應大於支付費率）

支付寶-支付費率

隨著移動端應用的崛起與滲透，越來越多的支付場景由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%左右，具體請參考中國銀聯商戶中心網站。

在產品設計上，支付手續費通常由平臺抹平，所以用戶是感知不到的（單客利潤應大於支付費率）

支付寶-支付費率

微信-支付費率

提現費率

相較於支付，提現功能所要支付

隨著移動端應用的崛起與滲透，越來越多的支付場景由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系統）

附上三大支付平臺的鏈接：

• 銀聯：https://merchant.unionpay.com/join/
• 微信：https://pay.weixin.qq.com/
• 支付寶：https://www.alipay.com/

鑑於不同產品的支付需要不盡相同，錢賬系統的展現形式也可以是多種多樣的，我們採取QA的形式來解決一些設計過程中的要點：

Q1 是否有必要設計應用內的錢包？

錢包的本質是預充值，即用戶已經將資金轉入平臺，當要進行其他購買操作時只完成平臺內的一步資金劃扣就可以了，這個體驗優於拉取站外支付。缺點是要求用戶對平臺具有一定的信任度，這給部分用戶造成了負反饋。

基於以上，當交易行為具有高頻小額，易受刺激（衝動型消費）的特性時，比如直播應用，付費社區，錢包將會給用戶帶來十分便捷的支付體驗。

同時，錢包會帶來更多的運營促活手段，比如充值返贈，強運營型的產品可以將錢包做為一個著力點。

Q2 如何保證平臺內的賬戶安全？

賬戶安全包括很多方面，除去技術手段上對於系統健壯性的保護，產品層面，我們以下幾個要點需要把握好：

1 身份驗證

敏感操作前，需要對用戶的真實身份進行認證，常見的認證要素有：真實姓名、手機號、銀行卡號、身份證號（護照），根據業務所需來調用相應的鑑權接口來驗證所需字段，值得一提的是，對於實名要求很高的場景，還應引入複雜驗證，比如人臉識別，視頻驗證，上傳照片等。支付寶和國政通都提供相關的欺詐驗證接口服務。

2 操作安全

操作安全主要為了防止用戶誤操作，他人操作，或用戶隱私洩露。常見的方法有：應用內手勢鎖屏，支付密碼，關鍵信息的部分遮罩處理等。

Q3：還有什麼其他需求嗎？

當完成了以上的產品設計後，基本上主線流程已經明確了。但同時不要忘記數據統計的需求，因為數據是用戶行為的客觀體現，也是我們迭代優化的重要依據，例如：

數據監控需求，通常這部分數據也為運營和財務部門服務，屬於後臺系統設計的範疇，包括但不限於支出、充值、轉賬等流水信息。

用戶行為數據，這部分數據主要依賴前端打點統計得出，用來驗證用戶和界面交互式是否符合預期。

關鍵轉化率漏斗，這部分數據為複合型數據，使用起來會包含以上兩種類型，用來衡量核心模塊，比如充值，提現，消費的轉化效率。

其他需求，根據團隊的需要，PM提供的個性化需求。

安全

安全性是錢賬系統第一優先級的需求，在上線前一定要經歷嚴密的測試，保證用戶和平臺的資金安全。一方面技術層面要進行規範的開發和自查，規避漏洞；另一方面對潛在的外部安全隱患有預警和應急方案，以備不時之需：

信用卡盜刷

如果你的支付系統支持信用卡消費，那麼一旦發生了信用卡盜刷我們期望系統可以第一時間做出反應，及時止損，這裡可以採取的措施主要是判同一用戶是否有連續多筆的大額消費，並在風險出現時進行相關驗證。

洗錢

理論上來說，任何一個完整支持資金流閉環的錢賬系統都可以洗錢。即不法分子使用非法收入進行支付後再提出，從而將非法收入合理化。尤其是當系統的資金流閉環支持無損提現（無手續費，無抽成）時更應考慮到洗錢的風險。當然，大多數洗錢案件都涉案數額較大，一般的互聯網產品不會被這類人使用。規避的辦法主要是把控資金出口，進行高門檻的身份鑑權。

本文由 @ 阿廝 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於CC0協議