1、將新通道提供的接口整理出單獨的接口業務流程（即各接口流程順序的關係），
2、以此爲基準，對比系統的業務流程，測試接口（如商戶是否可以多次修改費率），瞭解上游的業務規則；
3、對比系統已有功能、已對接通道的接口字段，確認是否有新增的必填字段，字段的長度限制等；（此處以商戶入駐、審覈爲例進行說明）
序號 | 處理方式 | 優點 | 缺點 |
① | 【採取】以上游爲準 平臺只增加可選參數，不做必填校驗，轉發給上游進行校驗； | 平臺較少開發工作量，且以上游結果爲準，不存在校驗陳舊問題。 | 1、在審覈的時候，運營沒有統一審覈標準。 2、如果因不符合上游要求進件商戶失敗，且此時不允許修改商戶，可駁回審覈待下游修改後重審； |
② | 分渠道校驗 平臺根據渠道進行校驗，走上游A時註冊地址必填，走上游B則選填； | 能很好應對各個渠道的情況。 | 1、在審覈的時候，運營沒有統一審覈標準。 2、如果需要做平臺端的商戶渠道切換，則需要先根據渠道要求補充、修改資料纔可； 3、需要及時更新維護校驗規則而升級系統，在更新之前，會導致與上游通訊失敗。即使做成配置項，也怕被誤改。 |
③ | 【採取】按全量進行校驗，不區分渠道 平臺收集各個渠道的參數做一個並集，增加必填參數。 | 1、運營可按統一標準進行審覈； | 1、如果某代理商一直走上游B，就沒有必要提交營業執照了，下游工作量較多。 |
注
（1）對於新增字段，採取③的處理方式，儘可能收集完整的資料。（如上游A要求企業上送營業執照註冊地址，上游B則不要求）。因爲本需求背景是各渠道都可能會關閉通道，可能會隨時提高入網標準，所以商戶資料按真實商戶情況進行完整、準確、合法的原則進行提交是最好的，且運營同事也希望掌握商戶更精細的資料以便提供更準確貼心的服務。
（2）對於校驗規則（必填、長度等），採取①，由上游直接控制。
3、根據前面的分析，列明上游各接口參數與平臺字段的對應關係，如上游的推薦關注公衆號名稱對應平臺的商戶全稱；
4、結合現有業務流程進行合併、兼容處理，同時考慮切換通道的緊急處理流程；
5、新增【支付渠道】測試點
一、支付 1、輸入密碼、不輸入密碼； 2、測試交易超時（一般是商戶掃碼）； 3、測試異步通知（一般是顧客掃水牌）； 4、測試支付結果是否返回微信openID、支付寶支付賬戶； 5、測試大額交易是否成功，並檢查記錄輪詢次數，時間； 6、微信、支付寶扣款賬戶：借記卡/餘額、貸記卡； 二、退款 1、退款時間限制，只支持3個月內的訂單進行退款？是否需要額外開通業務權限？ 三、撤銷 四、測試支付同步返回、異步返回、查詢返回參數是否包括微信、支付寶端的官方訂單號，OpenId、支付賬戶，借貸標識； |