訂閱型內購, 有一套完整的銷售體系, 這一點非常重要. 以往的內購app, 一般上都使用我們自己的銷售體系, 然後跟蘋果的內購配合起來, 尤其是消耗性內購, 在我們自己的商品體系中, 加上一個ID對應到蘋果的內購ID, 使用者在我們的商品體系內獲取商品資訊, 然後蘋果那裡支付, 支付完成了, 再到我們自己的體系內完成購買. 這個過程, 對我們開發者來說, 其實就是拿iap僅僅當做支付工具來用, 而放棄它的銷售體系. 當然, 不排除有人老老實實的使用蘋果內購的銷售體系, 但是, 對大部分開發者來說: 內購就僅僅只是一個支付工具. 

將iap僅僅當做支付工具, 在訂閱型內購中, 已經不起作用了, 因為, 訂閱型內購它自帶的一整套銷售模型, 必然會迫使我們產品修改自己的商業銷售模型. 這裡要額外提一下, 原本我並不關注訂閱型內購, 但是, 一旦程式中涉及一段時期的VIP服務, 蘋果的稽核人員會強迫我們使用訂閱型內購, 所以, 逼得我只能去研究這個工作了. 下面, 我總結一下, 從蘋果的各個官方資料裡面總結下來的資訊:

1. 要使用訂閱型內購, 一定要在Connect的協議,銀行一欄裡面重置Request, 一個新註冊的空白賬號, 是無法新建訂閱型內購的. 

2. 訂閱型內購的每個時期, 是一個Cycle期, 這個Cycle期結束後, 會自動發起一次新的訂閱, 這個過程無需使用者確認. 

3. 訂閱內購可以帶試用模式, 試用模式過期後, 會提示使用者正式購買訂閱. 

4. 訂閱內購是跟隨AppleID的, 所有的使用同一AppleID的裝置上, 是會同步訂閱的. 這一點就是一大坑, 直接將訂閱型內購繫結到蘋果的賬戶, 如果我們自己有商業銷售體系, 往往都是有自己的使用者體系, 跟蘋果的體系直接產生衝突. 

5. 訂閱模式下, 使用者第二年繼續訂閱的話, 開發者可以獲得85%的收益. 這裡是指積累訂閱, 而且是同一個Group的訂閱, 不包括免費的時期. 這一點倒是很爽的. 

6. 一個Group內的訂閱不能選擇多個, 只能選擇一個, 使用者可以在多個訂閱之間切換, 這一點, 同樣也導致了跟我們自己的商業銷售模式會有衝突. 

7. 一個訂閱型內購, 可以給新老使用者不一樣的定價體系, 比如給老使用者優惠, 新使用者原價. 

8. 訂閱內購降價的時候, 不會有任何提示資訊, 但是, 一旦漲價的時候, 自動會給使用者(AppleID)的裝置彈出提示, 通知使用者訂閱的新價格, 使用者在這個時候, 是可以直接退訂的. 

通過自己的實踐, 以及閱讀蘋果的資料, 大概總結了以上的內容, 僅供參考. 

 自動訂閱商品在訂閱過程及訂閱完成後的有效期內，均可理解為非消費品，其支付過程及恢復流程（這裡特指蘋果自身的恢復流程）均和非消費品相同。

           目前主要有如下幾個問題需要注意：

           1、訂閱到期的處理

                     目前網上並沒有對於訂閱到期的明確處理方式，目前據說有如下幾種做法：

a、訂閱到期或者使用者手動取消訂閱之後，再次進入客戶端，會收到蘋果發來的回撥，就是在之前的購買成功/失敗/恢復流程接收回調的observer裡，客戶端根據該回調進行相關處理。

這其實是最合理的處理方式，但是經過自測，發現客戶端並未收到任何訊息，至少在測試環境下沒有收到任何訊息，網上有朋友說是測試環境收不到，但是正式環境可以收到，由於測試難度較大，所以一直沒有拿線上產品這麼嘗試過。

b、客戶端自行連伺服器判斷是否訂閱過期，過期之後執行恢復流程。

執行恢復流程確實可以達到目的，可以通過恢復回來的receipt向蘋果驗證，從而得到使用者在蘋果當前的訂閱資訊。但是恢復流程的一個致命缺陷就是需要輸入密碼，而且使用者可以選擇不輸入，這樣的話使用者體檢就大打折扣了。

c、客戶端在訂閱成功後將蘋果返回的receipt記錄本地，每次程式啟動後（防止客戶端時間被篡改的情況）向蘋果驗證一次訂閱是否有效，然後執行後續邏輯。

這樣處理也可以達到目的，但是與其如此做，還不如把記錄和驗證receipt的工作放在伺服器，過期時間也由伺服器判斷，這樣可以保證穩定性，同時也可以優化流程。

     因此可考慮如下操作：

                     當客戶端訂閱成功之後，蘋果會返回當前訂閱的有效期及其相應的receipt，伺服器記錄這些引數。

                     在訂閱到期時（可先由客戶端判斷訂閱是否到期，未到期則不做處理，客戶端判斷到期則先向伺服器驗證是否真的訂閱到期，若伺服器也判斷為訂閱到期，則說明確實到期），伺服器用之前記錄的receipt向蘋果再次驗證，通過蘋果返回的錯誤碼來判斷使用者已經自動續訂還是手動取消訂閱。

                     在這個過程中，客戶端不需要做任何處理，只需要走check訂閱有效期的流程即可。（當客戶端判斷出使用者已經不在有效期後，會向伺服器請求，伺服器會將新的有效期下發給客戶端）

           2、使用者手動篡改時間的預防機制

                     可考慮如下操作：

     在客戶端訂閱成功之後，蘋果會返回當前訂閱的有效期間（起始時間＋中止時間，是兩個時間點），客戶端記錄該時間。

                     每當程式切換到前臺之後，獲取系統當前時間。用該時間對上述已記錄的訂閱有效期進行驗證。若當前時間仍在訂閱有效期內，則更新起始時間為當前時間；若不在有效期內，則向伺服器傳送請求，伺服器將當前時間及有效期等相關資訊回傳給客戶端，客戶端再次檢測當前是否在有效期之內，然後執行後續流程。

                     這樣處理可以不停的縮短使用者的訂閱有效期，並在很大程度上避免客戶端修改本地時間的作弊行為。

                     由於每套訂閱流程對應的業務邏輯不同，因此目前暫定為訂閱模組可返回一個BOOL標誌當前是否在有效期之內，和兩個時間戳，標識訂閱起始時間和終止時間，由外部接到返回資料之後進行自身業務邏輯的處理。

                     由於本支付模組包含多處訂閱＋普通購買，因此每一處訂閱可使用一個family標籤，其中可包含多個期間檔。不同的訂閱使用不同的family。

                     一個family下可以包含多個訂閱商品，但最多6個（7天，1個月，2個月，3個月，6個月，1年）。同一個family下的多個商品，當已有商品被訂閱且當前仍在有效期時（如7天），其他商品（如1個月）不可被訂閱。不同family沒有此限制。

           5、過度訂閱

                      需要確定訂閱到期之後，是否所有訂閱過程中獲取到的資訊全部清零，如有需要延續的物品，則需要考慮過度訂閱的問題。如在某些應用中，在訂閱期內把所有的商品都購買了，然後取消訂閱。這裡需要考慮清楚預防機制。

           6、恢復流程相關

                     該恢復流程是指廣義上的恢復，即通過伺服器的同步操作，可將使用者的相關資訊跨裝置共享，操作物件為已登陸使用者和獲取openUDID後的未註冊使用者。

                     可優先選擇使用伺服器的同步操作，同步完成之後，可提示使用者是否需要執行蘋果的恢復操作，並以此來決定是否執行蘋果的恢復流程（狹義上的恢復流程）。如需執行蘋果的IAP恢復操作，則需要注意從蘋果拿到資料後的處理，有些資料可能在伺服器同步的過程中已經被恢復過了，這裡要注意相容。

           7、管理已訂閱內容

1. 在裝置的主螢幕上，輕按 App Store。
2. 輕按螢幕底部的精品推薦。
3. 滾動到頁面底部。
4. 輕按左下角的 Apple ID 按鈕。（如果未登入，可輕按登入按鈕並通過您的 Apple ID 登入。然後滾動回頁面底部，輕按Apple ID 按鈕。）
5. 輕按檢視 Apple ID 按鈕。
6. 輸入您的密碼，然後點按“好”。
7. 在帳戶主頁面上，向下滾動並輕按管理 App 訂閱。如果您沒有 app 訂閱，此按鈕將不顯示。
8. 從 iPhone、iPad 或 iPod 上的“管理 App 訂閱”頁面中，輕按您要管理的 app。
9. 根據不同的 app，您可以選擇管理不同的訂閱類別。