In-App Purchase Programming Guide----（六) ----Working with Subscriptions

 

Working with Subscriptions

Apps that use subscriptions have some additional behaviors and considerations. Because subscriptions incorporate an element of time, your app needs to have the appropriate logic to determine whether the subscription is currently active and what time periods the subscription was active in the past. Your app also needs to react to new and renewed subscriptions, and properly handle expired subscriptions. Figure 5-1 shows an example subscription timeline, including some of the complexities your app needs to handle.

使用訂閱(subscriptions)的應用有一些額外的行爲和注意事項(considerations)。 由於訂閱包含時間元素，應用程序須要有適當的邏輯來決定訂閱當前是否處於活動狀態以及過去該訂閱活動的時間段。 應用程序還須要應對新的和更新的訂閱，而且須要正確地處理過時訂閱。 圖5-1 舉了一個訂閱時間表的例子，包括一些應用程序須要處理的復瑣事項(complexities )。

Figure 5-1  Example subscription timeline

Calculating a Subscription’s Active Period

1、計算一個訂閱的活動期

Your app needs to determine what content the user has access to based on the period of time the subscription was active. Consider, for example, a user with a subscription to a magazine that publishes a new issue on the first day of each month, following the timeline shown in Table 5-1.

應用程序須要在訂閱處於活動狀態的期間內決定用戶訪問什麼內容。 舉個例子，一個用戶訂閱了一個雜誌，該雜誌在每月的第一天發佈新刊，如圖5-1中的時間表：

Table 5-1  Timeline of a sample subscription表 5-1 一個示例訂閱的時間表

Date	Event
February 1	February issue is published. It is not made available because the user has not yet subscribed. (It is made avaibalbe later, after the user subscribes.) 二月刊發佈。用戶不可用，由於他尚未訂閱(訂閱後就可使用)。
February 20	User subscribes with a duration of one month. January issue is made available immediately. 用戶訂閱了一個月期限的雜誌。一月刊當即可使用。
March 1	March issue is published. It is made available immediately because the user has an active subscription. 三月刊發佈。用戶當即可使用，由於它已經有一個活動的訂閱。
March 20	The user’s subscription automatically renews for another month. 用戶的訂閱自動續訂一個月。
April 1	April issue is published. It is made available immediately because the user has an active subscription. 四月刊發佈。用戶當即可使用，由於它已經有一個活動的訂閱。
April 20	The user prevents the subscription from renewing, ending the subscription period. 用戶結束了續訂。
May 1	May issue is published. It is not made available because the user’s subscription has lapsed. 五月刊發佈。 用戶不可用，由於訂閱已經失效。
June 1	June issue is published. It is not immediately made available because the user’s subscription has lapsed. (It is made available later, after the user resubscribes.) 六月刊發佈。用戶不可用由於訂閱已經失效(用戶從新訂閱就能夠立刻使用)。
June 17	User resubscribes. June issue is made available immediately. 用戶從新訂閱。六月刊當即可用。
July 1	July issue is published. It is made available immediately because the user has an active subscription. 七月刊發佈。用戶當即可使用，由於它已經有一個活動的訂閱。

To implement this logic in your app, keep a record of the date that each piece of content is published. Read the Original Purchase Date and Subscription Expiration Date field from each receipt entry to determine the start and end dates of the subscription. (For information about the receipt, see Receipt Validation Programming Guide.) The user has access to all content published between each start and end date, as well as the content that was initially unlocked when the subscription was purchased. If the subscription lapsed, there will be multiple periods of time during which the subscription was active, and there will be pieces of content unlocked at the beginning of a subscription period.

要想在應用程序中實現該邏輯，保留一個關於每刊內容發佈的日期記錄。 從每一個收據項目中讀取初始購買日期和訂閱到期時期來決定訂閱的開始和結束日期。 (關於收據的更多信息，請看 Receipt Validation Programming Guide.) 用戶能夠訪問全部在開始日期和結束日期之間發佈的內容以及它初次購買時解鎖的內容。 若是訂閱失效(lapsed),將由訂閱活動期間的多個時間期，以及在一個訂閱期的開始時又多刊內容解鎖。

Note: Don’t calculate the subscription period by adding a subscription duration to the purchase date. This approach fails to take into account the free trial period, the marketing opt-in period, and the content made available immediately after the user purchased the subscription.

注意：不要經過添加一個訂閱持續時間到購買日期中來計算訂閱期。 該方法沒有考慮到應用試用期，市場選擇期，並讓用戶購買了訂閱以後立刻解鎖內容。

 

Continuing the example from Table 5-1, the receipt would show the following start and end dates:

從表5-1開始繼續示例，收據將顯示如下開始和結束日期：

• February 20 – March 20

• March 20 – April 20

• (The lapse from April 20 – June 17 is not recorded explicitly in the receipt.)

• June 17 – July 17

The user has access to the February and June issues because they were initially unlocked when the subscription was purchased or restarted.

用戶能夠訪問二月和六月刊，由於它們時在訂閱被購買或從新訂閱時解鎖的內容。

The user has access to the March, April, June, and July issues because the subscription is active at those times.

用戶能夠訪問三月，四月，六月以及七月刊，由於在這些時間訂閱是活動的。

Expiration and Renewal

2、到期和續訂

The renewal process begins with a 「preflight」 check, starting ten days before the expiration date. During those ten days, the App Store checks for any issues that might delay or prevent the subscription from being automatically renewed—for example, if the customer no longer has an active payment method, if the product’s price increased since the user bought the subscription, or if the product is no longer available. The App Store notifies users of any issue so that they can resolve it before the subscription needs to renew, ensuring their subscription isn’t interrupted.

續訂過程在到期日期前10天開始預檢。 在那10天中，應用商店檢查任何可能致使自動續訂延遲或沒法續訂的狀況---好比，若是用戶沒有一個可用的支付方法，若是用戶購買了訂閱以後，產品價格升了，又或者若是產品已經不存在。 應用商店通知用戶任何問題，這樣他們就能夠在續訂以前解決這些問題，以確保不會終止他們的續訂。

Note: Increasing the price of a subscription doesn’t disable automatic renewal for all customers, only for those customers whose subscription expires in the next ten days. If this change is a mistake, changing it back to the original price means no additional users are affected. If this change is intentional, keeping the new higher price causes automatic renewal to be disabled for the rest of your users in turn as they enter the ten-day renewal window.

 注意：提升訂閱價格並不會終止全部用戶的自動續訂，只要那些用戶的到期時間是在將來10天以內。 若是該價格改變是一個錯誤，把價格改回原來的價格並不會影響任何用戶。 若是是有意的提交價格，一直保留該新價格將致使依次進入10天續訂窗口的其餘用戶不能進行自動續訂。

During the 24-hour period before the subscription expires, the App Store starts trying to automatically renew it. The App Store makes several attempts to automatically renew the subscription over a period of time but eventually stops if there are too many failed attempts.

在訂閱到期的前24個小時期間，應用商店開始嘗試自動續訂。 儘管應用商店在自動續訂期間會屢次嘗試自動續訂，可是若是失敗次數太多則會終止自動續訂。

The App Store renews the subscription slightly before it expires, to prevent any lapse in the subscription. However, lapses are still possible. For example, if the user’s payment information is no longer valid, the first renewal attempt would fail. If the user doesn’t update this information until after the subscription expires, there would be a short lapse in the subscription between the expiration date and the date that a subsequent automatic renewal succeeds. The user can also disable automatic renewal and intentionally let the subscription expire, then renew it at a later date, creating a longer lapse in the subscription. Make sure your app’s subscription logic can handle lapses of various durations correctly.

儘管應用商店在它快要過時以前自動續訂來防止丟失任何訂閱。 可是，任然有可能丟失。好比，若是用戶的支付信息已經失效，第一次續訂將失敗。 若是用戶一直不更新該支付信息直到訂閱到期，在到期時間和下一次自動續訂成功以前這段時間將有一小段時間的丟失。 用戶也能夠關閉自動續訂並故意讓訂閱到期，而後在之後續訂它，長期丟失訂閱。 請肯定你的應用程序的訂閱邏輯能正確地處理不一樣時間的丟失。

After a subscription is successfully renewed, Store Kit adds a transaction for the renewal to the transaction queue. Your app checks the transaction queue on launch and handles the renewal the same way as any other transaction. Note that if your app is already running when the subscription renews, the transaction observer is not called; your app finds out about the renewal the next time it’s launched.

 當成功續訂以後，商店Kit把續訂交易添加到交易隊列中。應用程序在啓動時檢查交易隊列而且同處理其它任何交易同樣處理它。 注意若是在續訂時應用程序已經運行，那麼交易觀察者將不被調用；應用程序在下一次啓動時找到續訂記錄。

Cancellation

3、取消

A subscription is paid for in full when it’s purchased and can be refunded only by contacting Apple customer service. For example, if the user accidentally buys the wrong product, customer support can cancel the subscription and issue a refund. It’s not possible for customers to change their mind in the middle of a subscription period and decide they don’t want to pay for the rest of the subscription.

購買了一個訂閱後得全額付款，只有經過聯繫蘋果客服服務才能退款。 好比，若是用戶意外買錯了產品，客服中心能夠取消該交易並退款。 用戶不能在一個訂閱週期中間改變注意不支付剩餘的訂閱。

To check whether a purchase has been canceled, look for the Cancellation Date field in the receipt. If the field has a date in it, regardless of the subscription’s expiration date, the purchase has been canceled—treat a canceled receipt the same as if no purchase had ever been made.

要想確認某次交易是否已經被取消，在收據(receipt)中查找Cancellation Date(取消日期)字段。 若是該字段有日期，無論該訂閱的過時日期是什麼，該交易都已經被取消---取消交易就是跟一直沒有購買過同樣。

Depending on the type of product, you may be able to check only the currently active subscription, or you may need to check all past subscriptions. For example, a magazine app would need to check all past subscriptions to determine which issues the user had access to.

 根據產品類型，你或許只能檢查當前的活動交易，或者你可能須要檢查過去全部的交易。好比，一個雜誌應用須要檢查過去全部的交易來決定用戶訪問了那些期刊。

Cross-Platform Considerations

4、跨平臺注意事項

Product identifiers are associated with a single app. Apps that have both an iOS and OS X version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an OS X app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions.

產品識別碼只能綁定到一個應用程序。同時有iOS和OS X版本的應用程序是不一樣的應用程序並分別帶有不一樣的產品識別碼。 你可讓在一個iOS應用中購買了訂閱的用戶從OS X應用(或其它平臺)訪問它購買的內容，可是這功能你應該本身實現。你會須要一些系統來識別用戶並保持跟蹤他們已經訂閱了什麼內容，相似於你會給一個no-renewable subscriptions(不可再生訂閱)應用程序實現什麼。

Letting Users Manage Subscriptions

5、讓用戶管理訂閱

Rather than needing to code your own subscription management UI, your app can open the following URL:

不須要你本身編碼實現本身的訂閱管理UI，你的應用程序能夠打開如下URL：

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

Opening this URL launches iTunes or iTunes Store, and then displays the Manage Subscription page.

打開該URL啓動iTunes 或者 iTunes商店，而後顯示管理訂閱頁面。

The Test Environment

六、測試環境

 

For the sake of testing, there are some differences in behavior between auto-renewable subscriptions in the production environment and in the test environment.

爲了測試，自動再生訂閱在產品環境(production environment) 和 在測試環境(test environment)中的行爲有所不一樣。

Renewal happens at an accelerated rate, and auto-renewable subscriptions renew a maximum of six times per day. This lets you test how your app handles a subscription renewal, a subscription lapse, and a subscription history that includes gaps.

更新發生在加速時，而且自動更新訂閱天天最多更新6次。 這樣讓裏測試你的應用程序如何處理一個訂閱更新，一個訂閱失效，以及一個包括缺口的訂閱歷史。

Because of the accelerated expiration and renewal rate, the subscription can expire before the system starts trying to renew the subscription, leaving a small lapse in the subscription period. Such lapses are also possible in production for a variety of reasons—make sure your app handles them correctly.

由於加速的到期和更新速度，訂閱能夠在系統開始嘗試更新訂閱以前過時，在訂閱期間留下一個小失誤。 由於各類緣由，這樣的失誤在產品中也一樣可能存在---請確保你的應用程序能夠正確地處理它們。

下一頁       上一頁