In-App-Purcharse 官方原文摘要笔记

这并不是一篇关于 In-App-Purcharse 的专业深入分析文章，只是在初次浏览有关IAP官方文档后记录的一些需要注意的地方，就像是课堂笔记。

因为这是原版、并且涉及到支付的内容，所以就不翻译，以免引起歧义，原文会让你更准确的理解文档。

如果各神有更多的踩坑经验，欢迎 回复、分享~

后续我自己的 踩坑经验 和 深入体会 也会继续更新

作为一个专业围观者、为了刷刷访问量、为了提高曝光率。。。。。转载请注明出处：http://www.cnblogs.com/zhuocheng/p/3512740.html

Good luck for you & your customer ~~

Updated by Zhuocheng Lee - 2014.1.9

---

购买信息标识：

To provide this information, populate the applicationUsername property of the payment object with a one-way hash of the user’s account name on your server
only in iOS 7 ！！

---

结束购买：

Finishing a transaction tells Store Kit that you’ve completed everything needed for the purchase. Unfinished transactions remain in the queue until they’re finished, and the transaction queue observer is called every time your app is launched so your app can finish the transactions.
Complete all of the following actions before you finish the transaction:
Persist the purchase.
Download associated content.

Update your app’s UI to let the user access the product.

---

不要这样：

Don’t try to call the finishTransaction: method before the transaction is actually completed, attempting to use some other mechanism in your app to track the transaction as unfinished. Store Kit isn’t designed to be used this way. Doing so prevents your app from downloading Apple-hosted content and can lead to other issues.

After you finish a transaction, don’t take any actions on that transaction or do any work to deliver the product. If any work remains, your app isn’t ready to finish the transaction yet.

---

订阅时间的计算：

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.

---

自动续订的策略：

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.

---

取消订阅：

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.

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.

---

多平台购买：

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.

---

自动续订测试：
For the sake of testing, there are some differences in behavior between auto-renewable subscriptions in the production environment and in the 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.
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.

---

恢复购买验证：

Restoring purchases prompts for the user’s App Store credentials, which interrupts the flow of your app: because of this, don’t automatically restore purchases, especially not every time your app is launched.

---

恢复receipt：

in iOS 7, use initWithReceiptProperties: method of SKReceiptRefreshRequest.

if you need to support versions of iOS earlier than iOS 7, where the app receipt isn’t available, restore completed transactions instead.

restore：

in iOS 7，If your app sets a value for the applicationUsername property of its payment requests, as described in “Detecting Irregular Activity,” use therestoreCompletedTransactionsWithApplicationUsername: method to provide the same information when restoring transactions.

---

初次提交商品：

The first time you submit your app for review, you also need to submit in-app products to be reviewed at the same time. After the first submission, you can submit updates to your app and products for review independently of each other.

---

提交测试：

When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production”, validate against the test environment instead.

---

验证receipt：

Perform receipt validation immediately after your app is launched, before displaying any user interface or spawning any child processes. Implement this check in the main function, before the NSApplicationMain function is called. For additional security, you may repeat this check periodically while your application is running.

---

receipt的验证响应：

The receipt field on the JSON object holds the parsed information from the receipt. The receipt data for an auto-renewable subscription includes some additional keys, and some other keys are used differently for subscriptions. For information about keys found in a receipt, see “Receipt Fields.”
In addition to the receipt field, the response may also include two other fields. If the user’s subscription is active and was renewed by a transaction that took place after the receipt your server sent to the App Store, the latest_receipt field includes a base-64 encoded receipt for the last renewal for this subscription. The decoded data for this new receipt is also provided in the latest_expired_receipt_info field. Your server can use this new receipt to maintain a record of the most recent renewal.

---

几个关键的receipt验证响应字段：

Receipt Expiration Date
The date that the app receipt expires.
ASN.1 Field Type 21
ASN.1 Field Value IA5STRING, interpreted as an RFC 3339 date
JSON Field Name expiration_date
JSON Field Value IA5STRING, interpreted as an RFC 3339 date
This key is present only for apps purchased through the Volume Purchase Program. If this key is not present, the receipt does not expire.
When validating a receipt, compare this date to the current date to determine whether the receipt is expired. Do not try to use this date to calculate any other information, such as the time remaining before expiration.

Original Transaction Identifier
For a transaction that restores a previous transaction, the transaction identifier of the original transaction. Otherwise, identical to the transaction identifier.
ASN.1 Field Type 1705
ASN.1 Field Value UTF8STRING
JSON Field Name original_transaction_id
JSON Field Value string
This value corresponds to the original transaction’s transactionIdentifier property.
All receipts in a chain of renewals for an auto-renewable subscription have the same value for this field.

Purchase Date
The date and time that the item was purchased.
ASN.1 Field Type 1704
ASN.1 Field Value IA5STRING, interpreted as an RFC 3339 date
JSON Field Name purchase_date
JSON Field Value string, interpreted as an RFC 3339 date
This value corresponds to the transaction’s transactionDate property.
For a transaction that restores a previous transaction, the purchase date is the date of the restoration. Use “Original Purchase Date” to get the date of the original transaction.
In an auto-renewable subscription receipt, this is always the date when the subscription was purchased or renewed, regardless of whether the transaction has been restored.

Original Purchase Date
For a transaction that restores a previous transaction, the date of the original transaction.
ASN.1 Field Type 1706
ASN.1 Field Value IA5STRING, interpreted as an RFC 3339 date
JSON Field Name original_purchase_date
JSON Field Value string, interpreted as an RFC 3339 date
This value corresponds to the original transaction’s transactionDate property.
In an auto-renewable subscription receipt, this indicates the beginning of the subscription period, even if the subscription has been renewed.

Subscription Expiration Date
The expiration date for the subscription, expressed as the number of milliseconds since January 1, 1970, 00:00:00 GMT.
ASN.1 Field Type 1708
ASN.1 Field Value IA5STRING, interpreted as an RFC 3339 date
JSON Field Name expires_date
JSON Field Value number
This key is only present for auto-renewable subscription receipts.

---

---

add by Zhuocheng Lee

Good luck for you & your customer ~~

2014.1.9