今天來說「重新付款」功能

首先要說的是
綠界沒有提供「原訂單重新付款」功能

如果你看到其他網站也是串綠界金流
且網站有提供「重新付款」功能
那就是該網站自己設計的流程
不是綠界提供的原功能

每次呼叫綠界建立訂單API時
MerchantTradeNo都必須是一組全新且不重複的值
只要綠界有收到request
不管交易是否成功
這組MerchantTradeNo就無法再次使用了

例如
呼叫全方位金流的建立訂單API
進入綠界付款頁面後隨即關閉頁面
訂單編號=ECPaytest1726108768

隨後再次使用同樣的MerchantTradeNo呼叫建立訂單API
就會收到「訂單編號重覆，建立失敗，請返回商店頁面重新下單。」的錯誤訊息

只要離開付款頁面，該MerchantTradeNo就會失效

也就是說
綠界沒有提供同一張MerchantTradeNo的重新付款功能

但有些廠商會要求工程師架站時
提供原訂單重新付款功能

所以該怎麼做?

假設購物網站訂單編號是AA123
送往綠界的訂單編號是ECPAY111
結果消費者因故未付款或交易失敗

於是
在購物網站的AA123訂單頁面跳出「重新付款」按鈕
消費者再次點擊後
購物網站會再自動送一筆ECPAY222訂單進綠界
如此消費者就可以再次進到綠界頁面完成付款

當網站收到付款成功通知後
再將付款成功狀態寫回AA123的訂單
這樣就達成「重新付款」功能囉
是不是很簡單呢?

其實，上面的流程有些「缺陷」

確實，把重新付款功能做在自己的系統是可行的
但其中的流程要規劃清楚

這裡提供有可能會產生的錯誤的情景:
購物網站的訂單號碼為「AA123」
送往綠界的訂單編號(MerchantTradeNo)為「ECPAY111」

但因消費者操作原因
不小心將綠界付款頁面關閉
返回購物網站後點選「重新付款」

這時
購物網站的訂單號碼還是「AA123」
但由於綠界不接受重複的訂單編號
因此重送一筆新的訂單編號(MerchantTradeNo) 為「ECPAY222」
然後消費者才付款完成

到這裡都沒問題
問題出在下面

前面有提到
ReturnURL未收到綠界回傳通知的原因之一
就是消費者沒有填入信用卡資訊就關閉頁面
建議使用查詢訂單API反查付款結果

問題就出在這裡
如果有設置反查邏輯

購物網站可能因前一張訂單「ECPAY111」並未收到綠界回傳付款結果
這時啟動反查訂單機制
就會查到「TradeStatus=10200095」

隨後將查詢結果直接寫回資料庫
並將「AA123」訂單狀態為「付款失敗」

但消費者返回購物網站點選「重新付款」的時間
可能是第一張訂單的「一小時後」

而你網站的反查邏輯是第一張訂單的「10分鐘後」發動
這樣導致後面那張付款完成「ECPAY222」的訂單狀態
寫不進購物網站的訂單「AA123」資料庫更新狀態
假設資料庫不允許狀態複寫的情況

這樣就會導致消費者明明有付款
但網站卻仍顯示未付款的情況產生

因此各位在進行串接的時候
要自行注意有沒有踩到這個雷囉

以上就是今日的「重新付款」講解

我們明天見