[Legacy] Receipt validation for in-app purchases

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: This is a legacy feature. Learn more about the new, fully automatic, and improved in-app purchase validation mechanism.


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:

  1. The user performs an in-app purchase.
  2. The app store notifies the app of the successful purchase.
  3. The app developer calls the SDK Receipt Validation function.
  4. The SDK calls the AppsFlyer validation service.
  5. AppsFlyer validates the purchase to make sure it is not fraudulent.
  6. Upon success, AppsFlyer internally creates a regular af_purchase event. Otherwise, the created event is tagged as fraudulent (available via Protect360). 
  7. The AppsFlyer validation service transfers the response to the SDK.
  8. 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 our developer SDK documentation:


  • 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.
  • For Android, receipt validation may return a null result and consider the validation failed if the end user doesn't have internet access during the purchase.


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.