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元這樣不符合任何等級的價格。詳細價格等級表可以看蘋果的官方文件：(

1.3分成

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

 1.4結算

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

2.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.參考資料