[WIP] Bulletin: End of support for legacy Receipt Validation

You can't tell from the AppsFlyer dashboard. legacy doesn't appear as a product type in the Revenue settings page. Use the following two methods to check:

• Check the SDK code. If your app calls validateAndLogInAppPurchase with a license key, signature, and JSON payload (Android) or a product ID, price, currency, and transaction ID (iOS), it's using legacy.
• Scan raw data. Look for af_purchase events with event_source: SDK and is_receipt_validated: true. Note that logEvent calls can produce similar events, so treat these as candidates and confirm in the code.

If you're unsure, contact your CSM. They can confirm which of your apps are still on legacy.

The legacy Receipt Validation backend service shuts down. From that day:

• Any call to the legacy validateAndLogInAppPurchase method returns no validation response, regardless of SDK version.
• af_purchase events validated and logged by that method are no longer recorded in AppsFlyer.
• Dashboards, raw data, and partner postbacks no longer receive purchase data from legacy.

To keep capturing validated purchases, migrate to one of the supported alternatives before September 7, 2026.

No. The two products run in parallel until September 7, 2026. Enabling the new Receipt Validation in AppsFlyer has no effect on app versions that still call the legacy method. They continue to work as before until the sunset date.

Users on old app versions continue to generate validated af_purchase events until September 7, 2026. To continue getting validated purchase data, release your updated app version before the sunset date.

Yes. Both products use the same validateAndLogInAppPurchase (v2) SDK method, so switching from Receipt Validation to ROI360 Store Revenue doesn't require an SDK change or app release. Change the Product type on the Revenue settings page and complete the additional ROI360 setup (App Store server notifications for iOS, Google Play RTDN for Android).

If you want to go further and enable automatic purchase detection, full subscription lifecycle coverage (including renewals, upgrades, and existing subscribers), and subscription price-change handling, integrate the Purchase Connector SDK component. That's an app update, but it's optional. The manual validateAndLogInAppPurchase (v2) flow works in ROI360 Store Revenue without it.

Yes. You can report in-app purchase events with the standard logEvent API. But you'll miss out on:

• Receipt Validation against the app stores, which filters out fraudulent purchases
• The af_validated flag on events: set to true when AppsFlyer successfully verifies the purchase with the store, false when it fails. Without validation, this flag is absent.
• Accurate revenue postbacks to your UA partners. Without validation, any af_revenue you pass is recorded and sent to networks as-is, with no confirmation that the purchase actually occurred

For these reasons, AppsFlyer recommends using either Receipt Validation or ROI360 Store Revenue rather than skipping validation entirely.

It depends on which product you use:

• Receipt Validation: the SDK callback returns an error code. Your app needs to handle the failure and implement its own retry logic.
• ROI360 Store Revenue: AppsFlyer retries validation automatically once the store service recovers, and regenerates any missed events for the outage window.

The revenue source changed. legacy used the value you passed in the SDK call. The new Receipt Validation uses the gross revenue returned by the store. If you previously passed a custom value, for example net revenue after store fee deduction, your dashboards and partner postbacks will reflect a different number after migration.

If you need net revenue, use ROI360 Store Revenue. It records both gross and net (gross minus store fees and taxes).

If you still pass the af_revenue value, it's preserved on the event inside the custom_data object. Dashboards and partner postbacks use the gross value from the store response, not your custom value.

Yes. After migration, af_purchase postbacks carry the gross revenue from the store. If you previously passed a custom value under legacy, your partners will see a different number. Make sure to inform your UA partners before rolling out the migration, especially those that use revenue data for campaign optimization.

legacy produced a single af_purchase event for all transaction types. The new Receipt Validation uses distinct event names:

• One-time purchase: af_purchase
• Trial start: af_ars_trial_started
• Subscription start: af_ars_subscription_started
• Sandbox purchase: af_purchase_sandbox_sdk
• Sandbox subscription or trial: af_ars_sandbox_sdk

Full subscription lifecycle events (renewals, cancellations, refunds, upgrades) are only available in ROI360 Store Revenue. For the full event list, see About Receipt Validation.

The new Receipt Validation still returns a validation result to your SDK callback that you can use to control access to purchased content. The result is more accurate because it relies on the latest validation mechanisms provided by the Apple App Store and Google Play, so the signal you receive in the callback is more trustworthy.

The new validateAndLogInAppPurchase requires a mandatory PurchaseType parameter. Set it to one-time or subscription based on the transaction type.

Your app has integrated the new validateAndLogInAppPurchase (v2) method, but the product isn't configured in the AppsFlyer dashboard. Open Settings > ROI360 > Revenue settings > Purchases & subscriptions, select either Receipt Validation or ROI360, and complete the setup steps.

af_purchase is logged only for production transactions. Sandbox transactions are logged as af_purchase_sandbox_sdk. To produce a real af_purchase event, test through a production pipeline (non-TestFlight on iOS, non-Licensed Tester on Android).