O Legacy não aparece como tipo de produto na página de configurações de receita, então você não consegue confirmar o uso do Legacy apenas pela interface. Use os métodos a seguir em conjunto:

• Primeiro, examine os dados brutos. Procure eventos af_purchase com event_source: SDK e is_receipt_validated: true. Esses são candidatos, mas chamadas logEvent podem produzir eventos semelhantes, então isso não é conclusivo por si só.
• Confirme no código do SDK. Se o seu aplicativo chamar validateAndLogInAppPurchase com a assinatura legada, ele estará no modo Legacy. A assinatura legada inclui:
  • Android: chave de licença, payload JSON, preço, moeda
  • iOS: ID do produto, preço, moeda, ID da transação
• Entre em contato com seu CSM. Eles podem confirmar quais dos seus aplicativos ainda estão no Legacy.

O serviço de backend de validação de recibos do Legacy será desativado. A partir desse dia:

• O método legado validateAndLogInAppPurchase será considerado como obsoleto a partir das seguintes versões do SDK:
• Os eventos af_purchase validados e registrados por esse método não são mais registrados na AppsFlyer.
• Dashboards, dados brutos e postbacks de parceiros deixam de receber dados de compra do Legacy.

Para continuar capturando compras validadas, migre para uma das alternativas compatíveis antes de 7 de setembro de 2026.

Sem. Os dois produtos funcionam em paralelo até 7 de setembro de 2026. Ativar a nova validação de recibos na AppsFlyer não afeta as versões do aplicativo que ainda chamam o método legado. Elas continuam funcionando como antes até a data de descontinuação.

Usuários em versões antigas do aplicativo continuam gerando eventos af_purchase validados até 7 de setembro de 2026. Para continuar recebendo dados de compras validadas, lance a versão atualizada do seu aplicativo com antecedência suficiente para alcançar a maior parte da sua base de usuários antes da descontinuação.

sim, sim, Ambos os produtos usam o mesmo método do SDK validateAndLogInAppPurchase (v2), portanto mudar de Validação de recibos para Receita da loja do ROI360 não exige uma alteração no SDK nem o lançamento de uma nova versão do aplicativo. Para mudar, altere o Tipo de produto na página Configurações de receita e conclua a configuração adicional do ROI360 (notificações do servidor da App Store para iOS, RTDN do Google Play para Android). Veja Mudar para ROI360 Store Revenue da validação de recibos.

Se você quiser ir além e ativar a detecção automática de compras, a cobertura completa do ciclo de vida da assinatura (incluindo renovações, upgrades e assinantes existentes) e o tratamento de alterações no preço da assinatura, integre o componente SDK Purchase Connector. Essa é uma atualização do aplicativo, mas é opcional. O fluxo manual validateAndLogInAppPurchase (v2) funciona no ROI360 Store Revenue sem isso.

sim, sim, Você pode reportar eventos de compra in-app com a API padrão logEvent. Mas você vai deixar de ter:

• Validação de recibos nas lojas de aplicativos, que filtra compras fraudulentas
• A flag af_validated nos eventos: definida como true quando a AppsFlyer verifica a compra com sucesso na loja e como false quando a verificação falha. Sem validação, essa flag não aparece.
• Postbacks de receita precisos para seus parceiros de UA. Sem validação, qualquer af_revenue que você enviar será registrado e enviado às networks como está, sem confirmação de que a compra realmente ocorreu

Por esses motivos, a AppsFlyer recomenda usar a validação de recibos ou o ROI360 Store Revenue, em vez de ignorar totalmente a validação.

Depende de qual produto você usa:

• Validação de recibos: o callback do SDK retorna um código de erro. Seu aplicativo precisa lidar com a falha e implementar a própria lógica de nova tentativa.
• ROI360 Store Revenue: a AppsFlyer tenta validar novamente automaticamente assim que o serviço da loja se recupera e regenera os eventos perdidos durante a janela de indisponibilidade.

A fonte da receita mudou. O modelo legado usava o valor que você enviava na chamada do SDK. A nova validação de recibos usa a receita bruta retornada pela loja. Se antes você enviava um valor personalizado, por exemplo, a receita líquida após a dedução da taxa da loja, seus dashboards e postbacks de parceiros vão refletir um número diferente após a migração.

Se você precisa de receita líquida, use ROI360 Store Revenue. Ele registra a receita bruta e a líquida (bruta menos taxas e impostos da loja).

Se você ainda enviar o valor de af_revenue, ele será preservado no evento dentro do objeto custom_data. Dashboards e postbacks de parceiros usam o valor bruto da resposta da loja, não o seu valor personalizado.

sim, sim, Após a migração, os postbacks de af_purchase passam a incluir a receita bruta da loja. Se você antes passava um valor personalizado em Legacy, seus parceiros verão um número diferente. Informe seus parceiros de UA antes de implementar a migração, especialmente os parceiros que usam dados de receita para otimização de campanha.

O Legacy gerava um único evento af_purchase para todos os tipos de transação. A nova validação de recibos usa nomes de eventos distintos:

• Compra única: af_purchase
• Início do teste: af_ars_trial_started
• Início da assinatura: af_ars_subscription_started
• Compra em sandbox: af_purchase_sandbox_sdk
• Assinatura ou teste em sandbox: af_ars_sandbox_sdk

Os eventos completos do ciclo de vida da assinatura (renovações, cancelamentos, reembolsos, upgrades) estão disponíveis apenas no ROI360 Store Revenue. Para ver a lista completa de eventos, consulte Sobre a validação de recibos.

A nova validação de recibos ainda retorna um resultado de validação para o callback do seu SDK, que você pode usar para controlar o acesso ao conteúdo comprado. O resultado é mais preciso porque depende dos mecanismos de validação mais recentes fornecidos pela Apple App Store e pelo Google Play, portanto o sinal que você recebe no callback é mais confiável.

O novo validateAndLogInAppPurchase exige um parâmetro obrigatório PurchaseType. Defina-o como one-time ou subscription com base no tipo de transação.

Seu aplicativo integrou o novo método validateAndLogInAppPurchase (v2), mas o produto não está configurado no dashboard da AppsFlyer. Abra Configurações > ROI360 > Configurações de receita > Compras & assinaturas, selecione Validação de recibos ou ROI360 e conclua as etapas de configuração.

af_purchase é registrado apenas para transações de produção. As transações de sandbox são registradas como af_purchase_sandbox_sdk. Para produzir um evento af_purchase real, teste por meio de um pipeline de produção (sem TestFlight no iOS, sem Licensed Tester no Android).