• 作者寄語：寫總結文章不容易，希望大家不要吝惜點贊，如果您也技術做到了，我同樣要為您點贊！！！如果要轉載，麻煩一定署名總結來至【收錢爸爸】，謝謝！！！

【渠道】

- 《支付寶》：
個人支付寶（或商戶號），可以使用多個支付寶號並行的方案，動態添加、刪除

    備註：用戶錢直接進入商戶自己的支付寶賬號
    耗時：即時

- 《微信》：
個人微信（或商戶號），可以使用多個微信號並行的方案，動態添加、刪除

    備註：用戶錢直接進入商戶自己的微信賬號
    耗時：即時

- 《雲閃付》：
個人雲閃付，可以使用多個雲閃付號並行的方案，動態添加、刪除

    備註：用戶錢經銀聯處理，然後直接進入用戶的銀行卡賬戶
    耗時：即時

- 《支付寶轉賬到銀行卡》：
動態生成支付寶轉賬到銀行卡的二維碼（活碼），可以使用多個銀行卡並行的方案，動態添加、刪除
支付寶轉賬到銀行卡的二維碼金額已經自動生成好，不需要用戶手工輸入金額
支付寶轉賬到銀行卡的二維碼設置為明卡碼（即顯示銀行卡完整卡號，賬戶名）
支付寶轉賬到銀行卡的二維碼設置為暗卡碼（即顯示部分銀行卡號，加***）

    備註：用戶錢進入支付寶-->支付寶與各銀行對接-->錢進入用戶自己的銀行卡賬戶
    耗時：常規耗時在2分鐘以內（高，低峰處理不一樣），與每個銀行的處理能力有關，有的銀行快，有的銀行慢
 

- 《微信轉賬到銀行卡》：
微信轉賬到銀行卡，可以使用多個銀行卡並行的方案，動態添加、刪除

    備註：用戶錢進入財付通-->財付通與各銀行對接-->錢進入用戶自己的銀行卡賬戶
    耗時：常規耗時在1分鐘以內（高，低峰處理不一樣），與每個銀行的處理能力有關，有的銀行快，有的銀行慢

- 《直接銀行卡到銀行卡轉賬》：
多個銀行卡並行負載，動態添加、刪除

    備註：用戶錢直接進入商戶自己的銀行卡賬戶
    耗時：10秒左右（高，低峰處理不一樣），與每個銀行的處理能力有關，有的銀行快，有的銀行慢

- 《銀行合作商戶》：
提醒：每個銀行合作商戶結算的情況不一致，有的銀行是T+0，有的銀行是T+1，這個根據商戶自己的能力進行申辦。

    例如，農行合作商戶（農行聚合碼），T+1
    例如，平安銀行合作商戶（平安銀行商戶共碼），T+0
    例如，建行合作商戶（建行聚合碼），T+1
    ...

    備註：用戶的錢直接進入商戶自己的銀行合作商戶號
    耗時：與各銀行合作商戶的結算方式有關，有即時和T+N方式有關

- 總結：
總結：多個渠道並行負載，大大的提高靈活度，以及吞吐量（日量1-10KW不是夢），難的是要能支持上面這麽多渠道的負載並行，組合，並可配置，動態調整。
這裏要大大的點贊【收錢爸爸】平臺，此處掌聲，謝謝！

【到賬通知策略】

- 動態碼技術：
即時動態生成指定金額/備註的二維碼，用戶掃碼後不需要輸入金額/備註，直接掃碼支付即可，完成掃碼充值後，自動回調通知到賬信息。

    優勢：用戶掃碼支付成本低，不需要做人工輸入金額，備註等多余的操作。
    劣勢：支付寶目前收款碼一天有20次的生成限制，但是目前可以使用支付寶轉賬碼的形式來避開次數限制，但是需要處理好友的相關業務邏輯。
          微信也有風控限制，微信收款碼生成一天也會觸發45次左右的限制

- 定額碼技術：
提前準備收款二維碼（商戶需要計劃準備自己常規需要的金額的收款二維碼），可以手工準備，也可以借助Xposed等自動生成二維碼進行準備。
定額碼方案之一，金額不變，備註變，來區分識別收款。即如：1元(備註:1.00) 1元(備註1.01) 1元(備註1.02)... 用戶付款還是1元，到賬也是1元
定額碼方案之二，金額變，來區分識別收款。即如：1元 1.01元 1.02元... 用戶付款1元，1.01元，到賬也是1元，1.01元

    優勢：性能優勢大，能突破支付寶/微信等風控限制
    劣勢：有準備的成本，且需要處理相關的識別策略邏輯

- 備註模式：
即通過用戶付款的備註（用戶自己輸入的備註信息），來識別到賬。

    優勢：只需要準備通用的收款碼一張，或者展示收款賬號信息，用戶主動輸入付款備註來識別到賬
    劣勢：用戶有寫付款備註的成本，且需要處理備註到賬的策略邏輯

- 指定金額輸入：
提示用戶，按照指定金額來充值，從而識別到賬。

    優勢：只需要準備通用的收款碼一張，或者展示收款賬號信息，用戶主動輸入指定的付款金額來識別到賬
    劣勢：用戶得按照指定金額付款，且需要處理相關得到賬策略邏輯

- 總結：
多個策略可以組合運用，當前也會大大提高復雜度，不過幸運的是有的到賬通知技術平臺已經完全實現所有的技術策略。這裏依然要大大的點贊【收錢爸爸】平臺，此處掌聲，謝謝！

【支付寶轉賬到銀行卡收款碼】

支付寶轉賬到銀行卡，活碼策略（即多個卡並行，使用池子的處理策略） 支付寶轉賬到銀行卡碼，明卡（上面已提到）
支付寶轉賬到銀行卡碼，暗卡（上面也已經提到），目前黑市中有各種收費，，，但是在這裏，是免費的......

【技術點再強調】

多渠道負載，並行（實現大吞吐量，日量大，渠道穩定性高，風險分擔，從而導致幾乎無掉單，除非收款賬號/卡本身存在異常） 多賬號負載，並行
單點控制，即動態配置每個渠道的日量限制，筆數限制，單筆額度限制，卡的筆數，量等限制。（這樣子才可以真正穩定的輸出，當然難度是復雜的邏輯實現）

【商戶側配合】

• PC電腦客戶端：
  商戶可以只用在電腦上直接運行客戶端軟件，來實現收款。（當然也可以用來對接測試等）

• APP客戶端：
  商戶可以在手機上安裝APP客戶端，來實現收款。（當然也可以用來對接測試等）

【商戶API接口設計】

通用的restful api策略（和開發語言無關），https安全協議保障，基於token以及md5驗簽的方案處理

• 充值申請接口：

實現商戶側發起充值申請，可攜帶商戶自己需要的信息，後續再充值成功到賬信息回調中，原樣返回商戶自己需要的信息。
充值申請發起成功後，可直接返回一個H5的掃碼落地頁，也可以商戶只需要返回相關的JSON數據，然後商戶自己設計展示自己的掃碼落地頁信息。

• 充值到賬信息回調接口：

同步回調：
充值到賬後，將到賬信息回傳給商戶，直接跳轉到商戶指定的同步結果的頁面（適用於一般的網頁類型的商戶）

異步回調：
充值到賬後，將道長信息回傳給商戶，接口地址是商戶側後端接收到賬通知信息的地方。商戶根據到賬信息，修改會員的分數/賬戶金額等。

【合作方式】

• 註冊成為我們商戶，在線使用相關的功能。
• 獲取源碼方式，自己可以自定義、擴展等。
• 獨立部署，商戶側自己使用一整套完整的功能平臺程序。

致閱讀者

感謝大家的閱讀，有什麽技術問題，或者業務邏輯難點，可以一起探討，共同進步！

【收錢爸爸】供！謝謝！

https://www.shouqianbaba.cn

個人到賬通知全量分析與總結（到賬一時爽，一直到，一直爽~~）