個人到賬通知全量分析與總結（到賬一時爽，一直到，一直爽~~）
作者寄語：寫總結文章不容易，希望大家不要吝惜點贊，如果您也技術做到了，我同樣要為您點贊！！！如果要轉載，麻煩一定署名總結來至【收錢爸爸】，謝謝！！！
【渠道】
- 《支付寶》：?個人支付寶（或商戶號），可以使用多個支付寶號并行的方案，動態添加、刪除
備注：用戶錢直接進入商戶自己的支付寶賬號
耗時：即時
- 《微信》：?個人微信（或商戶號），可以使用多個微信號并行的方案，動態添加、刪除
備注：用戶錢直接進入商戶自己的微信賬號
耗時：即時
- 《云閃付》：?個人云閃付，可以使用多個云閃付號并行的方案，動態添加、刪除 個人云閃付，單個云閃付號綁定多張銀行卡，對多個卡并行的方案，動態添加、刪除 個人云閃付，解和多個云閃付賬號，并多個卡并行的方案
備注：用戶錢經銀聯處理，然后直接進入用戶的銀行卡賬戶
耗時：即時
- 《支付寶轉賬到銀行卡》：?動態生成支付寶轉賬到銀行卡的二維碼（活碼），可以使用多個銀行卡并行的方案，動態添加、刪除 支付寶轉賬到銀行卡的二維碼金額已經自動生成好，不需要用戶手工輸入金額 支付寶轉賬到銀行卡的二維碼設置為明卡碼（即顯示銀行卡完整卡號，賬戶名） 支付寶轉賬到銀行卡的二維碼設置為暗卡碼（即顯示部分銀行卡號，加***）
備注：用戶錢進入支付寶-->支付寶與各銀行對接-->錢進入用戶自己的銀行卡賬戶耗時：常規耗時在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數據，然后商戶自己設計展示自己的掃碼落地頁信息。
充值到賬信息回調接口：
同步回調： 充值到賬后，將到賬信息回傳給商戶，直接跳轉到商戶指定的同步結果的頁面（適用于一般的網頁類型的商戶）
異步回調： 充值到賬后，將道長信息回傳給商戶，接口地址是商戶側后端接收到賬通知信息的地方。商戶根據到賬信息，修改會員的分數/賬戶金額等。
【合作方式】
注冊成為我們商戶，在線使用相關的功能。
獲取源碼方式，自己可以自定義、擴展等。
獨立部署，商戶側自己使用一整套完整的功能平臺程序。
致閱讀者
感謝大家的閱讀，有什么技術問題，或者業務邏輯難點，可以一起探討，共同進步！
【收錢爸爸】供！謝謝！
