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.僅對最新的充值信息進行處理(我們采取的方案)

因為采用一方案:

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

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

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM