Legacy no aparece como tipo de producto en la página de configuración de ingresos, así que no puedes confirmar si se usa 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 y is_receipt_validated: true. Son posibles candidatos, pero las llamadas a logEvent pueden generar eventos similares, así que esto por sí solo no es concluyente.
• Confírmalo en el código del SDK. Si tu aplicación llama a validateAndLogInAppPurchase con la firma heredada, está en Legacy. La firma heredada incluye:
  • Android: clave de licencia, payload JSON, precio, divisa
  • iOS: ID de producto, precio, divisa, ID de transacción
• Contacta con tu CSM. Pueden confirmar cuáles de tus aplicaciones siguen en Legacy.

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

• Cualquier llamada al método heredado validateAndLogInAppPurchase no devuelve ninguna respuesta de validación, independientemente de la versión del SDK.
• Los eventos af_purchase validados y registrados por ese método dejan de registrarse en AppsFlyer.
• Los dashboards, el raw data y los postbacks de partners ya no reciben datos de compra de Legacy.

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

N.º Los dos productos funcionan en paralelo hasta el 7 de septiembre de 2026. Habilitar la nueva validación de recibos en AppsFlyer no afecta a las versiones de la aplicación que siguen llamando al método heredado. Siguen funcionando como antes hasta la fecha de retirada.

Los usuarios que usan versiones antiguas de la aplicación seguirán generando eventos af_purchase validados hasta el 7 de septiembre de 2026. Para seguir obteniendo datos de compras validados, 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), así que cambiar de la 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 hacer el cambio, 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 App Store para iOS y Google Play RTDN 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 mejoras de plan y los suscriptores existentes) y la gestión de cambios de precio de suscripciones, integra el componente del SDK Purchase Connector. Eso requiere 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 frente a 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 aparece.
• Postbacks de ingresos precisos para tus partners de UA. Sin validación, cualquier 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 estos motivos, 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 error e implementar su propia lógica de reintento.
• Ingresos de la tienda ROI360: AppsFlyer reintenta la validación automáticamente una vez que el servicio de la tienda se recupera y vuelve a generar los eventos que se hayan perdido durante la ventana de la interrupción.

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

Si necesitas los ingresos netos, usa ROI360 Store Revenue. Registra tanto los ingresos brutos como los netos (brutos menos las comisiones e impuestos de la tienda).

Si sigues pasando 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 una cifra diferente. Asegúrate de informar a tus partners de UA antes de implementar la migración, sobre todo a los 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 puntual: 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 de todo el ciclo de vida de la suscripción (renovaciones, cancelaciones, reembolsos y 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 que proporcionan el Apple App Store 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 en función del 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 Configuración > ROI360 > Configuración de ingresos > Compras & suscripciones, selecciona Validación de recibos 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, haz la prueba a través de un flujo de producción (no TestFlight en iOS, no Licensed Tester en Android).