1. 程式人生 > 其它 >iOS蘋果內購服務端技術方案

iOS蘋果內購服務端技術方案

IOS內購服務端技術方案

https://www.jianshu.com/p/632a79900aa3

IOS購買vip流程

1. IOS端,使用者點選相應的購買按鈕

2. 服務端生成訂單,並返回訂單資訊(包含在蘋果後臺設定產品對應的ProductID)

3. 客戶端發起支付

4. 客戶端支付完畢,拿到蘋果返回的transaction,把該transaction和訂單資訊傳到服務端

5. 服務端更新訂單狀態,返回客戶端該vip購買訂單已完成蛋未驗證的狀態(此時可認為使用者已經是vip),客戶端流程已結束

6. 服務端根據transaction,去蘋果伺服器驗證收據的有效性,再去更新訂單狀態,如果錯誤,則回滾使用者vip資格(非同步處理)

IOS內購伺服器模式的主要流程如下所示:

1. app從伺服器獲取產品標識列表

2. app從app store 獲取產品資訊

3. 使用者選擇需要購買的產品

4. app 傳送 支付請求到app store

5. app store 處理支付請求,返回transaction資訊

6. app 將transaction receipt 傳送到伺服器

7. 伺服器收到收據後傳送到app stroe驗證收據的有效性

8. app store 返回收據的驗證結果

9. 根據app store 返回的結果決定使用者是否購買成功

服務端驗證注意點

蘋果AppStore線上的購買憑證驗證地址是

https://buy.itunes.apple.com/verifyReceipt

測試的驗證地址是:https://sandbox.itunes.apple.com/verifyReceipt

1. 考慮到網路異常情況,伺服器的驗證應該是一個可恢復的佇列,如果網路失敗了,應該進行重試。

2. 與蘋果的驗證介面文件在這裡。簡單來說就是將該購買憑證用Base64編碼,然後POST給蘋果的驗證伺服器,蘋果將驗證結果以JSON形式返回。

國內連線蘋果伺服器的穩定性問題

問題

1. 使用者能否忍受3-6s的等待時間

2. 如果app store server 宕機,如何確保成功付費的使用者能夠得到正常服務。

解決

對於第一個問題,我們有理由相信使用者完全無法忍受,所以採用非同步驗證的方式,伺服器收到客戶端的請求後,就將請求放到MCQ中去處理。

對於第二個問題,由於蘋果人員很負責人的告知:我們的伺服器不穩定,所以不排除收據驗證超時的情況。

對於驗證超時的收據,儲存到資料庫中並標記為驗證超時,定時任務每隔一定的時間去app store驗證,確保能夠獲取收據的驗證結果。

相關參考

iOS支付

iOS應用內付費(IAP)開發步驟列表

IOS In App Purchase(內購)驗證

蘋果內購伺服器驗證之receipt返回多組in_app思考

https://www.cnblogs.com/widgetbox/p/8241333.html

最近有部分使用者反映,蘋果內購充值失敗,經過測試總結有幾個關鍵點出現問題

1.app購買成功蘋果沒有返回票據,屬於票據遺漏(取決於蘋果伺服器的響應狀況),只能客戶端進行監聽重新整理等處理

2.app連續購買的過程中,前幾次蘋果沒有返回票據,幾次之後,蘋果返回了一個有效的票據,app提交給伺服器進行驗證的過程中in_app出現多組資料的情況,這種情況還是能充值成功了,只是不能全部到賬

3.app連續購買,有一次正常返回票據,在提交給伺服器的過程中出現意外,但實際服務端已經接受到票據,為使用者成功充值,但app進行下次充值帶回票據,再次提交伺服器驗證的時候,in_app中出現了上次已經提交的票據資訊,這種情況伺服器將判斷為已經充值,導致最後一次充值失敗

本著刨根問底的精神,查閱各方資料總結如下,蘋果的官方描述(IAP票據驗證)如下:

百度翻譯如下:

它說,票據在一個在JSON檔案,是一個數組包含所有應用程式購買收據基於應用程式購買交易收據資料輸入Base-64,而且有可能返回一個空的陣列(空陣列居然還是有效的)

在應用程式購買收據消耗型產品新增到發票購買時,它是儲存在你的應用程式接收到完成交易。在這一點上,它是下一次收到的更新-例如從收據後,當用戶再購買或如果您的應用程式顯式重新整理收據。

原諒我的英文水平低下,看完之後一臉懵逼,下面總結一下我個人的理解,大概意思如下:

對於消耗型產品的購買,在購買完成(蘋果那邊購買完成,不是伺服器購買完成)之後會被新增到票據資訊中,直到你的APP完成交易(APP的主動行為),之後它會在使用者下一次購買的時候對票據進行重新整理,或者APP進行顯示重新整理。

看完這個就很好理解上面出現的問題了,也就是說:

驗證票據返回的receipt裡面的in_app欄位,這個欄位包含了所有你未完成交易的票據資訊。也就是在上面說到的APP完成交易之後,這個票據資訊,就會從in_app中消失。

如果APP不完成交易,這個票據資訊就會在in_app中一直保留。(這個情況可能僅限於你的商品型別為消耗型)

知道了事件的原委,就很好優化解決了,方案有2個

1.對票據返回的in_app資料全部進行處理,沒有充值的全部進行充值

2.僅對最新的充值資訊進行處理(我們採取的方案)

因為採用一方案:

如果使用者僅進行了一次充值,該充值未到賬,他不再進行充值了,那麼會無法導致。

如果他通過客服的途徑已經進行了補充充值,那麼他在下一次充值的時候依舊會把之前的產品票據帶回,這時候有可能出現重複充值的情況