A Apple decide se um reembolso é concedido. O que a política deixa com você é tudo o que acontece em torno dessa decisão, e é aí que está a maior parte das perdas evitáveis.
Ouvimos uma versão dessa história com frequência. Um usuário pede um reembolso à Apple em março. A Apple aprova. O servidor do desenvolvedor nunca fica sabendo. Em junho, esse mesmo usuário continua usando a versão paga do app. Ninguém percebe até o financeiro fazer uma conferência no fim do trimestre, e mesmo assim leva um tempo para entender o que aconteceu. O reembolso está em um relatório de pagamentos. O registro de acesso está no banco de dados do próprio app. Os dois nunca conversam entre si.
É assim que a maioria dos desenvolvedores aprende sobre a política de reembolso da App Store. Não lendo o texto, mas descobrindo, meses depois, o que ela nunca cobriu.
Aqui está a parte que a política não explica. A Apple estornar um pagamento e o seu app remover o acesso são dois eventos diferentes. A Apple cuida do primeiro. Você cuida do segundo. A lacuna entre os dois é onde os desenvolvedores perdem dinheiro silenciosamente, mês após mês. A maior parte deste artigo é sobre fechar essa lacuna.
Então este post analisa a política do ponto de vista do desenvolvedor: o que a Apple controla, o que fica com você e o que seus sistemas precisam fazer depois que um reembolso é concluído. Se você prefere ler o lado prático em vez da política em si, nosso guia sobre como gerenciar reembolsos da App Store sem perder receita do app cobre isso.
Principais pontos
● A Apple toma todas as decisões de reembolso. Não existe um botão no App Store Connect para aprovar ou recusar um reembolso, porque essa escolha nunca foi do desenvolvedor.
● Onde o cliente mora pode mudar o resultado. A elegibilidade e o processo variam por país ou região, conforme os Termos e Condições dos Serviços de Mídia da Apple.
● A Apple pode enviar notificações relacionadas a reembolsos ao seu servidor e pode pedir informações sobre como uma compra foi usada enquanto analisa uma solicitação.
● Você tem 12 horas para responder, e somente se o cliente deu permissão para que essas informações sejam compartilhadas.
● Um reembolso que a Apple aprova e um reembolso que o seu banco de dados registra são dois eventos separados. O espaço entre eles é por onde o dinheiro escapa.
● A automação pode tornar o seu lado do processo mais rápido e consistente. Ela não tem nenhum efeito sobre o que a Apple decide.
O que é a política de reembolso da App Store?
Em resumo, é o conjunto de regras sobre como a Apple lida com a solicitação de reembolso de um cliente, mais uma lista de tarefas técnicas que ficam com o desenvolvedor.
A Apple decide se um reembolso é aprovado. Você não tem voz nisso. Não pode aprovar uma solicitação, nem bloquear uma. O App Store Connect não tem nenhuma tela em que o desenvolvedor vota sobre isso. O máximo que você pode fazer é enviar algumas informações à Apple em alguns pontos do caminho, e chegaremos a isso em breve. Se quiser ver como os clientes realmente enviam uma solicitação, isso está descrito no guia da Apple sobre como solicitar reembolso de apps ou conteúdo.
Costumamos dividir a política em quatro partes para as equipes, porque só duas das quatro são realmente problema seu.
A primeira parte é a elegibilidade. As solicitações vão direto para a Apple, nunca para você. A elegibilidade pode mudar dependendo do país ou região do cliente, e as regras estão nos Termos e Condições dos Serviços de Mídia da Apple. Então, se um usuário perguntar por que o reembolso dele foi aprovado e o de um amigo não, não há resposta simples. Depende de onde cada um mora.
A segunda parte é a decisão em si. Isso é inteiramente da Apple. Você só fica sabendo depois que ela é tomada.
A terceira parte são as suas responsabilidades, e elas são técnicas, não jurídicas, algo que pega as pessoas de surpresa quase sempre. Manter um servidor capaz de receber notificações. Fornecer informações quando a Apple pedir. Manter registros limpos. Esse é o trabalho, por completo.
A quarta parte é o que acontece com os direitos de acesso depois da decisão, e essa é a peça que realmente custa dinheiro. A Apple estornar um pagamento não muda nada no seu banco de dados por si só. Um cliente que recebe um reembolso mas mantém o acesso pago para sempre não é uma falha da política da Apple. É uma lacuna na forma como o seu sistema foi construído.
Você provavelmente consegue adivinhar qual parte importa mais para nós.
Como funciona o processo de reembolso da App Store para desenvolvedores?
O cliente inicia. A Apple conclui. Você fica em algum lugar no meio.
O cliente solicita um reembolso pela Apple
↓
A Apple analisa a solicitação
↓
Seu servidor pode receber uma notificação relacionada ao reembolso
↓
Você fornece informações de apoio, se aplicável
↓
A Apple toma a decisão
↓
Você recebe o resultado como uma notificação
↓
O direito de acesso é atualizado
Duas coisas merecem atenção aqui. A Apple diz aos clientes para esperarem uma resposta em cerca de 24 a 48 horas, e esse prazo não tem nada a ver com o seu, então cuidado com o que a sua equipe de suporte promete enquanto uma solicitação está pendente. E cada etapa acima só funciona se o seu servidor estiver de fato configurado e acessível. Muitas equipes descobrem que o delas não estava. Se o seu endpoint estiver fora do ar, o reembolso acontece mesmo assim. Você simplesmente nunca fica sabendo.
O que as regras de reembolso da App Store significam para desenvolvedores?
Tire a linguagem da política, e as regras viram uma lista curta e pouco glamourosa para a sua equipe de engenharia.
● Registros de transação que você consegue realmente pesquisar. As notificações de reembolso fazem referência aos identificadores de transação da Apple. Se você não os salvou no momento da compra, a notificação é quase inútil. Você também precisa de um vínculo confiável entre cada transação e uma conta de usuário, já que o payload da Apple identifica a compra, não a pessoa que a fez.
● Um endpoint de notificações que funciona e verifica as assinaturas. Os eventos de reembolso chegam por meio das App Store Server Notifications, e os payloads são assinados. Verifique essas assinaturas sempre. Um endpoint que confia em qualquer coisa que recebe é um risco de segurança com uma URL anexada.
● Um fluxo de consentimento, configurado com antecedência. Se a Apple pedir informações de consumo, você só pode responder quando o cliente já tiver concordado em compartilhar esses dados. Essa responsabilidade é sua. A documentação Send Consumption Information da Apple é direta sobre isso, e qualquer resposta enviada sem consentimento é rejeitada. Você também não pode voltar atrás e coletar o consentimento depois que uma solicitação já chegou. Ou você o tinha no momento da compra, ou fica de fora dessa.
● Lógica de entitlement que funciona nos dois sentidos. Reembolsos às vezes são revertidos. A Apple também permite reembolsos parciais, em que só parte de uma compra é devolvida. Total, parcial ou revertido, o seu código precisa lidar com os três.
● Um lugar para os resultados chegarem que o financeiro consiga realmente usar. Um reembolso que só existe dentro do banco de dados do app nunca vai bater com um relatório de pagamentos. A maioria das equipes descobre isso no fechamento do trimestre, e raramente é um bom dia.
Como a política de reembolso da Apple afeta os desenvolvedores?
Todo mundo foca no valor reembolsado. Geralmente é o menor número da história.
Um período de assinatura reembolsado retira uma receita que você já tinha contabilizado, e na maioria dos casos a relação termina ali também. As renovações que você esperava simplesmente param de aparecer. Compras únicas são mais simples, mas ainda chegam depois da venda, então qualquer relatório baseado em números brutos vai superestimar os valores até que os reembolsos sejam subtraídos.
Aqui está a distinção que vale lembrar deste artigo inteiro. Um reembolso que a Apple aprova e um reembolso que o seu sistema realmente registra são dois eventos separados. A metade da Apple acontece no cronograma dela, esteja alguém observando ou não. A sua metade só acontece se o handler de notificações disparou, a transação foi encontrada, a conta foi identificada e o acesso foi atualizado. Perca qualquer um desses elos e o trabalho fica pela metade, e, de fora, ninguém consegue dizer qual metade.
Essa lacuna tem nome: vazamento de reembolsos. São clientes que receberam o dinheiro de volta e mantiveram tudo o que pagaram. Eles não vão relatar isso, porque, do ponto de vista deles, nada está errado. Aparece meses depois durante a conciliação, se é que aparece.
Todo o resto decorre dessa mesma lacuna. Agentes de suporte respondendo tickets sem nenhum registro de reembolso para consultar. Análises que superestimam o valor de vida do cliente porque as reversões nunca entraram nos números. Nenhum histórico de reembolsos para revisar, então ninguém percebe quando um produto está gerando muito mais reembolsos do que os outros.
O que os desenvolvedores devem fazer quando um reembolso da Apple é solicitado?
Sete etapas. A maior parte do trabalho acontece bem antes de qualquer solicitação aparecer.
1. Receba e verifique a notificação
Os eventos de reembolso chegam ao seu endpoint como payloads JWS assinados. Verifique a assinatura contra a cadeia de certificados da Apple. Confirme o bundle ID. Só então aja com base no conteúdo. Isso é higiene básica, e ainda assim há equipes que pulam essa etapa. Um endpoint que aceita qualquer coisa que recebe é um endpoint do qual outra pessoa pode tirar proveito.
2. Localize a transação e a conta
Pegue os identificadores de transação do payload e compare com os seus registros de compra. Se você vinculou um token de conta estável no momento da compra, isso é uma única consulta. Se não, você está chutando sob pressão de tempo.
3. Verifique o que você já sabe sobre a compra
Você não consegue dizer nada útil à Apple até saber o que seus próprios sistemas registraram. O conteúdo foi entregue? Funcionou como esperado? Quanto dele o cliente realmente usou? Se você não consegue responder a isso a partir dos seus próprios registros, esse é o seu primeiro problema real, e não é o reembolso.
4. Envie informações de consumo quando a Apple pedir e houver consentimento
Uma notificação CONSUMPTION_REQUEST da Apple significa que você pode responder com informações sobre como a compra foi usada, mas só se duas coisas forem verdadeiras: o cliente deu consentimento válido e você ainda está dentro da janela de 12 horas definida pela Apple. A documentação atual da Apple vincula essa notificação a solicitações de reembolso em todos os tipos de produto, então construa o seu handler sem presumir que ela sempre vai aparecer. O que você enviar deve vir direto dos seus registros, não de uma estimativa aproximada.
5. Acompanhe o resultado final
O resultado chega como uma notificação. REFUND significa que foi concedido. REFUND_DECLINED significa que não foi. REFUND_REVERSED significa que a Apple reverteu um reembolso que já havia concedido. Salve os três resultados. O caso de reversão é o que as equipes mais esquecem, e uma reversão perdida pode bloquear um cliente pagante de algo que ele legitimamente possui.
6. Atualize o entitlement e o acesso
Revogue o acesso quando um reembolso for concedido. Restaure-o se o reembolso for revertido. Trate o caso parcial, em que só uma porcentagem é devolvida. E execute isso a partir de eventos do lado do servidor, para que o acesso do cliente permaneça correto independentemente de ele abrir o app de novo ou não.
7. Concilie com os relatórios de receita e de assinaturas
Associe o reembolso ao período certo e ao produto certo. Pule essa etapa, e o financeiro e a engenharia acabam olhando para duas versões diferentes do mesmo mês. Quem já passou por essa reunião sabe que vale a pena evitar.
Por que a gestão manual de reembolsos da App Store se torna difícil
Não se trata de descuido. As restrições simplesmente não combinam com um processo que depende de alguém estar acordado e atento o tempo todo.
As solicitações de reembolso aparecem quando os clientes as enviam. Domingo de manhã. Duas da madrugada. Feriados. A janela de resposta não pausa para a agenda de ninguém. Cada solicitação exige uma consulta de transação, uma correspondência de conta, uma verificação de consentimento, um número de uso e uma atualização de entitlement. Em um dia bom, são cerca de cinco minutos de trabalho. Mas é urgente, repetitivo e completamente invisível quando feito direito. Ninguém recebe agradecimentos por um reembolso tratado corretamente às 4 da manhã.
O volume torna tudo mais difícil. Assim como manter mais de um app, com dados de transação em um sistema e dados de conta em outro. Aí o engenheiro que entendia o handler muda de equipe. A planilha de acompanhamento ganha um nome como refunds_OLD_final_v2 e silenciosamente deixa de ser aberta. O financeiro encontra a lacuna no fechamento do trimestre, cerca de três meses depois do ponto em que alguém ainda poderia fazer algo a respeito.
Como os desenvolvedores podem gerenciar reembolsos da App Store com mais confiabilidade?
O monitoramento manual é mais ou menos assim: alguém abre um dashboard, consulta uma transação, atualiza um registro e segue em frente. Funciona bem em baixo volume, e essa é a armadilha, porque não quebra com estrondo. Vai se desgastando aos poucos. Não há um momento único em que para de funcionar, então ninguém percebe a tempo.
A automação tira as etapas mecânicas das mãos das pessoas: receber e verificar notificações, associar transações a contas, montar os dados de resposta, acompanhar janelas de resposta, registrar resultados e manter os entitlements sincronizados.
O que ela não pode fazer é mudar a opinião da Apple. A automação não torna os reembolsos menos prováveis e não pode influenciar uma decisão, independentemente do que algumas ferramentas sugerem. Tudo o que ela muda é se o seu lado do processo acontece de forma consistente e no prazo, e isso, por si só, já é algo significativo de corrigir.
Gestão de reembolsos da App Store é a categoria em que esse trabalho se encaixa, e vale ser direto sobre o que uma ferramenta nesse espaço deve cobrir: tratamento de notificações, associação de transações a usuários, fluxos de resposta que respeitam consentimento e prazos, histórico de reembolsos que você consegue consultar depois e atualizações de entitlement que lidam com reembolsos totais, parciais e revertidos.
O RefundSensor cobre essa parte do trabalho. Ele conecta eventos de reembolso da App Store e do Google Play a um fluxo de trabalho automatizado, para que as respostas saiam dentro da janela da loja sem que ninguém precise vigiar notificações manualmente, e os registros de reembolso permaneçam precisos conforme o volume cresce. Ele não vai mudar o que a Apple decide, porque nada pode. O que muda é quanto trabalho cada reembolso deixa para a sua equipe depois.
Onde essas regras estão documentadas
Três fontes da Apple sustentam tudo o que está acima. Leia-as você mesmo antes de construir qualquer coisa, e volte a consultá-las de vez em quando, já que essa área já mudou mais de uma vez.
Solicitar reembolso de apps ou conteúdo — a política que os clientes veem. Cobre como as solicitações são enviadas, a janela de atualização de 24 a 48 horas e a observação da Apple sobre elegibilidade regional.
Send Consumption Information — o fluxo de resposta voltado ao desenvolvedor. Cobre a exigência de consentimento, a janela de 12 horas e os campos da solicitação. Vale ler na íntegra antes de mexer no tratamento de consumo.
App Store Server Notifications — como os eventos de reembolso chegam ao seu backend. Cobre o formato do payload assinado e os tipos de notificação, incluindo CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED e REFUND_REVERSED.
Se os eventos de reembolso ainda são verificados manualmente
O monitoramento manual funciona bem, até o dia em que deixa de funcionar, e a falha costuma ser silenciosa. Uma notificação que ninguém viu. Uma janela que fechou às 3 da manhã. Um cliente reembolsado que manteve o acesso por um trimestre inteiro.
Se isso soa familiar, o RefundSensor pode tirar o fluxo de reembolsos do acompanhamento manual: os eventos das lojas, as janelas de resposta e a garantia de que os resultados cheguem tanto aos seus registros quanto à sua lógica de entitlement.
Perguntas frequentes
É o conjunto de regras sobre como a Apple lida com solicitações de reembolso de clientes, junto com o trabalho técnico que fica com os desenvolvedores em torno delas. A Apple decide o resultado. Os desenvolvedores cuidam da infraestrutura ao redor: receber notificações, enviar informações de consumo quando são solicitadas e o consentimento permite, e atualizar o acesso e os registros assim que a decisão chega.
Não, e não há como fazer isso mesmo que quisessem. A Apple dá a palavra final em cada solicitação. O endpoint atual de consumo permite sinalizar um resultado preferido, mas isso é um dado entre vários, não uma instrução. A Apple ainda pode decidir de forma diferente.
O cliente envia uma solicitação à Apple. A Apple analisa e pode contatar o seu servidor para obter informações de consumo. Quando há consentimento, você responde dentro da janela definida pela Apple. A Apple decide, envia o resultado como uma notificação própria, e os seus sistemas alinham o entitlement do cliente e os seus registros a essa decisão.
Sim, mas apenas de uma forma restrita. Quando uma notificação CONSUMPTION_REQUEST chega, a Apple quer informações sobre como a compra foi usada. A sua resposta precisa ter consentimento válido do cliente, precisa ser precisa e precisa sair dentro da janela da Apple. Ela informa a análise. Não decide o resultado.
É uma App Store Server Notification que pede ao seu servidor informações sobre uma compra enquanto a Apple analisa uma solicitação de reembolso. Não é o reembolso em si, nem uma decisão. Você tem 12 horas para responder, e somente quando o cliente concordou em compartilhar esses dados.
De duas formas. Diretamente, o período reembolsado é estornado. Indiretamente, a relação geralmente termina ali, então as renovações com que você contava nunca aparecem. Relatórios baseados em renovações brutas superestimam a receita até que os reembolsos sejam subtraídos, e o valor de vida do cliente carrega o mesmo erro adiante.
Três coisas, e depois duas para ficar de olho. Registrar o resultado na transação e no cliente. Revogar o entitlement correspondente. Levar o reembolso para os relatórios de receita no período certo. Depois, tratar o caso parcial, em que só parte de uma transação é devolvida, e manter o caminho de restauração pronto, já que a Apple pode reverter um reembolso mais tarde.
As partes mecânicas, sim, totalmente. Verificar notificações, associar transações a contas, acompanhar janelas de resposta, atualizar entitlements, manter o histórico de reembolsos. Tudo isso é previsível o suficiente para automatizar. O que deve continuar humano é o desenho do fluxo de consentimento e a leitura real dos seus padrões de reembolso, já que eles dizem algo concreto sobre o produto.
