系統(tǒng)集成方式概覽
系統(tǒng)之間的交互方式通常包含以下幾種：
- api接口調(diào)用，通過rpc的方式（如：http）直接調(diào)用獲取數(shù)據(jù)或?qū)懭霐?shù)據(jù)
- 直接訪問數(shù)據(jù)存儲，如直接訪問對方系統(tǒng)數(shù)據(jù)庫等
- 通過消息隊(duì)列進(jìn)行隊(duì)列通知
接口方式
接口方式（包括<font color="red">api和消息隊(duì)列</font>）是數(shù)據(jù)交互的經(jīng)典方式，適用于系統(tǒng)之間的數(shù)據(jù)集成、互聯(lián)互通，便于實(shí)現(xiàn)分布式的事務(wù)以及系統(tǒng)之間邏輯調(diào)用
界面集成方式
很多情況下，系統(tǒng)之間的集成包含了復(fù)雜的業(yè)務(wù)操作邏輯，例如對于保險業(yè)務(wù)，很多時候需要進(jìn)行較為復(fù)雜的交互操作，這時，如果單純的使用接口方式進(jìn)行交互，會調(diào)用大量的系統(tǒng)接口，同時需要每個接口集成的業(yè)務(wù)系統(tǒng)理解一系列的業(yè)務(wù)交互過程，對于系統(tǒng)集成方造成很大的困難，系統(tǒng)集成周期非常長。針對這種情況，如果被集成方提供現(xiàn)成的基于界面交互的方式的集成能力，將能夠大大的降低集成難度，便于業(yè)務(wù)快速落地。具體流程如下：
支付寶網(wǎng)頁支付接口調(diào)用示例
調(diào)用順序如下：
商戶系統(tǒng)請求支付寶接口 alipay.trade.page.pay，支付寶對商戶請求參數(shù)進(jìn)行校驗(yàn)，而后重新定向至用戶登錄頁面。
用戶確認(rèn)支付后，支付寶通過 get 請求 returnUrl（商戶入?yún)魅耄?，返回同步返回參?shù)。
交易成功后，支付寶通過 post 請求 notifyUrl（商戶入?yún)魅耄?，返回異步通知參?shù)。
若由于網(wǎng)絡(luò)等問題異步通知沒有到達(dá)，商戶可自行調(diào)用交易查詢接口 alipay.trade.query 進(jìn)行查詢，根據(jù)查詢接口獲取交易以及支付信息（商戶也可以直接調(diào)用查詢接口，不需要依賴異步通知）。
注意：
- 由于同步返回的不可靠性，支付結(jié)果必須以異步通知或查詢接口返回為準(zhǔn)，不能依賴同步跳轉(zhuǎn)。
- 商戶系統(tǒng)接收到異步通知以后，必須通過驗(yàn)簽（驗(yàn)證通知中的 sign 參數(shù)）來確保支付通知是由支付寶發(fā)送的。詳細(xì)驗(yàn)簽規(guī)則參考異步通知驗(yàn)簽。
- 接收到異步通知并驗(yàn)簽通過后，一定要檢查通知內(nèi)容，包括通知中的 app_id、out_trade_no、total_amount 是否與請求中的一致，并根據(jù) trade_status 進(jìn)行后續(xù)業(yè)務(wù)處理。
- 在支付寶端，partnerId 與 out_trade_no 唯一對應(yīng)一筆單據(jù)，商戶端保證不同次支付 out_trade_no 不可重復(fù)；若重復(fù)，支付寶會關(guān)聯(lián)到原單據(jù)，基本信息一致的情況下會以原單據(jù)為準(zhǔn)進(jìn)行支付。
其他界面集成方案
- 對于移動端來講，可以通過類似Android系統(tǒng)的Activity集成調(diào)用方式，調(diào)用被集成方的App的界面來進(jìn)行集成
問題及解決方式
- 上面所描述的方法，如果涉及到復(fù)雜傳參或者大量傳參的情況，可以在被集成方和集成方雙方提供數(shù)據(jù)接口的方式來臨時存儲過程參數(shù)，參數(shù)通過臨時的唯一標(biāo)識key來互相獲取，存儲方式可以考慮redis等臨時存儲，具有一定時效性，過期清除
