iOS: Things to ensure while implementing In-App Purchase Subscription

This is a short article that doesn't describe the implementation and working of In-App purchase subscription rather it states the common problems faced while implementing In-App Purchase Subscriptions.

IAP Product doesn't load

• If your subscription doesn't load while initiating SKProductsRequest with the product identifier, please check whether the subscription product id from the AppStore Console matches with your code.
• Also, Your product wouldn't load if the bundle identifier of the app and the bundle identifier of the app within which the subscription product is created mismatches.

Avoid Local Receipt Validation

• If you are validating the subscription within the app, the best practice is to avoid local receipt validation and validate it using the HTTP Request validation provided by Apple (Verify Receipt API(Sandbox and Prod)). The reason to avoid local receipt validation is local receipt can be modified in the device and in the case of jailbreak devices, it requires less effort to modify the local receipt. This will allow the user to continue using your app without paying for the subscription.

Fields to check out for API Receipt Validation

A short tip on validating the API receipts,

• To make sure the subscription is valid, you could use expires_date, purchase_date, cancellation_date from the latest receipt info and compare it with any third party current time API (or) SKPaymentTransaction.date since the current date from the device can be modified by the user.
• You could also use auto_renew_status, is_in_billing_retry_period, expiration_intent, grace_period_expires_date from the pending renewal info to make sure on the renewal status and notify the user based on it.
• Click on the link, to know more about the properties associated with the API response. Below is the structure of the response JSON from which you need to get the above-mentioned values.

{
  "latestReceiptInfo": [
    {
      "expiresDate": "2021-12-11 07:32:28 Etc/GMT",
      "purchase_date": "2020-12-12 07:32:28 Etc/GMT",
      "cancellation_date": "Key is shown based on Availability"
    }
  ],
  "pendingRenewalInfo": [
    {
      "auto_renew_status": "0",
      "is_in_billing_retry_period": "0",
      "expiration_intent": "1",
      "grace_period_expires_date": "2021-12-13 07:32:28 Etc/GMT"
    }
  ]
}

Adding Fallback to the Sandbox API from the Production API

• If your app with the subscription is submitted for the first time in App Store, please make sure to add a fallback to Sandbox Verify Receipt API, if the status in the response JSON shows 21007. Until your first release of the app is in the AppStore, Apple generates the receipt to be validated in the sandbox environment. If the fallback isn't added, then the receipt wouldn't be verified and your app doesn't allow the user to access the paid features. This will result in the Appstore rejection stating that the app wouldn't allow to access paid features even after the payment.

Well, that's a wrap for the common things faced while implementing IAP Subscription, Hope you avoid the above-mentioned ones. Happy Coding!!!