And that user then promptly refunded the game within the (then-new) 15 minute window.
And (surprise!) someone ended up uploading a "cracked"  version of my game to warez sites shortly thereafter. Talk about adding insult to injury.
 I used a sneaky way to detect "cracks" in my game that involved, in part, letting the hacker think they'd cracked it: The game would query Google to see if they'd paid for it, and if not, it would throw a "Sorry, you don't own this game" dialog up. There were scripts around that would remove the standard Google DRM, though; instead of fighting that, I LET them "hack" it, and afterwards it wouldn't bring up that dialog any more. But then the behavior reverted to being identical to the free demo (first 30 levels free, then you had to buy the real game). It was "hacked" almost a dozen times, and never once did anyone figure out how to get past the second layer of protection.
And the best part was the encryption on ALL the games' data files was based on a key derived from the binary executable (the .so file), so if anyone were to hack that executable, the game wouldn't run at all. I should have thrown up a screen that let people know that it was a cracked version, and where to get the real thing. And I DEFINITELY should have changed the Flurry code; my "paid game" analytics were completely shot after the cracks were released. Duh.
A serious hack attempt would have broken it, no question; there's no unbreakable DRM, after all, and I wasn't even using serious encryption (I decided it didn't matter: A typical attacker is not going to attack the encryption mathematically, they're going to decompile the binary to get the key AND algorithm, so as long as it can stand up to trivial attacks, it's strong enough -- connecting to a known encryption algorithm might actually make it EASIER for them, since then they'd have known function names and parameters). I just wanted to raise the bar.