Identification of returned Play Store downloads

The Play Store now automatically approves refunds if they occur 2 hours after purchase. I have an Android app in which people can create and manage a VPS game host from within the app. That is, when you launch the application, you look at the registration stream, and then you have a VPS that launches your game. After registration, you need the application only if you want to make any changes to the VPS.

I see that people abuse it by buying an application (comes with a 30-day free VPS), going through the registration flow to create their VPS, and after that they request a refund (which automatically gets approval if it is within 2 hours).

From Google Wallet, I can see which OrderIDs are being canceled, but how can I associate this with the userID or with another, what can I get in the application?

I force users to declare their Google user account before they can go through the registration flow:

Intent intent = AccountPicker.newChooseAccountIntent(null, null, new String[]{"com.google"}, false, null, null, null, null); // ... email = data.getStringExtra(AccountManager.KEY_ACCOUNT_NAME); 

But that only gives me an email address that I cannot associate with the OrderID, which is the only identifier in Google Wallet.

How do I link my account / email address / deviceID with OrderID (or other information available in Google Wallet)?

Please note: this is NOT for in-app purchases where OrderID is easily accessible. This is for the purchase of the application.

Thanks!

Edit: Google Play Services authorization and user account management do not reach OrderID: http://developer.android.com/google/auth/http-auth.html Here is the documentation for billing in the application that (not surprisingly) does not provide any or a way to get information about the application purchase order identifier: http://developer.android.com/google/play/billing/billing_reference.html Licensing does not provide OrderID identifiers: http://developer.android.com/google/play/ licensing / overview.html

A person with a similar problem but also not responding: http://pcandsys.com/20378/verify-purchase-in-google-play-by-orderid / B 3

+7
android google-play in-app-billing android-billing android-pay
source share
2 answers

Not quite the answer to your question, but in your situation I would limit the rental time to a few hours, while the installed background service of the application should wake up once every few hours to extend the rental time. Such a low frequency does not lead to a noticeable energy consumption or the impact of data traffic. Of course, in order to avoid possible conflicts, the rental time should be several times longer than the update time (for example, rent for 24 hours / update once every 8 hours).

Another option may be to make your application free with a trial period + in-app purchases to make it permanent.

0
source share

The only solution I can see is requesting a “confirmation of interest” in the application after two hours.

The stream will be:

00:00 User shopping app 00:05 User delivers his email address and subscribes 00:10 VPS is activated. The user is notified of the COI requirement and confirms. 00:30 Return user requests

02:05 The remote server sends a welcome email: "Hey, you need to confirm your interest in order to receive your 30 days."

03:00 Lack of COI, VPS pauses / stops until deletion.

Users with the installed application will have few problems with confirmation (the button is not activated until the grace time has elapsed). Maybe you can even set an alarm?

Users with the app who disabled it and who don’t check email (call them “Group G”) are fine. They will have to recreate the VPS. But they were warned, right? They did not have access to email, but what about the application itself?

Users who download the application again will need to log in to the same account as before. You can easily identify them.

You can also reduce problems for users, depending on the responsiveness of the Play Store reports (which I ignore). Let's say that you are informed about the return with a delay that is guaranteed to not exceed X minutes. This means that if at any time there were no refund notifications for at least 120 + X minutes , all VPS created earlier 120 + X minutes ago and whose COI are still pending are as good as confirmed, and their pending status can be safely cleared without the need for user action. Thus, all users of the G group who did not have anyone who requested a refund, while at the same time evaluating the application, will still not have any negative consequences.

However, it seems strange to me that Google does not allow the application to request “How was I born?” (with the identifier of the application and device) and get your own order identifier (or upload the identifier or unique identifier) ​​back, at least in a reasonable amount of time.

0
source share

All Articles