就邏輯上來看要先釐清
信用卡繳費時常失敗,是什麼引起失敗
應該會有失敗的代碼,代碼是什麼情況下觸發
兩件事是分開來看

API 與授權主機通訊錯誤

也就是API有指定IP才可以連進去刷卡~

既然公司都說不清的話~
何不先開放API不指定IP呢?這樣線上刷卡也許就不會被阻擋了~

我以存粹路由的層面來分析，通常問題是request 來到虛擬機時走的路，跟reply回去的時候走的路不同導致的

檢查步驟

1. 首先檢查你的虛擬機有沒有設 default gateway, 有的話跳7, 沒有的話跳第2步
2. 虛擬機前的那一個裝置(可能是Load Balancer 或 Firewall) 有沒有把in comming request的traffic另外做映射IP (NAT), 有的話跳第3步, 沒有的話跳5
3. 檢查in comming traffice的 NAT是不是被Load Balancer or Firewall指定了多於1個NAT IP 作為映射IP, 如果指定了多於1個NAT IP的話跳第4步, 只有一個 NAT IP (或被映射成該裝置的interface IP)的話跳6
4. 可能NAT IPs裡面某些IP跟其他同網段上的IP撞IP了, 或者某些NAT IP的request來到虛擬機後，該虛擬機本身沒有相對應的routing table去回應他(通常是NAT IP 跟虛擬機不是同一個網段才會需要另外設routing table)
5. 該檢查虛擬機有沒有足夠的routing table 來回應從外網而來的source IP traffic 該回應去哪裡...因為在沒有default route的情況下，虛擬機只能跟同網段的其他IP溝通，其他亂七八糟的source IP全部都會無法回應。(注意有些firewall, load balancer會自動把in comming traffice 應設為該裝置的interface IP, 如果是這個情況請跳6)
6. 假設該NAT IP與你的虛擬機除在同一個網段下，由於你的payment系統沒有辦法知道客戶用什麼source IP來付錢，而如果你處理每一單payment的時候不單單只靠token，還判斷IP的話，會遇到有個情況就是當有兩個以上客戶同時在線付款時，你的payment系統會看到兩個一樣IP的人在付某兩張invoice, 這樣就會是個問題了 (或許也能解釋為什麼有時可以有時不行繳費)
7. 檢查除了default gateway外，虛擬機上還有沒有另外手動加的routing存在, 有的話跳8, 沒有的話跳9
8. 如果是已經沒在用的routing, 建議先刪除掉，有時候這種前人遺留的東西很容易導致後人很難查找問題。如果是都有在用的routing, 就要先確定你payment的traffic 到底是不是只會從 Default gateway 或 某一條已經存在的routing table所指定的裝置來的，注意只能擇一。
9. 檢查該default gateway所指向的裝置上 (可能是Load Balancer 或 Firewall)，該虛擬機是否為某個cluster中個其中一台，是的話跳10, 只有單獨一台在線的話跳11 (payment系統一般都是會有HA的，也是企業最重視的核心業務，如果你真的只有一台的話請收下我的膝蓋)
10. 檢查你的Load balancer or Firewall 上的payment server 的cluster 設定，有沒有開啟強制單一連接 (也就是說一但user連上虛擬機，你的Load Balancer知道要讓一個user在同一session下時，不要把他的traffice派給cluster上的其他虛擬機處理，因為其他虛擬機並不知道那個user付錢付到什麼階段了)
11. 檢查Load Balancer or Firewall上對你虛擬機out going時的映射IP (SNAT 或有些裝置一樣叫 NAT)，如果只有一個固定的NAT IP的話就再往ISP端的方向去找問題，也有可能是ISP給了你浮動IP而不是固定的Public IP. 如果不止一個SNAT IP的話，就很可能會出問題，因為payment系統在處理付款過程的時候如果隨機的換了一個SNAT IP的話可能會導致失敗。

實際情況可以再複雜幾百倍，要看你的網絡拓墣多大，希望有因此提點到一些你未曾想過的盲點啦。