In-App Purchase Security Recommendations
Download llm.txt for an English summary of these in-app purchase security recommendations.
Follow these practices to reduce purchase fraud, payment-data tampering, and unauthorized access to in-app products.
Validate purchases on your server
Client-side validation alone can be bypassed through reverse engineering or a modified app. Verify purchase signatures and transaction data on your server before granting products or services. Use HTTPS between your app and server, record purchase and delivery status, and never trust client-provided data without validation.
Server-side validation reduces risk but does not guarantee complete security by itself.
Protect digital content
Avoid bundling unprotected paid content in your APK, where it can be extracted. When possible, deliver content from your server only after validating the purchase. Use HTTPS, check purchase entitlements before granting access, and encrypt sensitive content stored locally. Do not embed extractable encryption secrets in the app; prefer app-private storage and Android Keystore where appropriate.
Obfuscate application code
Use Android's R8 tooling to make reverse engineering and tampering more difficult. Remove unnecessary code, avoid embedding secrets, and include only the keep rules required by your dependencies. For example, if required by the library version you use:
-keep class com.android.vending.billing.** { *; }
Obfuscation is an additional layer of defense, not a replacement for server-side validation.
Review sample code before release
Sample code demonstrates API usage and may not be production-ready. Adapt and review it for your architecture, handle payment errors and state transitions, implement your own purchase validation and access controls, and remove test data, development settings, and sensitive logs from release builds.
Use secure nonces
When generating random request identifiers or security values, use an unpredictable, cryptographically secure generator such as Android's SecureRandom. Ensure values are unique for their intended validity period. To prevent replay attacks, track nonce validity and reuse on your server; a nonce alone does not prevent replay.
Use Developer Payload carefully
If the Myket Billing API version you use supports Developer Payload, you can attach an optional value to a purchase request. Use it to associate a purchase with an order or user, store the submitted value, and compare it with the returned value. Do not put passwords, authentication tokens, or other secrets in the payload. It is not proof of purchase ownership and does not replace signature or transaction validation.
The developerPayload string must not exceed 800 characters.
Support revoking product access
If paid content or features are delivered by your server, manage user entitlements there as well. Store purchase and entitlement status, verify access before providing sensitive services, and support revoking or correcting access when a purchase becomes invalid or is refunded. Record changes and apply revocation according to clear policies to avoid mistakenly blocking users.
Manage the Myket public key correctly
Each app has its own Myket public key, used to verify purchase signatures. A public key is not secret, and disclosure alone does not allow someone to forge a valid signature. Obtain the correct key from the Myket developer panel, avoid replacing it with a value from an untrusted source, and treat client-side validation as an additional layer. Runtime key obfuscation techniques may make extraction harder but do not guarantee payment security.
Summary
Prioritize server-side validation, correct purchase ownership, protection of digital content, and prevention of duplicate product delivery. R8, secure random values, and code obfuscation can strengthen your app, but they do not replace the core security controls above.