Auto renewable subscriptions allow customers access to content, services, or premium features in your app by subscribing to it. After completion of each subscription period, the subscription automatically renews until a user manually cancels it. Developers can offer subscriptions along with other in-app purchase products within the app.
- Premium content
- Episodic content
- Software as a Service
- Cloud support
Other appropriate subscriptions include apps that offer stable/pro updates, or access to libraries or collections of content.
How does it work on iOS?
Apps that offer subscriptions have some additional tasks to be performed. As each subscription has time period linked with it, an app should consider the time duration based on the receipt to allow customer access to specific content or service and should efficiently handle subscription events such as activation, cancellation, renewal, expiration and should behave based on all these events.
In addition to this, an “In App Purchase Programming Guide” and “Receipt Validation Programming Guide” will be useful to integrate in app purchase methods to your native app easily. Also, status update notifications will be useful to track all the purchase updates in real time.
Here are some important links for in app purchase programming:
To verify receipt in sandbox environment,
To verify receipt in production environment,
Official guide to validate receipt with App Store,
In App Purchase Receipt fields guideline,
A status update notification is a server-to-server notification service for auto-renewable subscriptions provided by Apple. A notification is triggered only when there is any change in subscription status for that particular application or order.
Whenever the server receives any status update notification, it should verify the receipt with Apple to get the latest update on particular subscription. Apple recommends use of receipt validation along with the status update notification service to validate a customer’s current subscription status and eligibility for the service or content. See “Receipt Validation Programming Guide” for information about receipt validation.
To receive status update notifications, the developer should configure a subscription status URL in App Store Connect (https://help.apple.com/app-store-connect/#/dev0067a330b). The App Store will post some JSON objects via an HTTP POST to developer’s server for the key subscription events listed in below table. Developer’s server is responsible for parsing, interpreting, and responding to all status update notification posts sent to them.
The status update notification is an HTTP POST request. The body of the POST contains the elements listed in the below table.
The App Store Connect will post notification for the key events made to the subscriptions in the below table, which represents a complete list of notification types and corresponding subscription events.
Apple recommends to use the below URL to manage subscriptions from their UI and not to use app’s own UI:
Opening this URL launches iTunes or iTunes Store and displays the Manage Subscription page.
Note: Please make sure to accommodate user to restore their purchase on any device by enabling them with an option to RESTORE PURCHASE in the app itself. (AppStore will reject the app if one has not provided an option to restore the purchases made earlier.)
How it works on Android?
Google Play Billing is a service that lets developers sell digital content or premium features from inside an Android app, or in-app. It is almost the same as the subscription management part.
Google Play Billing monitors purchases or subscriptions using purchase tokens and order IDs.
- A purchase token(similar to original_transaction_id in iOS) is a string that represents a buyer’s entitlement to a product on Google Play. It indicates that a Google user has paid for a specific product, represented by a SKU.
- An order ID(similar to transaction_id in iOS) is a string that represents a financial transaction on Google Play. This string is included in a receipt that is emailed to the buyer, and third-party developers use the order ID to manage refunds in the Order Management section of the Google Play Console. Order IDs are also used in sales and payout reports.
For one-time products, every purchase creates a new token and a new order ID.
For subscriptions, a new subscription creates a purchase token and an order ID. For each renewing billing period, a new order ID is issued and the purchase token stays unique.
Any modification to the subscription or purchase such as upgrades, downgrades, and re-signups all create new order IDs and purchase tokens.
Subscriptions are created and managed using the Android Play Console (in-app products). Once the developer has a subscription configured, he can add Google Play Billing to his app by listing products and adding appropriate methods to enable the user to experience the purchase flow for the subscription. Subscriptions have many properties such as billing period, grace period, free trial, renewal, and so on.
Real-time developer notifications are server push notifications (same as statusUpdateNotifications in iOS) that give you the capability to monitor state changes such as creation, cancellation, refund, revoke, renewal, expiration and others.
Real-time Developer Notifications enables developers to respond to user’s subscription status changes immediately and react to the changes accordingly after verifying changes with Google Play Developer API.
Google Play Billing Library provides server push notifications (Cloud Pub/Sub) that let you monitor subscription state changes for Google Play-managed subscriptions of their apps. By enabling Real-Time Developer Notifications, the developer will receive an order id and purchase token directly from Cloud Pub/Sub anytime there is any key changes or update to an existing subscription.
Real-time developer notifications do not contain all the required info about the state of the subscription, such as whether the user has currently active subscription or not. Whenever you receive the notification, your server should always use the purchase token to query the Google Play Developer API to get the full info and update the user’s current subscription status.
More notification types can be added in the future. Your server should be able to handle all the unrecognized notifications types, and the developer should always rely on the Google Play Developer API for critical business logic, not on notifications.
Each publishes made to a Pub/Subtopic contains a single base64-encoded Developer Notification with the following fields:
A SubscriptionNotification contains the following fields:
Latest posts by Milan Manwar (see all)
- Build class-apart UI on apple devices using SwiftUI - March 1, 2021
- Introduction to ARKit 2 and Hands-on using ARKit 2 with Vision - September 20, 2019
- Basics of Create ML and Turi Create - September 17, 2019