Myket In-App Purchase Security Recommendations

Purpose: Reduce purchase fraud, payment-data tampering, duplicate fulfillment, and unauthorized access to paid products. These controls reduce risk; no single client- or server-side measure guarantees complete security.

Purchase validation and fulfillment
- Validate purchase signatures and transaction data on your server before granting products or services. Client-only validation can be bypassed through reverse engineering or a modified app.
- Use HTTPS between the app and your server. Do not trust client-provided purchase or user data until it has been validated.
- Record purchase and fulfillment status on the server and prevent the same purchase from granting a product more than once.
- Manage entitlements on the server when appropriate. Support correcting or revoking access for invalid or refunded purchases, and record entitlement changes.

Protect digital content and secrets
- Avoid bundling unprotected paid content in the APK. When possible, deliver it from your server only after validating the purchase and checking the user's entitlement.
- Use HTTPS for content delivery. Encrypt sensitive content stored locally and prefer app-private storage; Android Keystore can help manage cryptographic keys.
- Do not embed passwords, authentication tokens, private credentials, or extractable encryption secrets in the app.

Application hardening and release review
- Android R8 obfuscation can make reverse engineering more difficult, but it is only an additional defense and does not replace server-side purchase validation.
- Remove unnecessary code, avoid embedding secrets, and add dependency-specific R8/ProGuard keep rules only when required by the library version in use. For example, the guide mentions `-keep class com.android.vending.billing.** { *; }` only when required.
- Review sample code before production release. Handle payment errors and state changes, implement purchase validation and access controls, and remove test data, development settings, and sensitive logs.

Nonces and replay protection
- Generate security-sensitive random values with a cryptographically secure generator such as Android `SecureRandom`. Values should be unpredictable and unique during their intended validity period.
- A nonce alone does not prevent replay attacks. The server must validate nonce expiry and whether it has already been used.

Developer Payload
- Use Developer Payload only when supported by the Myket Billing API version in use. It can associate a purchase with an order or user; store the submitted value and compare it with the returned value.
- Never put passwords or authentication tokens in Developer Payload. It is not proof of purchase ownership and does not replace signature and transaction validation. Keep Developer Payload at or below 800 characters.

Myket public key
- Each app has a Myket public key used to verify purchase signatures. A public key is not secret, and disclosure alone does not enable forging a valid signature.
- Obtain the correct key from the Myket developer panel and do not replace it with a value from an untrusted source. Treat client-side validation as an additional layer only.
- Runtime key-obfuscation techniques may make extraction harder but do not guarantee payment security.