Okay, something really dumb happened to my friend.
He submitted an Android application a few weeks ago that offers In-App Purchases to the user.
Now, he needed to update the .apk to fix a bug, but he actually lost the keystore that he used to sign the application the other day (what a dumbass...). He tells me it's definitely lost. He exhausted all options to find or restore it, but without success. So, as he understands, the only way to submit the update is to actually create a new application in the Google Play Developer Console. He is so dumb, I always tell him to do backups of important files, he just won't listen (wow, really, such a blockhead...)!!!! sigh...
Luckily, he only had a handful of users who actually purchased something in his app during that time. However, I would like to know (for my friend) if there is any way to transfer the In App Purchases from the same user from the old app to the new one, so that the users who bought something in the app and now want to update it, won't get punished for his stupidity and have to purchase the same items again....
AFAIK, there is no way to do that. The only option is to refund them and ask them to buy again in the new app. I believe refunding can be done by logging in to Merchant account.
Google Play does not provide any form of content delivery. You are
responsible for delivering the digital content that you sell in your
applications. In-app products are always explicitly associated with
one and only one app. That is, one application cannot purchase an
in-app product published for another app, even if they are from the
same developer.
And BTW, Does the app have any backend? Where in he saved data of all purchases made?
Related
I have an Android app that has several features available as in-app purchases. We have published the app on both Google Play and the Amazon App Store. We need to stop offering one of the features as of a certain date. However, customers who have already purchased the feature should be able to use it past that date, even if they install the app on a new device. They should also still be able to purchase other features.
I was thinking that we could simply update our app so that the UI offered no option for purchasing the feature in question. However, that would not prevent a user with an older version of the app from purchasing the feature. So it seems like in addition to removing the feature purchase logic from the app (but not the feature itself), we need to do something to turn off the purchase at the store end. But whatever that something is, it must still allow the app to check whether the user had previously purchased the feature.
I've been unable to figure out from the Google Play or Amazon App Store documentation how to set this up. My understanding, from what I've read, is that removing the item (from either store) will cause checks for previous purchases to fail. Is it possible to do what I've described? We need solutions for both stores.
P.S. I did find one related question on SO: Are Google Play in-app purchases still valid if the app or the product is removed? However, it has no answer and also is a little too narrowly framed. (I'm not assuming that the product has to be removed and I also need to know about the Amazon store.)
I was thinking that we could simply update our app so that the UI
offered no option for purchasing the feature in question. However,
that would not prevent a user with an older version of the app from
purchasing the feature. So it seems like in addition to removing the
feature purchase logic from the app (but not the feature itself), we
need to do something to turn off the purchase at the store end.
For Amazon Appstore, you would need to contact their support team to get the in-app item in question suppressed (it's not a self-service as of today). Once suppressed, that in-app item would no longer be purchasable. It would not affect existing users who purchased that item in the past.
When it comes to in-app purchase I always opt for implementing everything in my own server. when a user buys something, I instantly consume it and notify my server. Then instead of querying Google or Amazon, I query my own server which gives me a lot of flexibility. If I face something like your problem I just add few lines of code!
Since you already published your app this may not work for you unless you willing to force users to update the app to the newer version. (Hoping you can do that!)
You mentioned that you don't know what happens if you deactivate the product and there is no documentation, well you can try it on a test project and see what happens! It shouldn't be that hard. If that doesn't work as you expect there is nothing you can do, your logic is in your app and it's already published so...
So I got my first Android phone about 8 years ago and I created a Google account to buy apps and later use to comment on Youtube. now even tho I never personally attacked anyone or cyberbullied anyone. I did comment on videos saying certain things sucked or were stupid or gave my opinion on things which would start fights with people. I wasn't going thru a good time back then I had a lot of stress and I was depressed with graduating Highschool and not knowing what to do with my life along with other things. Now as of today I still own the account and as I bought a good number of apps with it I would always just use that account to buy things, but I no longer want to be tied to all these stupid things I've said on Youtube or Google+. Is there a way to delete my Youtube account? I never had a channel where I posted videos but can I delete the Youtube account part of my Google account so my Comments will be gone? I don't think you can but is there a way to transfer my purchased apps to another again or link an account to them, Google only introduced the family share thing after I bought the majority of my apps. Thanks for any help
it's unfortunately not possible to transfer paid apps to a different Google account.
You can do this..
Go into your phone Menu -> Accounts -> Google -> choose the account -> and choose what you want to sync. You can limit it to Account Data or even sync nothing.
Then, you can still get access to all your paid content and not have deal with all the other stuff that was on the account. Purchases you make are still available. It just won't automatically update anymore if you happen to still use that account on another device
We already have an app on Google Play with in app purchases (as subscriptions), and there are lots of users who already purchased our subscriptions. However, we have developed a new version of this app from scratch and we want to list it on Google Play as a new app. After few months, we want to unpublish the old version of it. There is one issue with this: How do we make sure that users who already purchased subscriptions in the old app keep their subscriptions in the new one? It seems like there is no way around this other than asking them to purchase on the new one. But maybe there is a better idea than that?
P.S. We are publishing as totally new listing because of significant changes in the app and also the old one wasn't taken care of properly, therefore there were many bad ratings. This would be a fresh start.
Maybe , there is a way.
From Your Old App Obtain 2 things
GOOGLE API KEY FOR IN APP PURCHASE
product id (is unique everytime)
Inside the java code, check all the purchase history for this particular product from Billing object.
This library is excellent in simplyfing in-app purchases.
https://github.com/anjlab/android-inapp-billing-v3
I'm pretty sure there is no way to tell the play store that the user has bought a subscription for the new app. You could update the old app to send subscription data to a server which can mark the user as having bought a subscription, and then the server can validate the new app to deliver subscription content. But the play store will not know anything about it.
Background
My app has some in-app billing (like this one), and I wish to test it out before publishing it.
I've watched some google IO lectures and read some articles, and prepared everything.
According to what i've learnt (talked about here), all I need to do is just add my email to the test accounts, and it won't be charged.
The problem
It seems that in the developer console, the in app items cannot be activated.
I think it's because the app isn't published yet, but that's the whole point of testing - I want to test the app before publishing it...
As I've also found out, in order to test in-app billing, I have to do a lot of things to take care of for making it work, also having many restrictions and annoyances:
sign the app and upload it to the play store . if you don't use a signed app, you get this message ("This version of the application is not configured for Market Billing...") .
make credit cards be used to the devices, even if they won't cost anything.
let others do the testing instead of myself, as my account cannot be used for that. not only that, but instead of adding exactly which you wish to add, you have to create a google group and there put the people who will be able to use the app, and all will have to have a google+ account... You will also need to wait some time till the testers will be able to use in-app-billing of your app and till then they will get an error "User is not eligible for this purchase" .
because of #1, I need to have some kind of mechanism to reset the purchases, within the app itself, but i also shouldn't forget to remove/hide this features for the end users, so that they won't reset it by mistake
because of #1, if I wish to be able to debug the app, I need to change it on the manifest, and choose to debug the app within Eclipse, and also remember to uncheck this flag before actually releasing the app.
since the app is on the play store, you cannot modify in-app purchases items (their Id for example), as opposed to many thing you can modify before publishing the app. It's no longer a development as flexible as it can be using simple development. It's like your app should be sealed with what you choose even though you haven't published it yet.
The question
Why is it this way?
How come there isn't a simple way to allow to test the in-app-billing ?
How would you deal with the problems I've written about?
Is it possible to test the in-app purchases before the app is published?
How come I can't use my own google account ?
Also, suppose I do make a (fake) purchase, how do I reset it (all/specific purchases) in order to check it out again? Is it true I can't do it anywhere besides the app itself?
Am I missing anything?
you dont have to publish the app inorder to test it all you have to do is upload the apk to your developer console, just dont publish it. If your account is linked to your developer console you cannot use that account and have to create a test account to test the IAP's
You will have to public the app but publish in beta mode so that you can test the in app purchases. Beta mode will enable to test the functionality with limited user set.
Yes, you can test your app without publish (and without publish in beta mode too). There are instruction http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-test. Please remember that after 1 point it's maybe need to wait about hour or two.
It seems that in the developer console, the in app items cannot be activated.
it's ok, just check that you mark it as active. It look like not active before you publish the app, but you can test it.
I can use my own google account, right?
I strongly recommended have additional account only for test purchases.
Also, suppose I do make a (fake) purchase, how do I reset it (all/specific purchases) in order to check it out again?
You'll must to fill billing information for your test account. But when you make test purchase, there are no any real money transaction. Every in-app can be tested once again after the app consume it.
I'm also working on how to test In-App-Billing for Android in best way since days.
With real transactions to me it seems to be really too complicated and a lot too much effort. So i'm currently thinking of 'only' testing this stuff with static responses (http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-static).
In theory i guess once this works, it should also be fine in production as in the source code only the SKU id gets changed for live release..
I have a few questions connected to Android In-App Billing:
Is it possible to make a purchase from non-Market app? I understand that it would be a vulnerability, but I have no opportunity to find out if it's possible or not.
How can I get purchase state for a particular product? As far as I understand it can be done using RESTORE_TRANSACTIONS request, but it's not recommended to use very often. That's not a theoretical problem. My application allows users to buy content using in-app billing. Content can be downloaded from a server, and server must allow content downloading only if it was purchased. But it can't check if content was purchased or not without using signed response from Android Market.
How can I get price and description of an item from Android Market? Seems that I know the answer and it's "there's no way it can be done", but maybe I'm wrong. It would be very useful to have a possibility of retrieving item's price.
It's very interesting to me how you solved/are going to solve these problems in your apps. Answer to any of these questions will be appreciated.
In order:
1- Nope. The in-app billing process is part of Market. If the app comes from elsewhere, there's no way for Market to verify the origin/authenticity of the application.
2- It's your responsibility to store the purchase state for a particular product. From the doc:
You must set up a database or some other mechanism for storing users' purchase information.
RESTORE_TRANSACTIONS should be reserved for reinstalls or first-time installs on a device.
3- Unfortunately, at this time you're right. File a feature request!
In the meantime, one option is to set up a website with appengine, store listings of all your content & pricing there, and then manually sync prices listed on your appengine server with the updated prices in Market. Then have your Android app pull the data from the AppEngine server. This is much better than hardcoding price values into the app itself, since you don't need to have everyone update the app immediately to see accurate pricing whenever you change something. The only caveat of this method is that if the user is in a different country, in-app billing will display an approximated price in their native currency, and there's no way for you to determine exactly what price will be displayed to them.
Related, One of the Android Developer Advocates is giving a talk on LVL/IAP at IO, called "Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine." - It would definitely be worth your while to watch when they release the session videos on the website.