Some people trying to do in-app purchase within my Android game report that they can never complete the purchase -- that they always get an error message. (I.e., The market app reports an error to my application, and I show the user this error.)
Unfortunately, I don't have any real log data for this one, because it only happens for certain customers of my game, not for me.
What's strange is that after updating to a new version of the app, for some users the problem goes away, and for some users the problem starts. So user A might have the problem in version 1 of the app, but it clears up when they update to version 2. User B might not have the problem in version 1, but it appears when they update to version 2.
I say "intermittent" above, but by that I mean that it only seems to affect a small number of users. But for any given user, once they get in this state, they seem to get the message all the time. HOWEVER, I have had some cases where the problem does clear up suddenly, without an app update. I'm not sure if, for instance, power cycling, or, say, making an in-app-purchase in another app is away to "break out" of this state.
I realize that without a specific error message or API call to name/blame, this question is difficult to answer. I'm just trying to understand if this pattern -- of some users mysteriously getting stuck in a state where they are unable to make any in-app-purchase within a given app -- sounds familiar to anyone for Google Play in-app-purchase.
Also, I build my apps on top of Marmalade, so it's possible that the problem is in the Marmalade layer, not in my app or in the Google Play market itself.
The same problem here: a lot of users can buy items in my app but some users send me emails complaining why they can't buy considering that they can successful purchase items in other apps. I think it occurs because of a temporary problem on the Google Play server or is something to do with the service on Android. I am still looking for an answer to this weird problem...
Related
I'm using Google's in-app billing V3 to get orders processed in my Android app. I've been testing the system by uploading my APK to beta and listing my email as a test account so that I could go back and forth without being charged anything. These orders all remained (in Google Wallet) as "pending" (i.e., yellow circle). Then, about 1 month after I charged myself, the orders began being automatically canceled by Google. I figured this was because they were all tests.
Recently, I upgraded the APK to published status and got my first real order. Strangely enough, it's still "pending" (no green circle here). This got me to thinking that maybe all the other previous pending orders were actually mistakes. Can anyone confirm this? How do I find out what I did wrong? Or, am I just being a little too rushed and real orders take a long time to process?
The way my system is set up is that as the user pays, I send them the product via email. Does this, in some way, make the transaction not go through? I guess I don't really understand how it all works in the background. Any clarification here would be greatly appreciated.
This is for anyone who may run into this problem in the future:
After speaking with a Google representative, the short story is that you just have to wait.
Initially, the same representative informed me that, even with test/beta orders, the transactions would process (just not charged). Because of this, I was under the impression that my code was buggy.
Turns out, beta orders are never processed and remain as "pending" for their entire lifetime (which is a couple of weeks). Real orders, on the other hand, could take 6+ hours to process.
In regards to how the product is delivered, that did not play into the processing equation at all.
I have a customer that has requested a refund (as his 15 minute window in play store has expired). If I give him a refund manually, the play store (as far as I know) will still allow the user to reinstall if uninstalled, and the app will still be on his phone and usable.
I need to know a way around this, something I could code into the app perhaps. I considered having the app grab the device id and upload it to a remote server, and if its in the DB then the app pops up a window and wont run. The issue with this is it becomes specific to that device, if the user gets a new phone, or installs on a different device, it will work.
What could I do to make it so that upon giving someone a manual refund, they cant reinstall. I dont want people being able to get a refund and then just use the app for free.
Ive seen a few other similar questions here about this kind of thing, but they all were closed due to not being programming related. I want to make sure its known that I am asking a programmatic question, as I hope to implement some sort of check into the app.
My app is having success in Google Play with several million downloads. However, almost 50% of users have uninstalled it already.
I don't think that's a critical number but I'd like to find out why users uninstalls it, so I'd like to ask it to users using a simple form, only to the ones who want to answer of course.
Now problem is when to show that optional form. I've seen I can't use ACTION_PACKAGE_REMOVED because app that's being uninstalled won't receive that broadcast.
Of course I don't want to ever forbid the user to uninstall my app, but I do want to know when to start my optional form. Can you think of any idea how to do this?
Also, I've seen that Google Play asks the user why he's uninstalling any app and gives a few options (missing space, don't need it, ...). Is there any way to get those responses from Google, regarding my app?
If you can give me any other ideas how to investigate main reasons why users uninstall my app, to improve it, I'd be really thankful.
Once the user uninstalls the app, there's nothing you can do. 50% retention rate isn't actually that bad..
I would propose you look at how the users are using the app, whether it's crashing and how often it's being used: these can then lead as indicators to make an educated guess why they might be uninstalling your app.
Crashes:
These aren't always reported - it's only if the user elects to report it you'll see it in Google Play. Try Crashlytics for a more detailed analysis of how/when/why your app crashes.
Analytics:
I use Flurry to log events and work out what my users are doing. You could also look in to some A/B testing.
I'm experiencing a weird problem after we've submitted our first app on the Android Market. The app has a in-app purchasing feature which have been fully tested before the release (or at least I thought so).
I'm aware that similar questions might already exists, but I haven't found them and it's quite difficult to describe my problem with only a few words.
The problem appears when a user:
a) downloads our app from Android Market
b) opens the app after download through the OPEN link in Android Market
c) starts a purchase which takes the user back to Android Market.
d) either cancels or completes the purchase
Then:
Instead of returning to our app, the user returns to Android Market (which displays an description of our app with a button to open the app etc). In the LogCat an Response Code is sent from Android Market to the Purchase Observer, but our app (now being in the background) doesn't receive the code and therefor stalls, forever waiting for a response from Android Market. So it's actually two problems, because it's not intentional that the user should return to the Android Market screen after purchasing - our app should be before Market in the history.
Everything works correctly if the user opens our app outside Android Market (e.g. the Home screen). The observer receives either the cancel or complete Response Code.
We've used Google's own In-App Billing example as our foundation.
I hope this is somewhat understandable.
Thanks in advance
All right, I finally found the answer myself.
I'll try to explain the solution without using any code :)
The PurchaseObserver instance is only available when my activity is active - but it's not active, in the example described above. I made the mistake to think that the PurchaseObserver is where the order should be saved in the database - only to find out that you cannot be certain that the PurchaseObserver exists when a purchase is made. Instead, I now only use the Observer to change the UI and then handle the order information and the database through the ResponseHandler, which always gets called when an purchase has been made in Android Market.
I still think it's odd the user gets thrown back to Android Market instead of our app when an purchase is made (only when the user starts the app through Android Market), but I cannot seem to find an solution or explanation for this.
This is btw impossible to test or reproduce the problem, without having the app on Android Market - so I hope this explanation can help you guys not make the same mistake I've made ;)
I've implemented in-app billing and I'm running into an issue with it. Here is what I see.
Place an order for an item
Wait for a little while for the order to go through
If the purchase is taking a while, the user hits the back button to cancel the purchase
My app gets notified that the purchase was canceled and it confirms this
The user and myself both get an email stating that the purchase was canceled
When the user attempts to purchase the item again, the Market throws an error saying "You already have a pending order for this item."
The response code is "Service Unavailable"
Restore transactions yields no transactions
You can't ever purchase this item with this account
I have found some information about this on the web.
http://www.google.com/support/forum/p/Android+Market/thread?tid=375490c831e02ab5&hl=en
http://code.google.com/p/marketbilling/issues/detail?id=39
I contacted Google and got an autobot response that they are looking into this.
However, I'm wondering if there is anything I could be doing to cause this.
Oh, and I've also made sure my PendingIntent is good. I have had successful orders.
Update:
Here is my stock e-mail to customers that see this. It seems the Android Market has been getting better, as I get fewer and fewer of these now anyhow.
Hello,
This "pending order" error is unfortunately a bug in the Android Market that I cannot control.
To help them raise the priority of this issue, please contact Google at the following web form.
http://www.google.com/support/androidmarket/bin/request.py?contact_type=market_phone_tablet
You can tell them to reference bug 5126349, which is their internal tracking number for this.
While there are issues with in-app billing like the links presented here (i was active commenter on issue 39), there are some worthwhile things to check on as well that can cause a 500 response from google.
Namely, "restore transactions" and abusing that call. Abuse of that call is done on a per user basis and i've seen a google account get blocked with a 500 for a few days, which can certainly happen during development to you depending on how you implement.
Best advice here is to expand your testers to more users (or devices with different primary google accounts), running different versions of the android market. If you can get one positive response from someone, then more than likely you're good to go and the rest is at google's door.