iT邦幫忙

2021 iThome 鐵人賽

DAY 10
0
永豐金融APIs

掌握訂單與線上金流的剪不斷理還亂系列 第 10

Day10 永豐金API 訂單通知服務

昨天提到今天要講一個交易上特別重要的流程,就是付款狀態!
為什麼呢?

因為在交易的過成功前是最重要的,訂單建立失敗頂多重新建立,
但是付錢後卻沒有顯示付款完成絕對是大忌,使用者絕對暴跳如雷,
所以修改訂單狀態絕對是訂單交易最重要的環節之一。

讓我們回憶一下Day8 永豐金API 建立訂單交易
建立訂單裡面提到的BackendURL付款通知url,
使用者付款完成後,永豐金會傳送付款資訊到我們填寫的url,
接收到資訊透過「訊息查詢服務api」來確認通知訊息內容並修改訂單狀態,
老樣子先上範例

//永豐金傳送到BackendURL的參數
{
  "ShopNo": "商家編號"
  "PayToken": "訊息token"
}

//apIService 可參考Day7 永豐金API 基礎流程5 -- 整理 
echo apIService("OrderPayQuery", $data);

//response
{
	"ShopNo": "商家編號",
	"PayToken": "訊息token",
	"Date": "202109061735", //訊息日期
	"Status": "S", //處理狀態 S:成功 F:失敗
	"Description": "S0000 – 處理成功", //處理代碼
	"TSResultContent": {
		"APType": "PayOut",  //訊息類型 PayOut為付款結果
		"TSNo": "永豐金流單號",
		"OrderNo": "訂單編號",
		"ShopNo": "商家編號",
		"PayType": "A", //付款方式
		"Amount": "50000",
		"Status": "S", //處理狀態 S:成功 F:失敗
		"Description": "" //處理代碼
	}
}

整個流程就是接收永豐金通知資料,透過訊息查詢服務api核實,
然後在修改訂單付款狀態,雖然流程不多,但這邊也是非常重要的環節,
除了付款資訊要做二次驗證之外,也容易發生掉單(掉狀態)的情況,
至於為什麼要二次驗證是因為,萬一BackendURL位置不小心流出,
有心人士又知道的驗證流程,即可仿造付款成功訊息,後果不堪設想,
雖然在永豐金裡面因為通知的時候已經有透過訊息token封裝過了,
應該是不會有該情況發生,不過還是養成好習慣。

另外一樣這邊只列出必要參數,還有一些詳細的設定可以客製化例如自訂欄位、
信用卡授權資訊,這邊就不多做介紹。


上一篇
Day09 永豐金API 查詢訂單
下一篇
Day11 永豐金API 回顧
系列文
掌握訂單與線上金流的剪不斷理還亂30

尚未有邦友留言

立即登入留言