介面輪詢

這種方式比較簡單，一般採用HTTP/HTTPS的方式，在PC端每隔5秒或者其它自定義的時間請求伺服器的介面，判斷返回的資料是否有變化，比如返回資料表明支付完成就跳轉響應的支付成功的介面。這個方式的缺點是會有一定的延時，而且客戶端請求次數較多。大公司有自己的是實現協議。

這種方式比較及時，資訊反饋會比較快，每個客戶端只需要和伺服器維護一條TCP/UDP通道即可，客戶端完成操作後伺服器很快就可以透過管道給客戶端/PC端發訊息，通知客戶端做出相應的操作。這種方式的缺點是對網路穩定性要求比較高，大公司對此種方式會有相應的加密。

分享我的支付系統經驗，PC端支付大部分使用網銀支付和快捷支付。

對於網銀支付支付，支付成功後會自動跳轉到商戶的成功支付地址，而這個地址是PC在發起支付請求時傳遞給網銀系統的。

對於快捷支付，PC端發起確認支付請求，並且收到服務端處理成功後會每隔幾秒向服務端發支付結果查詢，輪訓查詢結果，得到結果顯示支付成功或失敗，如果輪訓次數到限制還沒有結果顯示交易處理中，具體金額到賬戶中心查詢。

兩種可能，一是支付成功後有個回撥地址，回撥地址是支付介面設定的，付款成功後自動轉到這個頁面。這樣就能看到PC頁面的響應了。

另一種可能是輪訓。回撥起作用的前提是支付的時候是在付款介面的平臺上支付的。如果是介面返回了一個二維碼，顯示在網站上，那麼回撥是不會起作用的，但是非同步通知還是可以的。非同步通知到伺服器後，把付款狀態在資料庫中進行修改。用Ajax不斷查詢付款狀態的改變，有改變時就執行頁面跳轉等操作。