蘋果内購那些事兒(一)

1.簡介

 蘋果内購是指Apple Store的應用内購買，是蘋果為App内購買虛拟商品或服務提供的一套交易系統。

其他章節:蘋果内購那些事兒(二)

1.1内購商品類型

1.1.1消耗類型商品

      該類型适用于可多次購買的消耗型項目，如遊戲道具、虛拟币等。

1.1.2非消耗類型商品

      該類型适用于一次購買永久有效的項目，如電子書、遊戲關卡等。

    該類型項目支援跨裝置同步和本地restore，比如說，使用者在某個App中購買了一本書，可在所有相同Apple ID裝置的App中免費擷取這本書，而不要需要借助App本身的帳号體系，即使在App中删除了這本書，也可免費重新擷取。

1.1.3自動續費的訂閱商品

  該類型适用于自動續費的訂閱項目，如Apple Music的按月訂閱，使用者購買後會每月自動續費，直到使用者手動取消或者開發者下架IAP項目。類似非消耗類型商品，該類型也支援跨裝置同步和本地restore機制。

1.1.4非自動續費的訂閱商品

該類型适用于固定有效期的非自動續費項目，如雲音樂的會員和一些視訊App的會員。沒有跨裝置同步和本地restore機制，使用者可以多次購買。

1.2商品定價

  在建立IAP項目的時候，需要設定價格，這個價格隻能從蘋果預設的價格等級中選擇，比如等級1對應1美元、6元人民币，等級2對應2美元、12元人民币，最高等級87對應999.99美元、6498元人民币。另外可能是為了照顧某些貨币區的開發者和使用者，還有一些特殊的等級，比如備用等級A對應1美元、1元人民币，備用等級B對應1美元、3元人民币這樣。除此之外，IAP項目不能定一個9.9元這樣不符合任何等級的價格。詳細價格等級表可以看蘋果的官方文檔：(https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/ng/app/880452926/pricingMatrix/subscription)蘋果的價格等級表通常是不會調整的，但也不排除在某些貨币匯率發生巨大變化的情況下，對該貨币的定價進行調整，調整前蘋果會發郵件通知開發者。

1.3分成

  很多人都知道，App Store上的付費App和App内購，蘋果與開發者預設是3/7分成。但實際上，在某些地區蘋果與開發者分成之前需要先扣除交易稅，開發者的實際分成不一定是70%。從2015年10月開始，蘋果對中國地區的App Store購買扣除了2%的交易稅，對于中國區帳号購買的IAP，開發者的實際分成在68%~69%之間。而且中國以外不同地區的交易稅标準也存在差異，如1.3中所述，如果需要嚴格計算實際收入，可能需要把這個部分也考慮進來。

    針對不同地區的内購，内購價格和對應的開發者實際收入在蘋果的價格等級表中有詳細列舉。(https://developer.apple.com/app-store/subscriptions/)

 1.4結算

   針對IAP的交易收入，蘋果一般以5周(每年1/4/7/10月)或4周(其餘月份)作為一個結算周期，并在每個結算周期結束後第33天向開發者付賬。

2.IAP支付流程

這部分内容在《In-App Purchase Programming Guide》中有詳細說明：https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction.html#//apple_ref/doc/uid/TP40008267

      具體來說，IAP的支付模式分為用戶端校驗和服務端校驗2種模式，用戶端校驗模式因為容易僞造支付憑據，安全性比較低，一般隻有非常簡單的單機App才會使用，大部分App都會采用服務端校驗模式。

      另外不同類型的IAP支付流程也會有一些小差異（主要是restore機制），下面就以最常用的消耗品類型為例，來說明一下IAP的支付流程：

    1.使用者準備購買某個項目時，App用戶端通過product id向蘋果API請求支付資訊。

  2.App用戶端再次驗證product id對應的支付價格和貨币機關無誤（可跳過），繼續請求支付。

  3.手機系統彈窗提示使用者确認将要購買的内容和價格，使用者點選确認購買，App用戶端獲得蘋果API傳回的支付成功通知以及支付憑據，向App服務端請求校驗支付憑據。

  4.App服務端拿到用戶端的支付憑據，再向蘋果伺服器請求校驗支付憑據（避免一些越獄插件僞造用戶端支付憑據）。App服務端校驗支付憑據成功，通知App用戶端。App收到支付憑據校驗成功通知，代表使用者付費成功，再處理後續業務邏輯

      以上就是一個标準的IAP支付流程，看上去順理成章，但實際上有很多坑，下面重點來講一下需要注意的問題。

3.不能忽視的坑

3.1 延遲傳回支付結果

  在上述IAP支付流程中，由于網絡問題等種種原因，即使使用者已經付款成

功用戶端也可能一時半會收不到蘋果API的支付成功通知，也無法主動向蘋果API請求查詢支付狀态，隻能被動等待通知。是以有些情況下，用戶端會延遲收到支成功的通知（可能是過了幾分鐘，也有可能是下次打開App的時候）。

 針對這種情況，需要在每次蘋果通知到用戶端有未完成訂單的同時，用戶端需要及時把相關憑證等資訊給到伺服器。

3.2 服務端校驗延遲

  在上述支付憑據校驗過程中，因為網絡問題等各種原因，用戶端可能無法及時收到服務端的校驗成功的通知。

  類似的，這種情況需要用戶端本地持續向伺服器輪詢校驗結果，直到傳回明确的校驗成功或校驗無效的結果。

3.3 非官方管道包支付失敗問題

  在上述流程步驟中，如果使用者安裝的App不是App Store官方管道包（從

PP助手、同步推等第三方應用商店下載下傳），蘋果API會直接傳回product id不

存在并結束支付流程。

類似的，越獄裝置在安裝某些内購破解插件後，也會導緻無法進行内購（傳回product id不存在）。是以，針對這個問題的解決辦法是：當傳回product id不存在時，提示使用者安裝的可能是非官方管道包，引導使用者到App Store下載下傳官方管道包。

4.IAP使用中需要注意的問題

4.1綁定蘋果内購的交易資訊和應用的使用者資訊

  利用内購中的applicationUsername，可以實作每一個訂單和APP對應使用者的綁定。值得一提的是，applicationUsername上面可以放置一個任意字元串，開發者可以根據自己的需求，做出調整。

4.2 記錄支付成功以後的交易資訊

      蘋果内購付款成功以後，蘋果會傳回訂單号之類的交易資訊。建議APP拿到這些資訊以後，将其發送到APP的伺服器，友善以後使用。（注意，目前在蘋果的線上環境沒有做出測試，還不能确認内購傳回的交易訂單号和使用者收到交易訂單号是否一緻。）

4.3盡量不要删除已建立的内購商品

  已建立的IAP除了product id之外的所有資訊都可以修改，如果删除了一個IAP，将無法再建立一個相同product id的IAP，也意味着該product id永久失效。而product id一般有特定的命名規則，用來标示App内的購買項目，如果命名規則下有某個product id永久失效，可能會導緻整個product id命名規則都要修改，掉進坑裡~

4.4注意區分reference name和display name

      reference name是給開發者自己看的，display name會在IAP支付流程的确認購買系統彈窗中展示給使用者，而且不能随意修改（修改需要重新送出IAP稽核），是以命名的時候要弄清楚。

4.5當App稽核被拒時

      如果IAP随App版本一起送出稽核，有問題時所有新送出的IAP商品和App版本會同時被拒，再次送出App稽核時，一定要記得重新送出所有IAP商品（每個IAP還得要手動編輯一下才能重新送出真麻煩），否則蘋果是無法繼續稽核的。

4.6無法避免的丢單

       當遊戲用戶端沒有拿到支付憑證或者遊戲伺服器沒有拿到支付憑證的情況下，使用者再也不打開這個應用甚至删除掉，目前看來，沒有辦法解決這種情況的丢單。

4.7退款問題

  根據蘋果政策，使用者在購買IAP後90天内，能以各種原因申請退款（扣款後購買失敗、買錯了、不喜歡等等），但實際能不能退成功蘋果說了算。

      如果一個使用者申請退款成功，蘋果會在與開發者結算時記一筆退款訂單（當然原來購買成功的訂單也在），錢就不給了，而且蘋果也不會告訴你是哪個使用者退款的，而且使用者購買的東西還在。

      訂單資料可以在itunes connect背景的“付款和财務報告”中檢視，但沒有詳細時間資訊和使用者資訊，很難定位到相應的平台訂單。

      從曆史資料來看，一般不遇到大量惡意退款的情況下，IAP的退款率可能在1~3%之間（取決于App内容品質、使用者心情，還有蘋果的心情）。對于IAP營收額很大的App，可能需要考慮一下退款的問題。

5.參考資料

http://www.cnblogs.com/meteoric_cry/p/4598304.html

http://rhd361.com/special/news?id=bafeabd95c854196b753be356cf501e3

http://blog.csdn.net/u013152587/article/details/50488353

http://www.jianshu.com/p/8c958e75f98f

http://bbs.netease.im/read-tid-730

http://www.cnblogs.com/zhaoqingqing/p/4597794.html