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.

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.
    validateAndLogInAppPurchase
  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 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.

Was this article helpful?