針對蘋果內購，看了 大量的 其他blog和閱讀官方文件才發現，其實 蘋果內購伺服器做的工作很少，
此文件 寫於2023年10月，只針對此時蘋果返回的資料結構 內容解析。
基本上所有的 操作都可以再前端完成操作，包括對支付憑證的驗證，但是如果在客戶端驗證憑證可能存在被篡改的危險，
伺服器去重驗證和加款，是建立在 使用者已經在前端支付成功，然後由ios會得到乙個位元組流，然後 base64後轉給 後台。
後台通過這個字串 去請求蘋果的伺服器，然後得到乙個json字串去給使用者加款，其中注意事項為
請求蘋果位址 返回的 內容為
請求的蘋果的內容為string param = "";
為什麼要做 product_id，bundle_id，因為 客戶端傳遞過來的 憑證，是不可信的，有可能是別人篡改後的結果。
比如，他們有個自己的內購，我們把這個憑證發到蘋果是可以拿到返回結果的，但是 product_id，bundle_id沒辦法一樣。
伺服器端資料驗證
現在有乙個方法實現頁面所有textbox 的資料驗證，public static bool checkallitems page page,string strfrmname page 傳過來的 page strfrmname 是頁面上面的 form 的 id 這個方法會檢測畫面上面所有的 text...
關於Ajax伺服器端驗證
對於這個問題以前卡了幾次，也不知道自己是怎麼處理的。伺服器端驗證往往有乙個延時，也就是專業上所說的非同步操作。如果在提交表單需要獲取伺服器給的返回值來判斷是否需要提交就不是那麼容易了。因為 ajax 的延時性導致所獲取的返回值並非伺服器端的返回值。因為這一步執行的時候外圍程式可能已經執行完返回了。這...
IOS內購支付伺服器驗證模式
使用者選擇需要購買的產品 使用者選擇需要購買的產品 上述兩種模式的不同之處主要在於 交易的收據驗證，內建模式沒有專門去驗證交易收據，而伺服器模式會使用獨立的伺服器去驗證交易收據。內建模式簡單快捷，但容易被破解。伺服器模式流程相對複雜，但相對安全。使用者能否忍受3 6s的等待時間 對於第乙個問題，我們...