版本記錄

前言

大家都知道，ios虛擬商品如寶石、金幣等都需要走內購，和蘋果三七分成，如果這類商品不走內購那么上不去架或者上架以后被發現而被下架。最近有一個項目需要增加內購支付功能，所以最近又重新集成并整理了下，希望對大家有所幫助。感興趣的可以參考上面幾篇。
1. iOS內購IAP（一） —— 基礎配置篇(一)
2. iOS內購IAP（二） —— 工程實踐（一）
3. iOS內購IAP（三） —— 編程指南之關于內購（一）
4. iOS內購IAP（四） —— 編程指南之設計您的應用程序的產品（一）
5. iOS內購IAP（五） —— 編程指南之檢索產品信息（一）
6. iOS內購IAP（六） —— 編程指南之請求支付（一）
7. iOS內購IAP（七） —— 編程指南之促進應用內購買（一）
8. iOS內購IAP（八） —— 編程指南之提供產品（一）

Working with Subscriptions - 處理訂閱

提供訂閱的應用程序具有一些其他行為和注意事項。 由于訂閱涉及時間元素，因此您的應用必須能夠確定訂閱當前是否處于活動狀態，并確定過去日期的訂閱狀態。 您的應用還必須對新的，續訂的和已失效的訂閱做出反應，并正確處理過期的訂閱。 圖6-1顯示了一個示例訂閱時間表，包括您的應用程序需要處理的一些復雜性。

Figure 6-1 Example subscription timeline

Calculating a Subscription’s Active Period - 計算訂閱的激活期

您的應用需要根據訂閱處于活動狀態的時間段來確定用戶可以訪問的內容。 例如，對于訂閱每月雜志的用戶，該雜志在每個月的第一天發布新內容，請考慮表6-1中顯示的時間表。

Table 6-1 Timeline of a sample monthly subscription

要訪問客戶有權訪問的所有內容，請記錄每個內容的發布日期。 從每個收據條目中讀取原始購買日期，購買日期和訂閱到期日期字段，以確定每個訂閱期間的開始和結束日期。 （有關收據的信息，請參閱Receipt Validation Programming Guide。）用戶可以訪問在每個訂閱開始和結束日期之間發布的所有內容，以及購買訂閱時最初解鎖的內容。 如果訂閱失效，則訂閱處于活動狀態的時間段將存在多個時間段，并且在訂閱期開始時將解鎖多個內容。

要識別訂閱中的失誤，請將每個收據條目的訂閱到期日期字段Subscription Expiration Date與收據中所有條目的先前收據條目的PurchaseDate字段進行比較。

注意：請勿通過在購買日期添加訂閱持續時間來計算訂閱期。 該方法未考慮免費試用期，營銷選擇期以及用戶購買訂閱后立即提供的內容。例如，由于在購買訂閱時內容始終處于解鎖狀態，因此在月中購買月度訂閱的用戶可以在每個月的第一天發布新內容的雜志在訂閱的第一個月內獲取兩份雜志 ：最近發布的雜志，在購買訂閱時解鎖，以及您在本月的第一天發布的雜志，該雜志在您發布時解鎖。

繼續表6-1中的示例，收據將顯示以下開始和結束日期：

• 2月20日 - 3月20日
• 3月20日 - 4月20日
• （4月20日至6月17日的失效未在收據中明確記錄。）
• 6月17日 - 7月17日

用戶可以獲取二月和六月的內容，因為他們最初在購買或重新啟動訂閱時已解鎖。

用戶可以獲取3月，4月，6月和7月的內容，因為訂閱在這些時間處于活動狀態。

Upgrades and Plan Changes - 升級和計劃變更

用戶可以在App Store或您應用的界面中的帳戶設置中管理他們的訂閱。 對于每個訂閱，App Store會顯示訂閱組提供的所有續訂選項。 用戶可以輕松更改其服務級別，并根據需要隨時選擇升級，降級或交叉級。 任何持續時間的降級或具有不同持續時間的交叉等級將在下一個續訂日期生效。

您可以查看收據的Subscription Auto Renew Preference字段，以了解用戶選擇的任何計劃更改，這些更改將在下一個續訂日期生效。 （有關收據的信息，請參閱 Receipt Validation Programming Guide。）

Expiration and Renewal - 到期和續訂

訂閱續訂過程在到期日期前十天開始。 在這十天內，App Store會檢查可能會延遲或阻止訂閱自動續訂的任何結算問題，例如：

• 客戶的付款方式不再有效，
• 自用戶購買訂閱以來，產品價格上漲，
• 該產品已不再可用。

App Store可以通知用戶任何問題，以便他們可以在訂閱到期之前解決它，并避免其訂閱服務中斷。

在訂閱到期之前的24小時內，App Store開始嘗試自動續訂。 App Store會多次嘗試在一段時間內自動續訂訂閱，但如果嘗試失敗次數過多，最終會停止。

注意：對于與結算相關的問題，App Store可能會嘗試續訂最多60天的訂閱。 您可以在收據中檢查訂閱重試標記Subscription Retry Flag，以確定App Store是否仍在嘗試續訂訂閱。

App Store會在訂閱到期之前稍微更新訂閱，以防止訂閱失效。但是，失誤仍然存在。例如，如果用戶的付款信息不再有效，則第一次續訂嘗試失敗。如果用戶在訂閱到期后更新其支付信息，則在到期日期和后續自動續訂嘗試成功的日期之間訂閱將會短暫失效。用戶還可以禁用自動續訂并有意讓訂閱到期，然后在以后續訂，從而在訂閱中創建更長的失效。確保您的應用程序的訂閱邏輯可以正確處理各種持續時間的失誤。您可以檢查訂閱自動續訂狀態字段以確定訂閱的續訂狀態。

成功續訂訂閱后，StoreKit會將續訂事務添加到事務隊列中。您的應用程序在啟動時檢查事務隊列，并以與任何其他事務相同的方式處理續訂。請注意，如果您的應用在訂閱續訂時已在運行，則不會調用事務觀察器；您的應用在下次啟動應用時會發現有關續訂的信息。

例如，下面的時間線顯示了用戶訂閱應用程序的帳戶，該應用程序每月提供服務。在該示例中，由于計費問題，訂閱暫時失效。用戶更正了問題，訂閱將以新的每月續訂日期續訂

Table 6-2 Example of a timeline for a monthly subscription

Cancellation - 取消

續訂在購買時全額支付。用戶只能通過聯系Apple客戶服務獲得退款。例如，如果用戶意外購買了錯誤的產品，客戶支持可以取消訂閱并發出全部或部分退款。客戶可以在訂閱期間取消訂閱，但訂閱仍在同一時期結束時支付。

要檢查Apple Customer Support是否已取消購買，請在收據中查找Cancellation Date字段。如果該字段包含日期，則無論訂閱的到期日期如何，購買都會被取消。關于提供內容或服務，將取消的交易視為從未進行過購買。

根據您的應用提供的產品類型，您可能需要檢查當前有效的訂閱期，或者您可能需要檢查所有過去的訂閱期。例如，雜志應用程序需要檢查所有過去的訂閱期以確定用戶應該訪問哪些雜志。具有流服務的應用程序僅需要檢查當前活動的訂閱以確定用戶是否應該訪問其服務。

Status Update Notifications - 狀態更新通知

statusUpdateNotification是用于自動續訂訂閱的服務器到服務器通知服務。 通知指定發送通知時的訂閱狀態。

要在處理事件時獲取最新信息，您的應用應通過App Store驗證最新收據。 建議您使用狀態更新通知服務以及收據驗證來驗證用戶的當前訂閱狀態并為其提供服務。 有關收據驗證的信息，請參閱Receipt Validation Programming Guide。

要接收狀態更新通知，請在App Store Connect中為您的應用配置訂閱狀態URL。 App Store將通過HTTP POST將JSON對象傳送到您的服務器，以獲取表6-3中列出的key訂閱事件。 您的服務器負責解析，解釋和響應所有statusUpdateNotification posts。

注意：使用服務器到服務器通知服務是可選的。 您可以隨時選擇加入。

statusUpdateNotification是HTTP POST。 POST的body包含表6-3中列出的數據元素。

Table 6-3 Status Update Notification Keys

App Store可以在表6-4中列出的任何條件下發布通知，表示通知類型和相應訂閱事件的完整列表

Table 6-4 Status Update Notification Types

要通過statusUpdateNotificationpost指示成功，您的服務器應發送HTTP狀態代碼200；您的服務器不需要返回數據值。 如果您的服務器發送50x或40x HTTP代碼，App Store將重試該通知。 App Store會在一段時間內多次嘗試重試通知，但如果嘗試失敗次數過多，最終會停止。

1. Security Requirements - 安全要求

在發送通知之前，App Store會嘗試使用App Transport Security（ATS）協議與您的服務器建立安全的網絡連接。 要了解有關ATS要求的更多信息，請參閱Requirements for Connecting Using ATS。 如果無法建立安全連接，則不會將通知發送到您的服務器。 有關安全性的更多信息，請參閱https://developer.apple.com/security/。

2. Status Update Notifications in the Test Environment - 測試環境中的狀態更新通知

建議您在生產中實現此邏輯之前測試測試環境中交易的statusUpdateNotifications。

要確定訂閱事件的狀態更新通知是否在測試環境中，請檢查statusUpdateNotification JSON對象中的environment鍵值是否等于SANDBOX。

Cross-Platform Considerations - 跨平臺考慮因素

產品標識符與單個應用相關聯。 具有iOS版本和macOS版本的應用程序具有單獨的產品，每個平臺上都有唯一的產品標識符。 您可以讓在iOS應用程序中訂閱的用戶從macOS應用程序獲取內容（反之亦然），但實現該功能是您的責任。 您需要一個系統來識別用戶并跟蹤他們訂閱的內容，類似于您為使用不可續訂訂閱的應用程序實現的內容。

Enabling Users to Manage Subscriptions - 使用戶能夠管理訂閱

您的應用可以打開以下網址，而不是實施自己的訂閱管理用戶界面：

https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions

打開此URL會啟動iTunes或iTunes Store并顯示Manage Subscription頁面。

The Test Environment - 測試環境

自動更新訂閱的行為在測試環境和生產環境之間有所不同。

在測試環境中，訂閱續訂速度加快，自動續訂訂閱每天最多續訂六次。 這使您可以測試應用程序如何處理訂閱續訂，訂閱失效以及包含間隔的訂閱歷史記錄。

由于加速到期和續訂率，訂閱可以在系統嘗試續訂訂閱之前到期，在訂閱期間留下一小段時間。 由于各種原因，這種失誤也可能在生產中出現 - 確保您的應用正確處理它們。

后記

本篇主要講述了處理訂閱，感興趣的給個贊或者關注~~~~