I am using google in-app billing v-3 to implement auto renewal subscription process of google in my android application.
In my application user can go for different types of subscriptions, like Subs-1 for 30MB of space, Subs-2 for 90MB and so on. Now if, user chooses initially Subs-1 and then upgrades it to Subs-2, as a result now there are two simultaneous subscriptions on user's account.
I want to cancel first subscription, when second is purchased. Is there any method for the same in android code, or do I have to go for server-side implementation of the same here.
Google docs are really confusing, and I didn't find any solution there.
Yes you could use the cancel method, detailed here https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/cancel#request
All you would need is the subscription_id and token which you got when user purchased the subscription
Related
I am new to Android / IOS apps development with React Native. I am using react-native-iap to implement in app purchases.
I want to know whether an Android / IOS single app can have both Subscription and Full Purchase Methods ?
If yes, what will happens
When user first subscribed the app, and then try to purchase the full app ? will subscription get cancelled ?
When user purchased full app and try to do a subscription ?
Thank you.
Subscriptions and "one-time-purchases" are different.
When you buy 2 subscriptions, you can manage the replacement of one by another one. Although, the behaviour is different in iOS and android:
On the Apple App Store, you have the notion of "subscription group". If you try buying another product in the same subscription group, the previous subscription will be automatically replaced by Apple (at the next renewal date for a downgrade, immediately for a crossgrade/upgrade).
On the Google Play Store, you don't have this notion and you'll have to manage the replacement by yourself (more info on this here: Allow users to upgrade, downgrade, or change their subscription)
When you want to replace a subscription by a one-time-purchase, you can manage the "replacement" manually on the Google Play Store, but not on iOS:
On Google, you have an API to cancel a subscription: use it after your user buy the "full-app"
On Apple, such API doesn't exist and the only thing you can do for now, is explaining to your user the different steps to cancel his subscription. You can help him with this deeplink: https://apps.apple.com/account/subscriptions
Opening this URL launches iTunes or iTunes Store and displays the Manage Subscriptions page where the user can upgrade, downgrade, or cancel their subscription by disabling auto-renew
Concerning the full app => subscription, I don't know. You could refund the purchase, but it would mean you would have lost money during the corresponding period of time.
In the Android Developer Console, I saw this message
Resubscribe isn't currently available for your users because your app
does not use Billing Library 2.0 in all active APKs
But, I was puzzled. Currently, we are using Billing Library 1.2.2.
This is how we decide, whether to show subscription button to user or not.
During queryPurchases, We will perform List<Purchase> purchases = PurchasesResult.getPurchasesList(). If the subscription's SKU is not found in purchases, we will show the subscription button. If not, we will hide the subscription button.
If this is a new subscriber, there will be no SKU in his purchases. Hence, he will see the subscription button, and allowed to subscribe again.
If this is a previous subscribed, and already cancelled user, we assume there will be no SKU in his purchases too!!! Hence, he will see the subscription button, and allowed to subscribe to the same sku again.
As you can see, even with old Billing Library 1.2.2, we are still allow user to resubscribe to same SKU again, to his previous cancelled subscription.
If that is so, why there is a special feature called "Resubscribe" (https://developer.android.com/google/play/billing/subs#resubscribe) in Billing Library 2.0? How does it different from our current Billing Library 1.2.2 flow?
To be perfectly honest, there isn't any enormous difference between resubscribing to the same sku with old and new approach using the resubscribe feature. Why? (None of these are solidly tested by the way, this is a logical explanation.)
In both cases, the subscription elements will stay the same and they will both return in queryPurchases method as long as the subscription is active.
This relates to the queryPurchases method, I haven't tested this yet, but it is possible that, in the old way, multiple purchases with the same sku might return, which may create a confusion. After resubscribing while canceled subscription is still active, the queryPurchases method will return only 1 subscription, causing queryPurchaseHistoryAsync method to return nothing. In the old way, if queryPurchases method returns only 1 purchase after getting a subscription over a canceled subscription with same sku, queryPurchaseHistoryAsync might actually return the old subscription that was canceled for, even if it was still active in a canceled state.
On Google Play Developer API side, there is a method that links a purchase token to the older one. For this, the Purchase.getLinkedPurchaseToken() function might return different values after subscribing to same sku, between the old way and new way. I presume, resubscribing to an active canceled subscription with the old way will generate a new purchase token, and getLinkedPurchaseToken(). This does not affect the BillingClient itself since there is no getLinkedPurchaseToken() method but logically this should be the result.
Bottom line: The only difference I can say is that resubscribing with the new way might reduce confusions, while on the old way there might be unnecessary data that you want to avoid from. As long as you have a subscription that's returned from queryPurchases where it matches your sku, you can consider that the user has an active subscription.
https://developer.android.com/google/play/billing/subs#resubscribe
Users can resubscribe in a number of different scenarios:
Before the subscription has expired, users can repurchase the same subscription in your app. This generates a new subscription and
purchase token.
Before the subscription has expired, users can restore the subscription in the Google Play subscriptions center. This keeps the
same subscription and purchase token.
After the subscription has expired, users can also repurchase the same SKU up to 1 year after expiration through the Google Play
subscriptions center. This generates a new subscription and purchase
token.
More details are provided in the release notes of 2.0 here: https://developer.android.com/google/play/billing/release-notes
I think the API is for subscriptions made outside your app (for example, from Google Play Subscriptions Center (mentioned in bullet point 3), or at a physical store).
Based on your question, it seems that you already handle the other scenarios regarding a user not having a subscription or having cancelled their subscription - but these flows apply to within the app, not outside. To gracefully handle purchases made outside the app you must use 2.x or higher.
The ability to process subscriptions outside the app, such as Google Play subscription Center or a physical store is not available in 1.x. It is available from 2.x+
Presuming you don't confuse the flow of subscriptions , that will remain as it is. Additional features have been added to Google play billing . As we talk , Google play billing 3.0 is up and ready. Follow this link
https://developer.android.com/google/play/billing/release-notes#3-0-0-summary-changes
Resubscribe feature will make restoring subscriptions easier.
There are scenarios where managing subscription should be made easy .
Subscription Restore and Resubscribe
Lets assume a user for some reason cancels the subscription renewals and before the subscription is expired and wants to subscribe it again. Now if user wants to resume it again. This newly feature will allow to resume the subscription as if they were never cancelled. For this the condition is that the subscription must not have expired . If it has expired , then here it is . Users will have to resubscribe instead. To resume any paused subscription users will need to resubscribe , you will have to treat this as you have been treating it.
Account hold feature
A user subscribes and sometimes users are unable to pay their subscription, whether due to financial woes or an expired credit card. In these cases, developers can initiate an Account Hold instead of cancelling it . This will allow users to manage the subscriptions until they fix the payment at their end.
Developers with existing apps will need to integrate Account Hold and Subscription Restore by November 1st. Unless they opt out, they’ll also need to integrate Subscription Pause and Resubscribe. If they fail to do so by the deadline, future updates may be rejected, thus delaying the launch of new features, bug fixes and metadata.
I'm not specifically looking to have the option to refund a user for an in app purchase of a consumable, but just in the odd case that a user asks for a refund, either through google, or through the developer of an in app purchase of a consumable.
There does not seem any way of handling refunds through the In App Billing api V3. All documentation points to V2 of the api using broadcast receivers. This does not help me in least bit.
So how are refunds handled in the In App Billing v3 api? I'm assuming for a non consumable, the refund is processed, and then google handles the processing through their backend, and then when a getPurchaseState() is conducted, it would return a value of 2 (refunded). If so, this works great for a NON CONSUMABLE product.
When a getPurchaseState() call to a consumable purchase is made, it returns null. That's assuming if the purchase was previously successful, and that the item was consumed and provisioned. I figure I could store the purchase items locally within the app, but then there is still no way of receiving a refund notification for that product. I can check for purchase state, but again, it will return null, as long as it was consumed and provisioned already.
A slight workaround I can think of right now, is to not consume the purchase on provisioning. So that it remains "unconsumed" according to google, and remains in their database. Now, if a refund is requested, I am assuming a call to getPurchaseState() for that consumable will return refunded, thus the application logic can then subtract/deduct the provisioned consumable from user's inventory. If a user would want to repurchase that consumable again, then before the IAB api call is made for the purchase, get the purchaseState() and/or hasPurchase(), and if there is already a purchase there, consume that item without provisioning, this will let the user repurchase that consumable. Only issue with this workaround, is that if A user wants to re purchase the same consumable product, as soon as the select the option to repurchase, the item must be consumed regardless of whether they successfully repurchase the product or not. So if the user does not complete the purchase, the product is already consumed, and I end up back where I am now with inability to check for refund state on the consumable.
I can't think of any other way to do a refund for a consumable in app product, and that is what I ask here. Is the way I thought of sufficient, or is there a proper way to handle refunds using IAP v3 on consumables?
I was thinking I have 3 options:
Don't offer refunds for consumables, no/little exceptions, but the issue with this is if a user requests refund through google, and not through developer, leading to option 3 below)
Find a workaround (either properly through the api, or with my proposed workaround)
Offer refunds, but have no application logic to subtract/deduct the consumable. In this scenario, users could end up taking advantage of free purchases.
I know this is a super late response to this issue, but it took me quite some time to track down info on this issue, so hopefully it can help someone else out. There are a few ways of doing this... In the Google Play Developer console you can click on the left nav saying "Order Management" which will bring up a list of all recent orders though your app. If you need to refund one you can click on it, or multi select them and refund them in this view. Just a heads up... you will most likely need permissions from your account admin to see this view and refund users.
Your other option is though the API docs here. You will need to set up your API account though the Android console, which I will say is a massive pain and not clear. But once that's set up and your "Server Applications" is set up you will need to make sure it has proper permissions as well. Then you should be able to use a library such as this to do the heavy lifting for you, because from what I've read the JWT auth process though the google API is not super straightforward, and their docs are a mess. I hope this helps someone and comment if you have questions... I will do my best to answer.
This same API also can be used to find items that were purchased by users and then refunded, so you can remove these items from those users' apps. Also you can do server side purchase validation through this as well, which is highly recommended, because rooted phones can inject fake purchase requests making your app believe that it's hearing back from the google play store, but in reality it's not. You then send back to your server the purchase token and SKU of the item being purchased and then on your server you just run this. This will give you back a 400 error if it's invalid, and a 200 with a some JSON data if it's a successful purchase.
I have gone through most of the links here on stackoverflow and i have some doubts regarding InApp Subscriptions and Google Wallet.
What i know:
InApp Subscriptions basically allows a user to be able to subscribe to an app, say for example if it offers one year trial period, then once thats over, Google automatically handles the subscriptions then after.
Google Wallet, its a method that can be used to perform the purchase. What i don't understand is, can i use this method in order to allow users to use the app for one year, and then make them pay for the next years?
Billing continues indefinitely at the interval and price specified for the subscription. At each subscription renewal, Google Play charges the user account automatically, then notifies the user of the charges afterward by email. For monthly and annual subscriptions, billing cycles will always match subscription cycles, based on the purchase date. (Seasonal subscriptions are charged annually, on the first day of the season.)
This is what happens in my app:
1. A user logs in, and i get a date that probably keeps track of the billing cycle
2. If the sessions expired, the user is asked to pay using the inApp Billing serivce
3. Based on TrivailDriveApp Example, where we have the success log printed on subscription, we update the date of payment.
Some questions i have:
As per the quote from android, if the user is automatically subscribed to the service, and if a mail is sent to the user, does that mean that i would never be able to get a notification about the payment extension? How do i sync that with the server then?
Is my approach wrong in handling this kind of scenario? Or do i have to select a different method of handling app extensions?
P.S: There is no way of testing inapp subscriptions also. I wonder if i could do that without using real credit/debit card credentials.
EDIT:
I would also want to keep track of when the purchase or billing was done, if subscriptions are auto-renewed, then should i take up the purchase flow as an InApp Product instead of an InApp Subscription?
Please help.
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.