I'm (re) building an app for iOS and Android that has an existing subscription model (monthly and annual) through IAP.
There's already an existing app which has users subscribed, for the rebuild i'm reusing the current product/subscription IDs in Google Play Console/App Store Connect.
I'm using Cognito for login and when a (new) user subscribes I have a webhook setup that listens for events from the respective store and stores the subscription status as a claim against the user. This also works for when a user cancels/modifies their subscription, i'll get an event to the webhook and update the backend accordingly.
My problem however, is this
I need to migrate any existing users with existing subscriptions across to my new app, to for this to be a success I need:
A list of users that have an active subscription using the existing subscription/product IDs
Once I have this I can create users in Cognito and ensure their subscription status is correct, is there an endpoint/approach for each platform that allows me to get a list of users with an active subscription? Alternatively is there any event I can hook into from the subscriptions/purchases webhook that would allow me to do this?
The key is I need to make sure that any existing users that login have their subscription on the new app and for this to happen I need to know their current subscription status so I can store it against them in Cognito.
Any help is greatly appreicated
Related
I started to implement Google Play Billing flow (Subscriptions only) for simple use cases but surprisingly there are quite limited articles showing how to do it in an optimal way. ClassyTaxi example (https://github.com/android/play-billing-samples/tree/3f34105c34e2ed2e88055ccf2b04088e8a5fd3a2/ClassyTaxiJava) is in my opinion over-complicated and mix some functions (e.g. acknowledging by Android app instead on back-end server).
Simple case:
App is built around Firebase services (Auth, Firestore, Cloud Functions, etc.)
Subscriptions are linked to the App user
Only one subscription type (Premium access), billed monthly or yearly
My billing flow for new purchases:
Android app starts BillingClient based on the subscription billing frequency chosen by the user
After successful payment processing, BillingClient sends a notification via RTDN/PubSub
Cloud Function processes that notification gets all Purchase data (Purchases.subscriptionsv2:get), verify it, stores in Firestore ("PurchasesCollection") with userId, and acknowledges
(Optional) Send FCM notification to all user devices about SubsctiptionState change
Android app listens "PurchasesCollection" to react to any Purchase change
With this approach, the Android app is just listening to Firestore changes and not making any Purchase processing activities as all of them are done on the server side.
In case of any Purchase changes (cancellations, pausing, expiring, etc.) Cloud Function will receive notification via RTDN and updates existing purchase, so the Android app will always get the most recent Subscription status and data.
Are there any drawbacks or security issues I didn't take into account?
In case the Android app just needs to confirm if a user is entitled to receive Premium access would it be sufficient to make a simple check expiryTime = Future (for at least one purchase from the list of all users' purchases)?
What is the most optimal and secure flow for this simple case?
I would like to know if there is an API or endpoint that I can call/use to retrieve active subscriptions or the purchase history for a user and only to a specific app. To explain what I want to achieve, I am going to tell you what I currently have developed:
An Android app that has an active subscription that users can subscribe to.
Once a user pays and Google Play calls onPurchasesUpdated(), to deliver the result of the purchase operation, the app handles the purchase.
To handle the purchase, the app sends the sku, purchaseToken and other relevant information to our server.
As soon as the server returns a 200 OK to the app HTTPS POST request, the app acknowledges that subscription based on the purchaseToken.
If a user wants to check their active subscriptions that information is available through the following url: https://play.google.com/store/account/subscriptions
If a user wants to check their purchase history that information is available through the following url: https://play.google.com/store/account/orderhistory
So based on this information, I would like to know how can I obtain information about all the purchases (or the last one), either with the Google Play Billing Library or the Google Play Developer API (or other), so that I can access the purchaseToken information. My objective is to have a way to access, from within the app, a list of that user's subscriptions or just it's last purchaseToken. Note that I do not want to get access to a list that includes other apps purchases or history. Only the info about my app.
Can any one provide complete documentation for auto renew subscription and update status on backend using android developer notification with pub/sub?
We have to do Monthly & Yearly auto renew in app purchase subscription. If we subscribe using app,then we are getting purchase token and updating on backend.I have some query for auto renew subscription.
Please check the same as below:
1.Do we need to check subscription status at the time subscription period over using cron job? If yes,do we need to pass same purchasetoken in Purchases.subscriptions: get api?
2.If we enable developer notification for real time update on server,then we are getting notification on server. It doesn't contain any purchase information or unique user id.
Please check the below documentation :
https://developer.android.com/google/play/billing/realtime_developer_notifications
Real-time developer notifications do not provide full information about the state of the subscription, such as whether the user is currently entitled to access subscription content. When you receive the token, you should always use the purchase token to query the Google Play Developer API to get the full information and update your backend with the user's current entitlement status.
-> Will we get purchase token from realtime developer notifications?
I implemented with the help of the official implementation. I hope this helps.
I've implemented a recurring subscription for Android In App Billing, but I'm wondering how the apps knows that the subscription is renewed. In testing, at least, the subscription is ended after 1 day. Will it be continued when the app is published on the store?
On iOS the testing subscription is renewed a couple of times. Enough to let you test when the subscription is renewed, but what is the best way to do this on Android?
Can I use the purchaseToken to let my server query Google Play API or do ever renewed subscription get a new purchaseToken?
In android IAP, The purchase token expires when the user manually cancels the subscription or disables the auto-renew. Otherwise, you will get a valid purchase token every time. In test mode, the tester's subscription automatically gets expired after 5 minutes but in production, it will work fine. So don't get worried about the production behavior. If you are running the app as a tester, you will get the below payment modes on the payment flow start.
You will have 2 options to test your implementation
Test Card(Always Approves)
Test Card(Always Declines)
By testing both of the cards, you can be sure about the implementation. Your app should be capable of handling both responses from IAP. If both flows goes well, You shouldn't be worried about it. You are ready to roll-out it on production. Here is the Official Docs, may help you to understand the entire flow.
If you designed custom flow to manage IAP, You can verify the IAP Token from backend using the Google Play Developer API and allow the user to consume the feature accordingly. For the custom flow, You can send custom JWT token from backend according to IAP Token expiry and set custom JWT Token exp claim. By using this method you can check the custom token is expired or not in the client-side, If it's happened so, You can fetch the new IAP token and send it to your backend. Your backend should validate that IAP token and issue new JWT token to user and cycle goes on. Let me know if you want the custom flow, I'll post it here.
You simply periodically query the Google Play server to check the items that the user own, if it is a subscription, it will reply that he/she owns it while it is active and therefore has not expired.
Do not forget to verify the signature of the received data, and much better using a server side verification
Android - protecting in app purchases with server side verification
How do I implement (Auto-renewable) Subscriptions for an Android App.
I've read the documentation
and as far as I understand, the process is the following:
User subscribes to such a subscriptions on the app. This will generate a Purchase token.
The app sends this token to the server along with something to identify this user
The server will store this Purchase token with this user and will mark the subscription as valid
the server validates this Purchase token via the http-api periodically (typically once per day) with something like a cronjob
if the subscription isn't valid anymore, the subscription will be marked as invalid on the server-side.
If the app makes requests to the server to resources that need the subscription, the client will send this user-identity-string along with the requests. We then check in the database, if the subscription of this user is still marked as valid.
My question is now, how we should identify this users? Do we have a simple user id available that we can share between our app and our server? or should we use something different? What is the best practice here?
We did already similar subscriptions on ios and we used the uuid of the device to identify the users (at least as long as we were able to use the uuid).
From the Answer below we should generate a unique ID. This would be unique per device (or per app-installation). But if a user changes his device or reinstalls the application this id would not be the same anymore. So I'm not sure, how the process is in this use case. I thought of something like this:
The user is logged in with the same google play account on his second device.
As the app starts (or becomes active) we would fetch the users subscriptions
We then would receive this purchase token from the subscriptions and send them along with the new unique-ID to our backend-server as if the user had made a new subscription.
Would this be the right process? And stays the purchase token the same as it was on the first device?
Ok, my question about identifiying users is answered, the link provided delivers enough informations. I'll put further questions in new threads on SO, if I have some.
This link maybe helpful to you as you want to identify the users uniquely.Please note that the personal information of a user rests with Google only.And you should avoid getting private information of a user.
http://www.pocketmagic.net/2011/02/android-unique-device-id/#.URIe_B3Wgr7