I would like to let users purchase a good for 3 months for one time.
In subscriptions, even the user can cancel a subscription, since the cancellation of purchases is not possible inside application and the way to cancel a subscription is not straight-forward i think this would return us with a lot of user complaint due to forgotten subscription fees.
Managed product purchases are permanent so they don't work in my case.
Is there a way to make one time purchases with expiry date?
There are no such products out of the box. You have to implement it in your backend. You may use managed product and handle expiration date manually in the app with synchronization with your server.
You may try to hack it without backend comparing purchase date and correct current time (some trusted time server).
Related
Perhaps I am simply not looking in the correct places, but I am surprised at the lack of documentation around cross-platform apps incorporating renewing subscriptions.
I have a cross-platform (iOS and Android) Ionic app with a Rails API for the back-end. I am using https://github.com/AlexDisler/cordova-plugin-inapppurchase as a wrapper around the iOS/Google store SDKs.
My question revolves around subscription renewal:
From what I gather, it is recommended that I have a daily job checking each of my subscriptions for their expiration date. If a subscription is about to expire, I can send the receipt stored in my database to either Google/Apple and check if the subscription has been renewed. If it has, I update the expiration date and keep the subscription active. If the subscription has not been renewed, I mark the subscription as inactive.
Now, what happens if a user renews a subscription? How will I know that a subscription has been renewed? And when do I check for subscription renewal? Seems like my options are:
Every day, check every expired subscription for renewal. Problems with this: 1) as the number of users grows, so will the number of users with expired subscriptions. Eventually, this will result in checking many, many expired subscriptions every night. 2) A user will be unable to access subscription-only content between the time they renew their subscription through the app/play store and the nightly subscription-checking job is run.
Every time a user with an expired subscription logs into the app, check to see if they have renewed their subscription. Problems with this: 1) My app uses token authentication. Therefore, users are not required to login with each use. So, if a user renews their subscription, but their token is still valid, the app will have no way of knowing that their subscription is up-to-date.
Is there another option? What am I missing here?
I would suggest using a combination of both options.
When a user opens your app you should send a separate request to your backend that will fetch the receipt a check if its renewed and cache the expiration date and the time it was checked. Then I would have another job run nightly that doesn't check all the expired receipts, but clears the expiration date cache if it hasn't been checked within a certain period. Then, the next time a user opens the app, the cache will be empty and and will be fetched.
I'm working on adding Android subscriptions to RevenueCat but it won't be ready for a couple months.
thansk for reading
Context
We provide on-demand video streaming that user can purchase via monthly or yearly subscription on android, ios & web
Thus whenever purchases was made on Android, the app send our server a (purchaseToken, subscriptionID) pair, and we use this google developer API to persists the subscription info in our db
Problem
Recently, we added support for user to change their plan on Android. On Google side, the money is prorated and the new subscription is created. However, the old subscription's start and end time is still the same on the developer API.
We can't say for sure that the old subscription was cancelled and replaced with a new one because the payload (defined here) only tell you above auto-renew status. Plus the cancel reason of 1 is a blanket for anything that's not user-initiated, not just plan change.
I am making a work around, but it requires knowing a few things, like:
When you switch from a more expensive, longer plan (yearly) to a shorter one (monthly), will all the remaining money be prorated, effectively making your new subscription last longer than its normal duration?
which seems likely, based on this:
Google Play cancels the old SKUs and credits the user with the unused value of their subscription time on a pro-rated basis. Google Play applies this credit to the new subscription, and does not begin billing the user for the new subscription until after the credit is used up.
When you cancel the newer subscription, will it happen the same way as cancelling a normal subscription? (i.e, the subscription is not auto renewed, but should stay in effect till the end of its duration), or some credit will be stored with Google to be used later?
However, the old subscription's start and end time is still the same on the developer API.
This seems unexpected and could be a bug.
When you switch from a more expensive, longer plan (yearly) to a shorter one (monthly), will all the remaining money be prorated, effectively making your new subscription last longer than its normal duration?
Yes, the remaining balance of the original subscription is applied to the new subscription. The new billing period will start once that balance is used up. This is best explained in the docs here.
When you cancel the newer subscription, will it happen the same way as cancelling a normal subscription? (i.e, the subscription is not auto renewed, but should stay in effect till the end of its duration), or some credit will be stored with Google to be used later?
I believe what will happen is the subscription will not be auto renewed (as you said), but the subscription will remain active until the balance from the prior subscription is used up.
Scenario:
I am on the verge of completing my google playstore in-app billing implementation. I am using a monthly or yearly subscription in order to charge my consumers.
Problem: I can't seem to find a way to remove a subscription from active state, since cancellation simply stops the billing from occurring. This doesn't allow QA to thoroughly test the purchase procedure without creating an account for each test, or waiting until the subscription period ends.
Question: Have I missed or am wrong about something? If so, what is it? If not, what should be done to allow QA to do proper testing?
According to what I have understood from your question,
you can not test subscription from the test account. Google play doesn't provide subscription testing using dummy product. you have to test on the real product.
Now question arises how can I test subscription
you can check subscription by purchasing real product and check product status or purchase cancellation using the purchase status api from your server.
you can also get more information from the given link below for the step by step cancellation purchase status:
1) link1
2) link2
you can simply query every day and check your subscription is valid or not and also get it's expiration date.
I also have one other option with out pay for any charges on your real product, you can set trial period in the Google console and before trial period ends up cancel subscription from the Google play store Menu -> MyApp -> Subsciption and cancel product and check above procedure given in the links.
EDIT:
Important: In all cases, you must continue to offer the content that
your subscribers have purchased through their subscriptions, for as
long any users are able to access it. That is, you must not remove any
subscriber’s content while any user still has an active subscription
to it, even if that subscription will terminate at the end of the
current billing cycle. Removing content that a subscriber is entitled
to access will result in penalties. Please see the policies document
for more information.
more information check below links:
1)
http://developer.android.com/google/play/billing/billing_subscriptions.html#cancellation
2) https://support.google.com/googleplay/answer/2476088?hl=en
3)
https://support.google.com/googleplay/android-developer/answer/140504?hl=en
You can not done this with out waiting until the subscription process cycle completes after cancellation of subs product, the only way remaining which is Free trial version it's only the way to provide us to test for the product cancellation in which product cancel immediately after you cancel subscription trial period, it will not continue until even trial periods ends.
more information check below link:
http://developer.android.com/google/play/billing/billing_subscriptions.html#administering
And I think it is better way because in the trial period you should go
with the actual credit card payment process but you doesn't need to
pay anything for it. Google play record the transaction as $0.00 for
the subscription process. And if you cancel the subscription the you
should not pay anything for testing, but yes I am not sure free trial version
is worked before you publish the app but it is only get by efforts only.
Conclusion:
In the current api it is not possible to test subcription product like
normal products and if user has been cancel the subscription product
then you have to wait to purchase the same product until the
subscription cycle has been expired, there is no another way if the
subscription cycle is going on and you can test for the same product
again before subscription cycle ends. And if you still want to test
for the same product then you have to choose another account for
testing it or another way is Free trials, you will not be any charged
until your Free trials period expired or cancel subscription in that
period and for the testing account before publish the app you will be refunded
automatically after 14 days of purchased product according to my
knowledge.
Hope it will solve your problem.
I have a horribly clunky workaround for this problem. Here is what I do every time I want to do a test of in-app subscriptions:
Create a new in-app subscription product in the google play developer console.
Point the android app at the new subscription product you just created.
In your code to check for active subscriptions, add a line to specifically ignore the order number of the previous subscription that you tested.
Export a release build of the app and transfer it directly to your testing device.
After testing, return to step #1 to test the next time.
Don't forget to fix your change from step #2 before deploying the app!
You might want to create many subscriptions in step #1 so you don't have to continually wait hours for them to propagate. Please comment if you know of a better way!
UPDATE: Google now has test subscriptions and is making it easier to use them! https://android-developers.googleblog.com/2018/01/faster-renewals-for-test-subscriptions.html
It seems that nowadays there is better solution:
Open your app page in Google Play Store application
Click "Manage subscriptions"
Click "Cancel subscription"
Go to "Settings", "Apps" in your phone.
Find Google Play Store and clear application data.
You should now be able to re-buy subscription.
Create a mock class that mocks out the Google Play methods that you are using.
Before I explain my question, let me give an example situation.
A user of a magazine app subscribes to the monthly subscription on the month of August and September. If the user reformats the phone, the app should be able to restore both August and September month's magazines.
The problem with this is that, the In-App Billing API returns only the latest subscription and whether the subscription is active.
Also, I want the users to be able view the previous months' magazines even if they have canceled their subscription.
Is there a way to keep track of all payments made by the user?
This likely would involve your own independent servers and "developer payload" information. As stated in this Subscriptions link:
Include business logic in your app to notify your backend servers of subscription purchases, tokens, and any billing errors that may occur. Your backend servers can use the server-side API to query and update your records and follow up with customers directly, if needed.
In other words, you should be keeping track of this--unfortunately.
Further, you can check this api reference as to whether a user's subscription purchase is valid.
I can't test this myself, because there is no way to completely terminate subscription, apparently.
So, I want to test the following use case: user buys subscription, cancel's it (or it expires), than user buys same subscription.
What will I get with RESTORE_TRANSACTIONS response? Will I get two items with same item id, different purchase tokens and different state? Or purchaseToken will remain the same? I'm afraid that there will be only one subscription with different order ID and purchase token, and the information on previous subscriptions will be lost, but I can't confirm it right now. Also, will orderId be changed with every recurring purchase inside a subscription?
Why I need this - subscription will supply user with new content daily, so when user cancel subscription (subscription A) and later buys a new one (subscription B) I need to show to user content released during time-frame of subscription A,and content in a time-frame of subscription B, but not the content released in period used didn't had active subscription.
Note: You should use the RESTORE_TRANSACTIONS request type only when your application is installed for the first time on a device or when your application has been removed from a device and reinstalled.
Using RESTORE_TRANSACTIONS on a regular basis is not recommended because of performance impacts.
Taken right from Android Developers http://developer.android.com/guide/google/play/billing/billing_overview.html
Although I do understand your concern for the Subscription Billing. Google is pretty good about their API and how you should interact with purchases.
When you send a RESTORE_TRANSACTIONS request you will get two broadcast back. A RESPONSE_CODE and a PURCHASE_STATE_CHANGED. Here's the table from Google stating the different values you could receive.
Coming back to your question about buying two subscriptions: you should check to see if the user has bought a subscription with the GET_PURCHASE_INFORMATION request, if the Subscription is in the list check the Purchase State of the Subscription to see if you should continue with the purchase.
As for what you would get if you "Could" buy two of the same subscriptions, its (I want to say impossible) unlikely... But you will get two order transactions.
As long as you're always aware of the user transactions on your part, Google's API will do the rest. Good luck!