At a glance: Implement receipt validation to protect against fraudulent in-app purchases made in iOS and Android app stores, and make sure an in-app purchase occurred as reported.
Note
Receipt validation for in-app purchases isn't supported for third-party Android app stores.
Receipt validation flow
The receipt validation flow is as follows:
- The user performs an in-app purchase.
- The app store notifies the app of the successful purchase.
- The app developer calls the SDK Receipt Validation function.
validateAndLogInAppPurchase - The SDK calls the AppsFlyer validation service.
- AppsFlyer validates the purchase to make sure it is not fraudulent.
- Upon success, AppsFlyer internally creates a regular af_purchase event. Otherwise, the created event is tagged as fraudulent (available via Protect360).
- The AppsFlyer validation service transfers the response to the SDK.
- The SDK transfers the receipt validation response to the app (either success or fail).
If receipt validation fails, the event displays in the blocked in-app events raw-data report (available to Protect360 subscribers).
For details about the implementation of receipt validation, see the:
Notes:
- For iOS sandbox apps, meaning apps that are not live in the App Store, receipt validation requires some additional code.
- The AppsFlyer receipt validation service is free of charge to all account plans.
Important!
Calling validateAndLogInAppPurchase also generates an af_purchase in-app event. As such, don't generate an af_purchase event when validating. Doing so results in duplicate revenue events.