既然應用已經驗證在與正確的服務器通信并已被成功認證， 那么用戶就可以開始發出服務請求了。 應用必須確保傳輸的數據在傳輸過程中是安全且未被修改的。?

資金轉移請求會聯合使用密碼哈希與加密的方式來確保消息是難以理解的并且在傳輸階段是沒有經過修改的。 雖然本節將會生成和介紹很多負載示例， 不過每個示例都會使用如下代碼定義的 JSON 負載結構：

JSON?

payload 屬性是請求體中唯一被加密的元素。 服務層要想正確解密負載， 就得要求應用使用 Initialization Vector(IV) 來對數據進行加密。 通常情況下， IV 會隨著被它加密的數據一起發送。 雖然這么做似乎降低了消息的安全性， 但實際上并不會， 因為單憑 IV 本身不足以解密消息。 當服務層解密負載后， 它會使用同樣的預定義的負載屬性集合來生成 MAC（消息認證碼， Message Authentication Code)， 然后將其與進來的請求中的 MAC 進行對比以驗證消息的完整性。 如果消息在傳輸過程中被修改， 那么代碼就不會匹配， 被修改的消息則會產生錯誤

圖 6-2 概覽了請求、響應交易中發生的步驟， 以及在交易每一端的加密與解密過程中使用的組件。 交易雙方都知道用于加密與解密的重要值和 MAC 算法。 此外， 請求體部分與之前示例中定義的 JSON 負載結構是匹配的

請求、響應中的加密與解密過程