Anomalous spikes of non-reported consumable purchases?

Question

Created Dec ’15

Replies 1

Boosts 0

Participants 2

I'm using Fabric stats tracking in my app, specifically in the method to deliver a new in-app purchase, so I know when one has been made. My app has been live for long enough for me to know the normal pattern, which is about 2-3 purchases a day (all consumable items). But every once in a while, my stats tracking shows a MASSIVE spike in purchases (up to 100-200 in a day, all from a single user), without any corresponding profit report the next morning on iTunes Connect. Then the next day, it goes back to normal.

The first couple of times this happened, it was during the approval process for an update, so I just assumed it was an Apple employee testing the system. But now it's started happening on just normal days, without any apparent cause.

Has anyone else experienced this? Is there a known reason why this might be happening? It's definitely real: my other analytics for that day show a user with anomalously high stats, which fit with the purchase reports, so the purchases are definitely being delivered. Could it be Apple employees, or people with jailbroken phones? Is there anything I can do to prevent this, or at least a check I can do in my code to prevent them from being reported?

Boost

Answer 1

PBK OP

Dec ’15

I am not familiar with the way Fabric identifies a "purchase" but there are various ways of injecting a fake purchase into the updatedTransactions method. Some of these come with no receipt, some with a fake receipt and some with a copied receipt. Do you verify the receipt in your app? Is it possible that someone has created a way to hack your app and is slowly telling their friends who then stock up on your consumable? The good news is that these aren't 'lost sales' because such theives are unlikely to be actual customers.

There are three ways to verify the receipt. The first and least good is to send the receipt from the device to the Apple servers and receive back to the device the result - very easy but subject to various, but difficult, hacks. The next is to send the receipt to your own servers, from there send it to the Apple servers and back to your servers which check it and, if valid, credit the device - requires that you maintain a server. The best is to decode the receipt on the device itself - requires that you figure out OpenSSL stuff.

0