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

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

讓我們回憶一下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封裝過了，
應該是不會有該情況發生，不過還是養成好習慣。

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