识别退款的Play商店下载内容

Question

Play Store is now automatically approving refunds if they happen with 2 hours after the purchase. I have an Android App where people can create and control a VPS gaming host from the app. That is, when you start the app you go through a sign-up flow and afterwards you have a VPS that runs your game. After the sign-up you only need the app if you want to make any changes to the VPS.

I'm seeing people abusing this by purchasing the app (comes with 30 days free VPS), going through the sign-up flow to create their VPS, and afterwards they request a refund (which automatically gets approved if it's within 2 hours).

From Google Wallet I can see which OrderIDs are getting canceled, but how can I link that back to the users deviceID or something else that I can fetch in the app?

I'm forcing users to declare their Google user account before they can go through the sign up flow:

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

But this only gives me their email address, which I can't link back to the OrderID that is the only identifier in Google Wallet.

How do I link their account/email/deviceID to the OrderID (or other information available in Google Wallet)?

Please note: This is NOT for in-app purchases where the OrderID is readily available. This is for the purchase of the app .

Thanks!

Edit: Google Play Services authorization and user account management doesn't get you all the way to OrderID: http://developer.android.com/google/auth/http-auth.html Here's the documentation on in-app billing which (not surprisingly) do not offer any way of getting information about the app purchase order ID: http://developer.android.com/google/play/billing/billing_reference.html Licensing doesn't provide OrderIDs either: http://developer.android.com/google/play/licensing/overview.html

Person with similar issue but also unanswered: http://pcandsys.com/20378/verify-purchase-in-google-play-by-orderid /b3

Answer 1

Not exactly the answer to your question, but in your situation I would limit lease time to few hours, while installed app's background service should wake up once in a few hours in order to extend the lease time. Such a low frequency does not introduce any visible power consumption or data traffic impact. Of course in order to avoid possible collisions, lease time should be few times greater than update time (eg lease for 24 hours / updates once in 8 hours)

Another option may be to make your app free with trial period + in-app purchase in order to make it permanent

Answer 2

The only affordable solution that I see is to request a "confirmation of interest" from within the app , after the two hours have expired.

The flow would be:

00:00 User purchases app 00:05 User supplies his email address and signs up 00:10 VPS is activated. User is notified of COI requirement and acknowledges. 00:30 User requests refund

02:05 Remote server sends a friendly reminder email, "Hey, you need to confirm your interest to get your 30 days."

03:00 Lacking a COI, the VPS is paused/stopped pending deletion.

Users with their app still installed will have little trouble hitting confirm (the button is not enabled before the grace time has expired). Maybe you can even set a timed alarm?

Users with the app, that have it turned off, and who don't check the email (let's call them "Group G"), well. They will have to re-create the VPS. But they were warned, weren't they? They had no access to the email, but how about the app itself?

Users that try to download again the app will need to login to the same account as before. You can identify them easily enough.

You can also further reduce trouble for users, depending on the promptness of Play Store reporting (which I ignore). Let's say that you are informed of a refund with a delay which is guaranteed to not exceed X minutes. This means that if at any given moment there have been no refund notifications for at least 120+X minutes , all VPS created earlier than 120+X minutes ago and whose COI is still pending are as good as confirmed, and their pending status can be safely cleared with no need of user action. So all Group G users that happen to not have anyone requesting a refund at the same time they evaluate the app will still have no ill effects.

That said, it seems quite weird to me that Google does not allow an app to query "How was I born?" (with app and device ID) and receive its own order ID (or download ID, or uniquely generated ID) back, at least inside a reasonable time frame.