繳費業務的一般流程和差異

從終端來看：最糙的流程是這樣：
1.終端呼叫後臺的查詢個人繳費計劃（grycx介面），後臺返回給終端一個欠繳資訊
2.終端可以點選繳費，然後輸入銀行卡密碼，後臺返回給一個繳費結果給終端
說白了，這裡就是兩個請求-響應
第一個是確認請求，第二個是繳費請求；只有第一個了確認了，才執行第二個繳費；
第一個確認請求到達後臺後，後臺做了什麼？
後臺接收到這個請求之後，去呼叫X軟的一個介面（個人應繳查詢）
在個人應繳查詢介面把欠費資訊返回到後臺後，後臺把該結果處理一下，返回給終端；
一般後臺做的事情是：
1.接收終端請求獲取引數，
2.將引數組裝成javabean，傳送給本地資料庫事務處理介面，得到返回結果並處理成理想的結果，
3.將這個理想的結果傳送給終端
這裡後臺做的事情：
1.接收終端請求獲取引數，
2.將引數組裝成報文，傳送給東軟個人應繳查詢介面，接收返回結果並處理成理想的結果，
3.將這個理想結果傳送給終端
所以說，第二步做的事情變了；
第二個繳費請求到達後臺之後，後臺做了什麼？
1.接受終端的請求獲取引數
2.將引數組裝成報文，將報文傳送給第三方支付平臺，接收返回結果並處理成理想的結果
3.將這個理想結果傳送給終端

所以後臺的處理流程都是一樣的：
1.接收請求，獲取引數
2.根據引數組裝javabean或者報文，將javabean或者報文傳送給對應的介面，接收返回結果，處理成理想結果
3.將理想結果傳送給終端
區別在於第二步，是組裝javabean,還是報文，組裝json報文還是金融報文而已
這裡要注意的問題是：
是不是第三方支付平臺繳費成功了，就一定可以返回了呢？
不是的，
即使第三方支付平臺繳費成功了，還得去通知另外一個平臺，
讓另外一個平臺也做相應的處理，如果他們處理失敗了，我們也只能去呼叫支付平臺的介面，
去撤銷繳費，從而讓繳費金額原路返回；
這樣做是確保多個涉及的平臺的繳費記錄的一致性，
如果不一致，那問題就嚴重了；
管理平臺作為一箇中遊，為了實現上游和下游的互動，一直在做的工作是：
接收資料，處理資料，傳送資料；接收資料，處理資料，傳送資料；
中游完全就是一個數據流！