Such a scheme is open to many avenues of abuse. I'll try to outline some of those, and discuss the ways to combat them.
Owning without buyingThe other day, a customer told me: "Here's how it's normally done: you have a license app, once they install that, the premium content is unlocked". This sounds fine, until someone grabs an APK of the license app from a rooted Android device and publishes it for the whole world to see. I have some good evidence that my LicenseApp is available outside Google Play, although I never disclosed it elsewhere in any way.
Maybe in recent versions of Android grabbing a paid APK is not as straightforward as it once was. When I was last investigating this possibility, around Android 2.2, it was trivial - once the app was installed, the APK would just sit there in the filesystem. With some hackery, one could even install Google Play on the Android emulator.
Even if it's more tricky these days, all it takes is one determined person with a rooted phone.
Buying, then returningGoogle Play supports a license verification service - an app may ask the Play Market app whether it was indeed purchased there. So a well written LicenseApp would not open up the paid content right away - it should ask Play first.
Enter consumer friendly refund policy. At Google Play, during the first 2 hours a customer may undo a purchase with no help from the vendor whatsoever. So, an obvious, low tech way to get a free license would be - buy the LicenseApp, let it unlock the goodies, then return with a refund. It doesn't require a rooted device.
The only way to combat something like that is checking the license periodically, e. g. once a day, but that's rather user unfriendly. What if the device has no Internet connection and the license check fails - should one lock down the functionality then? I've decided early on that I'm not going down this road; once they buy the license, the "it's bought and paid for" state stays indefinitely.
Spoofing in-app purchases
This kind of fraud is the most technically sophisticated one. There's a certain app out there that can feed valid looking in-app purchase records to apps (I'm not linking to it; do your own homework). It requires a rooted device (naturally), but the IAP record withstands all checks, including the digital signature check. I haven't investigated closely, but they probably leverage some kind of debugging API to short out the system-provided signature verification function.
I have very convincing evidence that people have been trying this against my app. There's a simple call-home functionality on successful in-app purchase; ever once in a while, I'd get a record with an order number that doesn't look like a typical Play order number, and a signature that doesn't pass a check. However, the very fact that I receive those notifications means that the IAP has passed the signature verification on the device! As an engineer, I can't help but admire. Were my app to unlock the paid goodies upon a successful IAP, it'd fall for it.
Again, if this kind of Google Play spoofing is available for the IAP logic, it's equally possible for license verification logic.
All of this brings me to the key insight: don't trust the device. The only way to know if a Google Play order is genuine is by checking against the Play back-end. And that's what I've been doing all along.
When I just started selling Android apps, the payment back-end behind the store (then known as Android Market) was called Google Checkout. It had a very convenient HTTP-based API - one could get a list of orders along with their status, each order record would include customer e-mail address. So once an order went through, I'd e-mail the customer a license code which they'd use to unlock. Life was good.
Then Checkout was phased out in favor of Google Wallet. And the API was gone. One could get by by HTML-scraping the administrative console, but the customer e-mail on the order details screen was gone, too. That was the biggest source of my frustration.
I had to reengineer the purchase UI to ask the user for their e-mail after a successful purchase. Most of the time they do, sometimes they don't. I'm now looking at three valid orders that I don't know what to do with, because I have no address to send the code to.
In the latest iteration of the Wallet back-end (they're no longer calling it "Wallet"), the only way to send a message to the customer is by cancelling and refunding the order. Some irony.
Ways Google is not helpingTo their credit, Google did try to provide some measure of programmatic access to my merchant data. Unfortunately, it's always too little, too late. Functional parity with the legacy Checkout is nowhere to be seen.
I can't e-mail my customers, but they're running my app, aren't they? Can't I leverage that to deliver a message to them? Yes, but how do I know the right user? All I have from the Checkout/Play console is an order number. Here's where Google license API could help - but it doesn't. It provides no data item that I could possibly match against the Play back-end.
Play console provides sales reports, even with programmatic access via Google Storage - but those are not nearly realtime. Also, they don't list some of the very relevant information (e. g. the estimated payout amount in US dollars), and they don't list in-progress and cancelled orders.
Google Play has an API of its own, and it even has a purchase information function, but only for IAP. Paid downloads just aren't there. Also, there's no way to get the list of all transactions - only status for a specific one, and none of the financials are reported.