Legacy no aparece como tipo de producto en la página de configuración de ingresos, así que no puedes confirmar el uso de Legacy solo desde la interfaz de usuario. Usa los siguientes métodos en conjunto:

• Primero, revisa el raw data. Busca eventos af_purchase con event_source: SDK e is_receipt_validated: true. Son candidatos, pero las llamadas a logEvent pueden generar eventos similares, por lo que esto no es concluyente por sí solo.
• Confírmalo en el código del SDK. Si tu aplicación llama a validateAndLogInAppPurchase con la firma heredada, está en modo Legacy. La firma heredada incluye:
  • Android: clave de licencia, payload JSON, precio, moneda
  • iOS: ID de producto, precio, moneda, ID de transacción
• Contacta con tu CSM. Pueden confirmar cuáles de tus aplicaciones siguen en modo Legacy.

El servicio backend de Validación de recibos Legacy se cierra. A partir de ese día:

• A partir de las siguientes versiones de SDK, el método heredado validateAndLogInAppPurchase está marcado como obsoleto:
• Los eventos af_purchase validados y registrados por ese método dejan de registrarse en AppsFlyer.
• Los dashboards, los raw data y los postbacks de partners dejan de recibir datos de compra desde Legacy.

Para seguir capturando compras validadas, migra a una de las alternativas compatibles antes del 7 de septiembre de 2026.

N.º Ambos productos funcionan en paralelo hasta el 7 de septiembre de 2026. Activar la nueva Validación de recibos en AppsFlyer no afecta a las versiones de la aplicación que aún llaman al método heredado. Siguen funcionando como antes hasta la fecha de retirada.

Los usuarios de versiones antiguas de la aplicación seguirán generando eventos af_purchase validados hasta el 7 de septiembre de 2026. Para seguir recibiendo datos de compras validadas, lanza la versión actualizada de tu aplicación con suficiente antelación para llegar a la mayor parte de tu base de usuarios antes de la retirada.

Sí. Ambos productos usan el mismo método del SDK validateAndLogInAppPurchase (v2), por lo que pasar de Validación de recibos a ROI360 Store Revenue no requiere ningún cambio en el SDK ni lanzar una nueva versión de la aplicación. Para cambiarlo, modifica el Tipo de producto en la página Configuración de ingresos y completa la configuración adicional de ROI360 (notificaciones del servidor de la App Store para iOS, RTDN de Google Play para Android). Consulta Cambiar a ROI360 Store Revenue desde la Validación de recibos.

Si quieres ir un paso más allá y habilitar la detección automática de compras, una cobertura completa del ciclo de vida de las suscripciones (incluidas las renovaciones, las actualizaciones y los suscriptores existentes) y la gestión de los cambios de precio de las suscripciones, integra el componente SDK Purchase Connector. Es una actualización de la aplicación, pero es opcional. El flujo manual validateAndLogInAppPurchase (v2) funciona en ROI360 Store Revenue sin él.

Sí. Puedes reportar eventos de compra in-app con la API estándar logEvent. Pero te perderás lo siguiente:

• La validación de recibos con las tiendas de aplicaciones, que filtra las compras fraudulentas
• La marca af_validated en los eventos: se establece en true cuando AppsFlyer verifica correctamente la compra con la tienda, y en false cuando falla. Sin validación, esta marca no está presente.
• Postbacks de ingresos precisos para tus partners de UA. Sin validación, cualquier valor de af_revenue que envíes se registra y se envía a las redes tal cual, sin confirmar que la compra se haya producido realmente

Por estas razones, AppsFlyer recomienda usar la Validación de recibos o ROI360 Store Revenue, en lugar de omitir la validación por completo.

Depende del producto que uses:

• Validación de recibos: la devolución de llamada del SDK devuelve un código de error. Tu aplicación debe gestionar el fallo e implementar su propia lógica de reintento.
• ROI360 Store Revenue: AppsFlyer reintenta la validación automáticamente cuando el servicio de la tienda se recupera y vuelve a generar los eventos perdidos durante la ventana de interrupción.

La fuente de ingresos cambió. Legacy usaba el valor que enviabas en la llamada al SDK. La nueva Validación de recibos usa los ingresos brutos que devuelve la tienda. Si antes enviabas un valor personalizado, por ejemplo, los ingresos netos después de deducir la comisión de la tienda, tus Dashboards y los postbacks a Partners reflejarán una cifra diferente después de la migración.

ROI360 Store Revenue. Una solución premium de medición de ingresos que incluye seguimiento de reembolsos, visibilidad completa del ciclo de vida de suscripciones y cálculo de ingresos netos.

Si sigues enviando el valor af_revenue, se conserva en el evento dentro del objeto custom_data. Los dashboards y los postbacks de Partners usan el valor bruto de la respuesta de la tienda, no tu valor personalizado.

Sí. Después de la migración, los postbacks de af_purchase incluyen los ingresos brutos de la tienda. Si antes pasabas un valor personalizado en Legacy, tus Partners verán un número diferente. Asegúrate de informar a tus Partners de UA antes de implementar la migración, especialmente a aquellos Partners que usan datos de ingresos para la optimización de campañas.

Legacy generaba un único evento af_purchase para todos los tipos de transacción. La nueva Validación de recibos usa nombres de eventos distintos:

• Compra única: af_purchase
• Inicio de prueba: af_ars_trial_started
• Inicio de suscripción: af_ars_subscription_started
• Compra en sandbox: af_purchase_sandbox_sdk
• Suscripción o prueba en sandbox: af_ars_sandbox_sdk

Los eventos del ciclo de vida completo de la suscripción (renovaciones, cancelaciones, reembolsos, mejoras) solo están disponibles en ROI360 Store Revenue. Para consultar la lista completa de eventos, consulta Acerca de la Validación de recibos.

La nueva Validación de recibos sigue devolviendo un resultado de validación a la devolución de llamada del SDK, que puedes usar para controlar el acceso al contenido comprado. El resultado es más preciso porque se basa en los mecanismos de validación más recientes proporcionados por la tienda de aplicaciones de Apple y Google Play, por lo que la señal que recibes en la devolución de llamada es más fiable.

El nuevo validateAndLogInAppPurchase requiere un parámetro PurchaseType obligatorio. Configúralo como one-time o subscription según el tipo de transacción.

Tu app ha integrado el nuevo método validateAndLogInAppPurchase (v2), pero el producto no está configurado en el Dashboard de AppsFlyer. Abre Settings > ROI360 > Revenue settings > Purchases & subscriptions, selecciona Receipt validation o ROI360 y completa los pasos de configuración.

af_purchase solo se registra para transacciones de producción. Las transacciones de sandbox se registran como af_purchase_sandbox_sdk. Para generar un evento af_purchase real, prueba a través de un flujo de producción (sin TestFlight en iOS ni Licensed Tester en Android).