6

I have implemented In App Billing for my Android app.

After a feature is purchased in my app, I have been collecting the Purchase bundle of that purchase order to my local server.

I don’t know what’s wrong or happened, but I observed a few purchase orders on my local server, which are not reflected on the merchant page.

When I check the purchase orders at my server, I found something strange like, the Order ID for that purchase is found as

Order ID  <19 Digit number>.<16 Digit Number>
  say <1234567891234567891>.<1234567891234567>

According to Google,

The order number itself is a string consisting of numbers only, with a format assigned and managed by Google.

For transactions dated 5 December 2012 or later, Google payments assigns a Merchant Order Number (rather than a Google Order Number) and reports the Merchant Order Number as the value of orderId. Here's an example:

"orderId" : "GPA.1234-5678-9012-34567"

For transactions dated previous to 5 December 2012, Google checkout assigned a Google Order Number and reported that number as the value of orderId. Here's an example of an orderId holding a Google Order Number:

"orderId" : "556515565155651"

The orders which are shown at the merchant page are in the following format:

"orderId" : "GPA.1234-5678-9012-34567"

Questions:

  1. Is the OrderId other than the format is considered as fraud?

  2. How to validate an actual purchase in case of fraud orders (i.e Order ID <19 Digit number>.<16 Digit Number>)?

dakab
  • 5,379
  • 9
  • 43
  • 67
Pushpa
  • 892
  • 1
  • 12
  • 30

3 Answers3

1
  1. Yes, non-valid orderIds have a deviant format. If it’s not fraud, it’s an improper order with no effective revenue.
  2. You validate¹ all purchases the same way; the result tells you if it’s admissible or not.

Please note: This answer is merely based on approx. four years of (subscription) data, because specific documentation is not known. Still, some patterns emerge:

  • A valid token is always 144 characters long, with a dot-separated, 119-character, Base64ish portion after the initial [a-z]{24} part, which defraud attempts solely consist of (e.g. eiorsfdmklehiojapofmknoe).
  • Proper orderIds always look like GPA\.[1-9][0-9]{3}(-[0-9]{4}){3}[0-9] (e.g. GPA.3479-1780-0192-98654).
  • Non-valid orderIds exhibit a format like [1-9][0-9]{18}\.[0-9]{16} (e.g. 2394627089137670234.7256937842057394).

By these and such rules, you can strictly check for the success case (which should be >90%), and otherwise do any combination of actions:

  • revoke granted features
  • inform your user/customer
  • alert your administrators/staff to check those cases individually
  • derive further rules from those instances

¹ To validate purchases, there’s get for products and get for subscriptions in the “Subscriptions and In-App Purchases API” part of the Google Play Developer API.

dakab
  • 5,379
  • 9
  • 43
  • 67
0

You should use purchase token to validate orders instead of order id using google purchase API

Purchases.subscriptions: get

It seems order id returned by google servers might not always be in the new format (GPA.1234-5678-9012-34567) as per this link. As format may change anytime in future its better to avoid using it for validation.

random
  • 10,238
  • 8
  • 57
  • 101
0

If you want to verify the validity of a purchase you must verify the signature.

Any implementation of in-app billing that does not verify the signature is poor and capable of accepting fraudulent purchases.

As Google recommends it is better to verify the signature on an external server, here is an example. Android - protecting in app purchases with server side verification

from56
  • 3,976
  • 2
  • 13
  • 23