這是充值系列的最後一篇，將討論充值安全的問題。正如這個系列的其他文章提到的，充值系統的流程如下：
注意： 4,5執行順序不確定，步驟4是支付平臺自動向服務器請求，步驟5是玩家點擊“返回商家網站”時支付平臺請求服務器，如果玩家不點擊，這可能不會觸發，所以這是一個不可靠的請求。
支付的安全問題主要發生在步驟3和4中。下面是詳細說明：
在步驟3中，客戶端需要把訂單信息提交給支付平臺，比如玩家購買100個金幣，他需要支付人民幣10元。訂單信息如下：
{
"product_name" : 100金幣,
"total_fee" 100,
"currency": RMB
}
當玩家點擊提交訂單的時候，會把這個訂單信息提交到支付平臺，如果有人劫持這個請求，並且把訂單信息的總費用修改爲0.1元,那麼支付平臺只會扣除玩家0.1元，同時，這筆訂單會順利完成。也就是玩家只花了0.1元購買了原來100元的商品。
在步驟4中，支付平臺會把訂單處理結果和訂單信息返回給服務器，例如返回的結果如下：
{
"status" : "fail" // 表示支付失敗
"product_name" : 100金幣,
"total_fee" 100,
"currency": RMB
}
這裏，如果某個玩家把這個URL劫持，並且修改其中的某些信息，例如把支付失敗改爲支付成功，或者自己拼接一個URL向遊戲服務器發起請求，那後果可想而知。我們需要保證訂單除了結果沒有被修改，同時還要保證這個請求來自於支付寶。
針對串改訂單信息的問題，支付寶的做法是使用RSA算法加密訂單信息，對於步驟4中發生的問題，支付寶要求服務器驗證請求是否來自於支付寶，同時驗證返回的訂單信息，如訂單信息是否被串改，支付狀態是否爲成功等。
RSA加密的思路： 把訂單信息和商戶私鑰加密。同時把這個簽名傳給支付寶。只要不泄露商戶私鑰，訂單信息基本上不可能會被串改。當然，服務器也會驗證訂單信息沒有被修改。
服務器端驗證訂單信息是否被修改：
第一步：服務器端會接收到從支付寶返回過來的訂單信息和之前簽名的結果，這個時候，服務器在把訂單信息簽名，同時和之前的簽名結果對比，如果一致，說明訂單信息沒有被修改。
第二步：獲取支付寶返回的數據之一notify_id，按照支付寶要求的格式拼接成URL,提交給支付寶,如果返回爲true，則說明這請求確實來自於支付寶。如果所示：
做支付系統的一些思考：
1：在做遊戲後臺的時候，需要經常向遊戲服務器請求數據，這裏就有一個安全問題，遊戲服務器如何信任這個請求呢，這裏就可以參考支付寶的簽名機制：把需要向遊戲服務器請求的數據和一個”密文“生成一個簽名，把這個簽名也提交給遊戲服務器，當遊戲服務器接受到請求後，再把請求的數據和”密文“加密，同時把結果和接受到的簽名比對，這樣就可以判斷這個URL的合法性了。
2：支付平臺接入都大同小異，關鍵是要理解支付的流程，更深入支付流程的規範性和安全性，這對以後的編程也很有幫助。
3：在接入360,91這樣的平臺的時候，需要理解oauth2.0，也涉及到URL請求合法性的問題，但是Oauth2.0和本篇文章的做法不同。下一篇文章，將討論一下oauth2.0的應用。