圖 8-1: 文件第 31 頁

今天要開始建立我們的第一筆測試訂單。在文件第 31 頁的測試說明提供了測試用的信用卡卡號及相關資訊，這裡就不再重覆。文件中的小標題 - 商戶傳遞參數，則是我們在前幾天不斷提到的訊息內文，Day 4 的訊息內雜湊、Day 7 的 Message 內文加密，用的就是商戶傳遞參數中的欄位資料。

商戶傳遞參數

圖 8-2: 欄位說明

文件中對於資料欄位的型態一欄，採用的是 COBOL 程式語言的資料型別標示，X 代表字串型態，9 代表數字型態，文件雖然沒特別注明，但從欄位名稱和描述還是可以猜到。

需要特別注意的有以下幾點：

• Amount 欄位的說明，因補上小數兩位，金額數字的表示要多加兩個 0。
• 括號中的數字為欄位長度，在實作的過程中都必須檢查，尤其是字串欄位，超過限制的要截斷，以免格式錯誤而送單失敗。
• PayType 的值為 A 則為虛擬帳號付款，文件中 ATMParam 段落的 ExpireDate 為必填。
• PayType 的值為 C 則為信用卡付款，文件中 CardParam 段落的 AutoBilling 為必填。

流程實作

圖 8-3: 測試程式

第 28~50 行 是模擬的測試資料。
第 52 行 透過 SDK 的 getHashId 方法算出 HashId。
第 53 行從第 2~24 行的 getNonce 方法向 Nonce API 取得效期 60 秒的 Nonce。基本上每次發動請求，都會向 Nonce API 拿一次。
第 54 行 透過 SDK 的 getIV 方法算出 IV 值。
第 55 行 透過 SDK 的 getSign 方法算出 Sign 值。
第 56 行 透過 SDK 的 aesEncrypt 方法算出加密後的訊息本文。

第 58~68 行 是我們要傳給 Order API 的資料陣列，透過第 72 行的 json_encode 轉成 JSON 本文。

測試結果

圖 8-4: 測試建立訂單

建單失敗的話，會直接回一串錯誤訊息。建單成功的話，會回一串 JSON 字串，如下圖。

圖 8-5: API 回應字串

從 Order API 的回傳字串看來，Message 欄位也是加密過的 16 進位字串。

流程總結

透過今天的文章可以知道，其實比較複雜的欄位處理都在前幾天的文章中介紹了，透過 TTD (test-driven development) 的開發方式，邊寫文章編測試來寫文章，到今天 PHP SDK 也已經寫好了，即將放到 GitHub 分享給大家使用。

在明天的文章中，將進行解密 Message 欄位的流程介紹。

本文更新於筆者的 TerryL 部落格，Day 8 - 使用 Order API 建立測試訂單，有興趣可前往閱讀及討論。