O Legacy não aparece como um tipo de produto na página de configurações de receita, portanto você não pode confirmar o uso do Legacy apenas pela IU. Use os seguintes métodos em conjunto:

• Primeiro, verifique os dados brutos. Procure eventos af_purchase com event_source: SDK e is_receipt_validated: true. Estes são candidatos, mas chamadas logEvent podem produzir eventos semelhantes, portanto isso não é conclusivo por si só.
• Confirme no código do SDK. Se o seu aplicativo chamar validateAndLogInAppPurchase com a assinatura legada, ele está 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 modo Legacy.

O serviço de backend de Validação de recibos 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 não recebem mais 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 compra validados, 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 Migrar da Validação de recibos para ROI360 Store Revenue.

Se você quiser ir além e habilitar 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 de preço da assinatura, integre o componente SDK Purchase Connector. Isso é uma atualização do aplicativo, mas é opcional. O fluxo manual validateAndLogInAppPurchase (v2) funciona no ROI360 Store Revenue mesmo sem ele.

sim, sim, Você pode reportar eventos de compra in-app com a API padrão logEvent. Mas você 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 false quando isso falha. Sem validação, essa flag não está presente.
• 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 nenhuma 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 pular totalmente a validação.

Isso depende de qual produto você usa:

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

A fonte da receita mudou. A versão legada 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 para parceiros refletirão um número diferente após a migração.

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

Se você ainda enviar o valor af_revenue, ele será preservado no evento dentro do objeto custom_data. Os dashboards e os postbacks dos 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 enviava um valor personalizado no 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 evento 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 do ciclo de vida completo da assinatura (renovações, cancelamentos, reembolsos, upgrades) estão disponíveis somente 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 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; assim, 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 Settings > ROI360 > Revenue settings > Purchases & subscriptions, selecione Receipt validation 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 gerar um evento af_purchase real, teste por meio de um pipeline de produção (sem TestFlight no iOS e sem Licensed Tester no Android).