前言
Hi，各位朋友，我是CrazyCodes
上一篇我大致描述了支付系統開發的基本流程，但相比之下，國內的流程雖然大同小異，但必要步驟還是完整的，技術水平比較高，但相比之下，對接海外的三方支付就沒有我們想象的那麼通暢了。
本章還是按照正常流程，付款、通知（包括同步通知、非同步通知）、查詢、退款以及對賬這幾個基本步驟來說明與海外的區別。
建議配合 淺談支付系統開發基本流程 文章理解差異點
付款
上圖是一個完整的付款流程，與海外支付的特殊性相比較的話，有以下幾個點
- 三方確認支付可能不是實時的，這裡這個不實時代表的不是分鐘級，而可能是小時或者是以天為維度的，為啥延遲這麼大，這個我就不清楚了，可能是鏈路長，或者技術發展水平問題，當然這也是部分國家，類似英國、法國這些比較發達的國家，一般來說流程還是挺正常的。
- 例如臺灣的超商支付，可以理解為是一種線下支付方式，大致流程是使用者在網站上下單後，我方只能夠提供使用者一個支付碼，使用者需拿著這個支付碼去線下門店付款，最終完成交易，這種方式在我方付款的這個流程上，只能是完成一個付款前置的功能，付款過程線上下。
- 其次我們不應信任任何系統與使用者操作，何況是海外，貨品或資金的追回更加困難，所以要做各種校驗，有時海外三方系統沒有校驗的功能，可能會發生欺詐行為，我們可以通過三方提供的附加引數（類似於訂單描述）新增上校驗碼，當然，如果連這個也沒有的話，只能聽天由命了。
- 最後是關於訂單號的問題，就是部分三方系統訂單號可能不支援冪等，這意味著當使用者使用某個訂單號發起支付在並未付款後，再次用這個訂單號發起支付時就會失敗，遇到這種情況時，我們可以使用一個訂單號對應多個交易號去解決，意味著每次發起後生成一個唯一的交易號，作為訂單號的替補，去進行支付。
通知
付款都如此困難，那麼通知更是難上加難，列出幾個比較核心的差異點
- 首先可能沒有任何通知，那麼沒有任何通知的情況下，我們只能通過主動查詢的方式去獲取付款結果
- 又可能是缺少一種一類通知，缺少同步通知，或者非同步通知，一般都是缺少非同步通知，缺少非同步通知的話，如果你係統認為可以完全信任同步通知的話，可以選擇性忽略這個缺陷，如果有同步+主動查詢，個人認為確實可以選擇性忽略，如果沒有主動查詢的介面，那就需要詢問三方系統是否可以提供對賬的介面，總而言之，就是要做到資訊對稱，才可以認定付款成功。
- 最後一種最奇葩，雖說是一個線上付款的流程，但可能三方系統並沒有主動查詢介面、同步通知、非同步通知和對賬介面，你沒有看錯，除了一個付款，啥子都沒有，這種情況下，一般三方會提供給你一個可以手動下載賬單的商戶後臺，然後嘞，只能通過匯入表格的方式去校驗了，這比較類似於國內的銀行卡轉正或者公對公。
退款
經歷了複雜多變的付款後，再來看看退款的一些差異
- 首先是沒有退款介面，這就意味著使用者只能去找三方退款，三方再從對賬單中體現出來某個訂單的狀態。
- 其次就是可能沒有退款的非同步通知，那麼我們只能使用主動查詢的方式去驗證訂單狀態，這又回到了沒有介面的問題，如果沒有主動查詢介面，最次最次我們手動去商戶後臺匯出，再匯入系統內。
- 最後有一種最原始的方式，叫做財務打款（意思就是沒有自動化退款流程）。
對賬
歷經千辛萬苦，總算到了對賬這個環節，一般有以下幾個差異
- (自求多福型)沒有任何可以提供的賬單
- (自食其力型)三方系統提供了可以匯出的商戶後臺，通過匯入表格完成對賬
- (半自動化型)分為兩種，提供FTP供下載對賬單，另外一種通過郵件方式定時傳送賬單，程式通過讀郵箱完成對賬
- 最後說一點，保持著不完全信任三方系統的原則，對賬這塊還是要謹慎的，儘量把風險擋在使用者付款時吧。
致謝
感謝你看到這裡 ，希望本篇文章可以幫到你，謝謝。