Todo reembolso por upgrade de assinatura é uma decisão da loja, não sua, e sai direto dos seus rendimentos

Um cliente toca em fazer upgrade, passa do seu nível de cinco dólares para o de dez dólares, e você registra uma venda maior. A loja faz outra coisa nesse mesmo momento, e você nunca a vê. Ela entrega a esse cliente um reembolso por upgrade de assinatura pelos dias que ele já havia pago no plano antigo, e esse dinheiro sai dos seus rendimentos. Ninguém perguntou a você. Na App Store você nem sequer vai encontrar o valor nos eventos que o seu servidor recebe.

Este não é o reembolso que você pode contestar. Não é um CONSUMPTION_REQUEST da Apple e não é uma análise de chargeback do Google Play. É rateio, embutido na forma como as duas lojas deixam as pessoas trocarem de plano, e ele roda sozinho toda vez que um assinante sobe de nível. Veja o que um reembolso por upgrade realmente é em cada loja, por que a Apple mantém o valor fora do seu servidor e quanto a configuração errada do Google Play custa a você.

O que é de fato um reembolso por upgrade de assinatura

Um reembolso por upgrade é a loja acertando as contas pelo tempo que o cliente pagou mas não vai usar. Não tem nada a ver com uma reclamação, uma disputa ou a sua política de reembolsos. Ele dispara apenas pela mecânica da troca de plano.

É rateio, não uma reclamação do cliente

Quando um assinante passa para um nível superior no meio de um período de cobrança, ele já pagou até o fim daquele período pelo preço antigo. A loja o compensa pela parte não usada. A Apple emite um reembolso proporcional da assinatura original. O Google Play credita o valor não usado no novo plano. Nenhum dos dois passa por um fluxo ao qual você possa responder, e nenhum dos dois espera a sua aprovação.

Só um upgrade dispara isso

A direção da troca decide o dinheiro. Na App Store, um upgrade é uma passagem para um produto de posição mais alta no mesmo grupo de assinaturas, e só essa passagem é imediata e reembolsada. Um downgrade é uma passagem para uma posição mais baixa, e entra em vigor na próxima renovação sem reembolso. Um crossgrade é uma passagem entre produtos da mesma posição, e o seu momento depende das durações envolvidas. Ordene os produtos de forma errada no App Store Connect e uma troca que você acha que é um upgrade vai se comportar como outra coisa.

Por que a App Store esconde o reembolso por upgrade do seu servidor

Aqui está a parte que quebra o relatório de receita. A Apple emite o reembolso por upgrade, mas nunca diz ao seu servidor quanto reembolsou.

isUpgraded é o único sinal, e o preço está errado

A nova transação chega com isUpgraded definido como true, o que informa que houve uma troca de plano. O campo de preço nessa transação continua mostrando o preço de exibição cheio do novo nível, não o valor que a Apple recuperou do antigo. Nenhuma App Store Server Notification carrega o número do reembolso. Nas próprias palavras da Apple nos fóruns de desenvolvedores, o valor do reembolso proporcional não está disponível pela App Store Server API, pelas Notifications nem pelo StoreKit, e o relatório do App Store Connect é a sua fonte para todos os fins de contabilidade financeira.

O relatório financeiro é o único registro honesto

Os relatórios financeiros e de vendas do App Store Connect contabilizam o reembolso por upgrade proporcional, porque esses relatórios definem o que a Apple de fato paga a você. Isso os torna a fonte de verdade para qualquer assinante que já tenha subido de nível. Monte a sua contabilidade a partir dos relatórios, e trate os eventos do servidor como sinais de direito de acesso, não como receita.

Quanto isso custa a você, em dinheiro

O reembolso por upgrade não é um erro de arredondamento. São rendimentos reais, e no Google Play você ainda escolhe quanto do tempo não usado você dá de graça.

O reembolso são rendimentos que você já havia registrado

Pegue um assinante do seu nível de 9.99 por mês que faz upgrade para 19.99 no dia 20 de um ciclo de 30 dias. Cerca de um terço do mês fica sem uso, então a Apple reembolsa cerca de 3.33 dos 9.99 originais. Você não perde a venda toda. Você devolve a parte que o cliente pagou adiantado e não vai usar. O que importa é que a devolução é automática e recai sobre a venda antiga, então os rendimentos que você já havia contado encolhem depois. Multiplique isso por cada assinante que sobe de nível no meio do ciclo e é uma linha que você deveria conseguir enxergar, não uma lacuna que você descobre no repasse.

No Google Play, o modo de substituição é a verdadeira alavanca de custo

O Google Play não reembolsa dinheiro ao cartão em um upgrade. Ele acerta o tempo não usado de uma entre várias formas, e você escolhe qual passando um modo de substituição ao iniciar o fluxo de compra. A escolha decide se você entrega ao cliente tempo pago ou cobra a diferença dele. O Google recomenda CHARGE_PRORATED_PRICE para upgrades e DEFERRED para downgrades, mas o padrão da biblioteca é WITH_TIME_PRORATION, então um fluxo que você nunca configurou está creditando tempo em silêncio.

Como evitar que os reembolsos por upgrade surpreendam a sua contabilidade

Você não pode desligar o rateio, e nem iria querer, porque é o que torna uma troca de plano justa para o cliente. O que você pode fazer é enxergá-lo, precificá-lo e mantê-lo separado dos reembolsos que você de fato pode contestar.

Concilie os upgrades da Apple com o relatório financeiro

Como o valor do reembolso nunca chega ao seu servidor, os relatórios financeiros e de vendas do App Store Connect são o único lugar onde um reembolso por upgrade proporcional aparece. Concilie a receita por assinante com esses relatórios a cada período, e não calcule a receita a partir de um total acumulado de Server Notifications. A marca isUpgraded informa que houve uma troca. O relatório informa quanto ela custou.

Escolha o modo de substituição do Google Play de propósito

Passe um modo de substituição para cada troca de plano de forma deliberada. Use CHARGE_PRORATED_PRICE quando quiser cobrar a diferença de preço agora em um upgrade. Deixe WITH_TIME_PRORATION no lugar só quando a sua intenção for dar ao cliente o tempo restante. Use DEFERRED para downgrades para manter a receita atual até o prazo acabar. O padrão é uma decisão, e o padrão errado dá margem de graça um upgrade de cada vez.

Mantenha os reembolsos por upgrade separados dos reembolsos que você pode contestar

Um reembolso por upgrade é automático e definitivo por design. Não é um cliente pedindo o dinheiro de volta. Os reembolsos em que você de fato pode influir são os iniciados pelo cliente, em que a Apple envia um CONSUMPTION_REQUEST e dá 12 horas para você responder, e em que o Google Play abre uma análise de chargeback pelo orders.reviewrefund com uma janela de 24 horas. Marque os seus dados para que os dois nunca se misturem. Uma linha você concilia. A outra linha você responde, contra o relógio.

A versão curta

Quando um cliente faz upgrade de uma assinatura, a loja acerta o tempo não usado para ele de forma automática. A Apple reembolsa o valor proporcional do plano antigo imediatamente e nunca envia o número ao seu servidor, então os relatórios financeiros do App Store Connect são o único registro exato. O Google Play credita o tempo ou cobra a diferença dependendo do modo de substituição que você definir, e o padrão entrega ao cliente tempo pago que você entrega a custo. Nada disso passa por um CONSUMPTION_REQUEST ou por uma análise de chargeback, então não há nada a contestar. Concilie o reembolso por upgrade, defina o seu modo do Google Play de propósito e mantenha-o separado dos reembolsos pelos quais você ainda pode brigar.