Android store.restore() does not work. need help.

Solar2D Monetization (in-app purchases, ads, etc.)
#61

I’ve finally figured it out! (sort of)
I decided to log the receipt numbers, and there I could see that the purchased and cancelled events had different numbers. I then matched the receipt numbers in my Google Merchant account.
The purchased receipt corresponded to the new purchase. The cancelled receipt was for a previous purchase, that was cancelled.
It seems like we’re experiencing the “Google wait factor” here, where we have to wait x number of hours/days for cancelled test-transactions to get flushed from the system.

The only thing I don’t understand is why we’re getting repeated callback “bundles” (cancelled:receipt=123->purchased:receipt=987) and then *another* (cancelled:receipt=123->purchased:receipt=987) both “bundles” with the same receipt numbers for their respective events (in the example above I’ve just given fake receipt numbers to illustrate what I mean).

This also happens when I use Google’s test products. I tested with “android.test.purchased”, and got 2 callbacks. One purchased callback for the above Google test-product, and then a cancelled callback for a cancelled *real* transaction from another session where I was using my own product id. However in this case I only got one “bundle” (purchased->cancelled)

Anyway, this will be my last post about the subject on this thread as I now see that Google’s system is behind the behavior. I don’t have any updates planned for this app for at least another month, and by then all transaction from my test account should’ve been flushed.
[import]uid: 70847 topic_id: 29859 reply_id: 136648[/import]

#62

Oh, interesting.

The reason Google Play may be re-sending you the same “Cancelled” notification is because they haven’t received a confirmation that it was received. You can send that confirmation in Corona by calling the [lua]store.finishTransaction()[/lua] function. So, are you calling that function when you receive that “Cancelled” notification?

I’ll double check the code on my end next week to make sure that confirmations are being sent for cancelled notifications. [import]uid: 32256 topic_id: 29859 reply_id: 136743[/import]

#63

I send an appstore.finishTransaction(tx) at the end of all notifications, but you made me realize one thing.
A few posts up you might remember that I was getting an ‘Invalid Client’ response from time-to-time even with the sample app. *Maybe* the finishTransaction call isn’t always received properly by Google and they re-send whatever is in the queue when a new transaction is made.
It actually makes perfect sense now when I think about it.
Maybe I should stop with the Google-bashing. It might just be down to connectivity issues :wink: [import]uid: 70847 topic_id: 29859 reply_id: 136745[/import]

#64

ingemar, dingo,

Sorry about the late response.

So far, I’m only hearing about this canceled purchase issue from you two. I’m wondering if your test accounts have been wrongly flagged by Google as fraudulent. Have you tried contacting Google about this? I say this, because I’m not sure what we can on our end to resolve this since Corona merely passes the notifications received from Google to your app.

There are other Android developers who have filed similar issues with Google, as can be seen in the link below. So, I’m thinking this is really a system issue on Google’s end.
http://code.google.com/p/marketbilling/issues/detail?id=14#c28

I suppose one way to prove that it’s an account issue would be to set up another test account and see if that account can successfully make purchases.

I also recommend that you start a new forum thread about this issue to see if there are other Corona developers who are running into the same issue. Especially since the title of this forum thread is now unrelated. Who knows, perhaps other Corona developers have resolved this issue before and may be able to help you with this.

I hope this helps. I’m not trying to blow you off here. I’m just not sure what else to recommend at the moment. We’re fighting a black box and we just don’t know why Google’s in-app purchase system isn’t cooperating with you two. [import]uid: 32256 topic_id: 29859 reply_id: 136485[/import]

#65

I had the same idea, so I created a new test user, but with no difference.

IAP on Android is flaky to say the least. I took the Corona IAP demo app, compiled with 994, and even that it isn’t behaving 100%. I would say that 1 of 20 purchase attempts return an “invalid client” response (although never a multiple callback).

I’m still doing some testing to see if I can get to the bottom of this. When I have more info I’ll open up a new thread instead of continuing to hijack this one… [import]uid: 70847 topic_id: 29859 reply_id: 136582[/import]

#66

I suspect that the INVALID_CLIENT error that you are getting 1 out of 20 times with the sample app is due to a connectivity issue. That error will happen if you do not have Internet access or if Google Play is not set up with a valid account that can make purchases or if anything is wrong with Google Play. For your customers, odds are Google Play is set up correctly (because how else are they going to download your app?) so it is most likely an Internet access issue. Well, it could also mean that your customer might have misconfigured their payment settings too.

I saw a “Target server failed to respond” error in the log that you posted. That error is coming from the Google Play app. In that case, you shouldn’t be able to make a purchase… and yet you were able to and it was quickly canceled. This is very strange indeed. [import]uid: 32256 topic_id: 29859 reply_id: 136618[/import]

#67

I’ve finally figured it out! (sort of)
I decided to log the receipt numbers, and there I could see that the purchased and cancelled events had different numbers. I then matched the receipt numbers in my Google Merchant account.
The purchased receipt corresponded to the new purchase. The cancelled receipt was for a previous purchase, that was cancelled.
It seems like we’re experiencing the “Google wait factor” here, where we have to wait x number of hours/days for cancelled test-transactions to get flushed from the system.

The only thing I don’t understand is why we’re getting repeated callback “bundles” (cancelled:receipt=123->purchased:receipt=987) and then *another* (cancelled:receipt=123->purchased:receipt=987) both “bundles” with the same receipt numbers for their respective events (in the example above I’ve just given fake receipt numbers to illustrate what I mean).

This also happens when I use Google’s test products. I tested with “android.test.purchased”, and got 2 callbacks. One purchased callback for the above Google test-product, and then a cancelled callback for a cancelled *real* transaction from another session where I was using my own product id. However in this case I only got one “bundle” (purchased->cancelled)

Anyway, this will be my last post about the subject on this thread as I now see that Google’s system is behind the behavior. I don’t have any updates planned for this app for at least another month, and by then all transaction from my test account should’ve been flushed.
[import]uid: 70847 topic_id: 29859 reply_id: 136648[/import]

#68

Oh, interesting.

The reason Google Play may be re-sending you the same “Cancelled” notification is because they haven’t received a confirmation that it was received. You can send that confirmation in Corona by calling the [lua]store.finishTransaction()[/lua] function. So, are you calling that function when you receive that “Cancelled” notification?

I’ll double check the code on my end next week to make sure that confirmations are being sent for cancelled notifications. [import]uid: 32256 topic_id: 29859 reply_id: 136743[/import]

#69

I send an appstore.finishTransaction(tx) at the end of all notifications, but you made me realize one thing.
A few posts up you might remember that I was getting an ‘Invalid Client’ response from time-to-time even with the sample app. *Maybe* the finishTransaction call isn’t always received properly by Google and they re-send whatever is in the queue when a new transaction is made.
It actually makes perfect sense now when I think about it.
Maybe I should stop with the Google-bashing. It might just be down to connectivity issues :wink: [import]uid: 70847 topic_id: 29859 reply_id: 136745[/import]