Android In-App billing security issues?
Asked Answered
G

2

0

During our efforts to design InApp Billing for our Android App, we came up with the following scenario;

  1. Customer has rooted/manipulatable device (so Market app + my app can't be trusted)
  2. Customer purchases a product
  3. Purchase state 0 (purchased) is send to our backoffice (all is checked and ok), we give credits.
  4. Customer refunds that purchase
  5. Customer has manipulated our app or the market app to locally confirm the refund and thereby prevent the refund notification to reach our backoffice server.

Is this scenario possible? How can we fix this?

enter image description here

Gruel answered 25/6, 2012 at 14:5 Comment(0)
S
0

First: if the user asks for a refund you receive also an email.

Second: the purchases on in-app billing are not refundable directly by the user. If a user wants a refund, he must contact you and then you can proceed manually to refund with your google wallet account.

So i think that your scenario neve happen.

Secondly if possible i suggest you to use managed purchases, in that case if the user asks for a refund, google market will remember it, and you can use a RESTORE_TRANSACTION to check if some refunds occurred (but again: you must grant a refund).

Submergible answered 25/6, 2012 at 14:12 Comment(2)
Thanks for your replay. It is not possible to sell managed items, because the users could buy the item multiple times. But you mentioned that an email will be send if a user asked for a refund, but is it possible to receive notifications server sided? (like using some API)Gruel
I don't know if it is possible, but i think that another way to avoid the problem you mentioned is that when the user ask for a refund, it send an update to your server before doing the in=app billing transaction. In that way your server knew the refund operation before the in-app billing transaction.Submergible
C
1

It's been 7 years since this questions was asked but still I will provide an answer as it might be useful to some.

The part that is missing in your diagram is your BackOfficeServer to perform server side validation before granting the credits (goods) to the user. As nothing on the client side can be trusted (neither your app nor the app store) your only solution is to integrate your BackOfficeServer with the Purchase Verification API that Google provide. Only when you receive a response from them stating that the purchase is valid should you grant the goods.

The same would apply for refunds. If the user issues a refund you would need to revoke the goods. For this you again can only trust your BackOfficeServer. Google provide Real time Developer Notifications and Void API that can fulfill that requirement.

Commandment answered 5/3, 2020 at 14:29 Comment(1)
Just wanted to add that revoking goods/services for refund is not a good option as I've observed that sometimes it can be false signal for some reason. I send email to myself for any refunds and then manually verify it to make sure it's not a false trigger.India
S
0

First: if the user asks for a refund you receive also an email.

Second: the purchases on in-app billing are not refundable directly by the user. If a user wants a refund, he must contact you and then you can proceed manually to refund with your google wallet account.

So i think that your scenario neve happen.

Secondly if possible i suggest you to use managed purchases, in that case if the user asks for a refund, google market will remember it, and you can use a RESTORE_TRANSACTION to check if some refunds occurred (but again: you must grant a refund).

Submergible answered 25/6, 2012 at 14:12 Comment(2)
Thanks for your replay. It is not possible to sell managed items, because the users could buy the item multiple times. But you mentioned that an email will be send if a user asked for a refund, but is it possible to receive notifications server sided? (like using some API)Gruel
I don't know if it is possible, but i think that another way to avoid the problem you mentioned is that when the user ask for a refund, it send an update to your server before doing the in=app billing transaction. In that way your server knew the refund operation before the in-app billing transaction.Submergible

© 2022 - 2025 — McMap. All rights reserved.