Billing on Android, Goodbye AIDL
Google released the Billing library which makes it considerably easier to handle subscriptions and consumables in Android apps. The reason it is easier to integrate is removing the need to communicate across AIDL (Android Interface Design Language), which added a lot of complexity on top of an already complex cognitive domain of showing products and verifying purchases.
The old way of doing things required making an Intent referencing the com.android.vending.billing.InAppBillingService
in order to establish a ServiceConnection
to obtain a Service
defined as an interface against InAppBillingService
. If that didn't already make your head spin, try dealing with any of the resulting errors.
I never did. Got on the Google Billing Library bandwagon at the first available production ready version (roughly 1.2.2) and never looked back.
I have seen questions about how to implement payment validation client-side only, and it just doesn't make sense from a business perspective once the business makes enough to employ more than one engineer. The loss of revenue due to fraud is mostly going to be prevalent in the more popular applications since there will both be supply of tools and demand to avoid payment.
If you're looking to find whether a given purchase has been refunded another API might help you with that - the Google Play Developer API for purchases - though again that should happen from a private server and not an Android client on a users phone. Both methods require using a private key that should not be exposed, and anything you put in the APK that goes out to users phones should be considered exposed information.