Como tratar pedidos de reembolso na App Store (e o pedido de consumo)

Na App Store, nunca é o seu negócio a emitir um reembolso de subscrição e nunca responde a uma disputa de cartão. A Apple é o merchant: recebe o pagamento, decide sobre os reembolsos e trata com o banco do cliente. O que pode fazer é mais limitado, mas continua a ser útil: dizer à Apple como o cliente usou realmente aquilo por que pagou, reagir corretamente quando um reembolso é concedido e detetar padrões de abuso.

Este guia cobre esse processo para subscrições com renovação automática. Baseia-se na documentação da própria Apple, sobretudo Send Consumption Information, o corpo ConsumptionRequest, a referência de notificationType e Get Refund History (todos consultados em novembro de 2026).

Como os clientes pedem um reembolso

O guia da Apple sobre o tratamento de notificações de reembolso lista as formas de um cliente pedir o dinheiro de volta:

• contactar o Apple Customer Support;
• usar o site de autosserviço da Apple, reportaproblem.apple.com;
• pedir um reembolso ao emissor do seu meio de pagamento.

Há uma quarta via que controla: a sua app pode abrir a folha de reembolso da Apple com o beginRefundRequest(in:) do StoreKit. A Apple sugere chamá-lo a partir das definições da conta ou de um menu de ajuda. A folha mostra a compra e uma lista de motivos, e a documentação da Apple diz que a App Store demora até 48 horas a aprovar ou recusar o pedido.

Seja qual for a via, a decisão é da Apple. Não tem nenhum botão para aprovar ou recusar.

As notificações que vai receber

Se tiver as App Store Server Notifications V2 configuradas, os reembolsos geram um pequeno conjunto de eventos:

Notificação	O que significa
CONSUMPTION_REQUEST	Um cliente iniciou um pedido de reembolso e a Apple pede-lhe dados de consumo
REFUND	A Apple reembolsou uma transação
REFUND_DECLINED	A Apple recusou um pedido de reembolso
REFUND_REVERSED	A Apple reverteu um reembolso que tinha concedido, por causa de uma disputa aberta pelo cliente
DID_CHANGE_RENEWAL_STATUS com AUTO_RENEW_DISABLED	Entre outros casos, o sistema desativou a renovação automática porque o cliente pediu um reembolso através da sua app
REVOKE	O acesso através da Partilha com a família ou de um grupo terminou, por exemplo porque quem comprou foi reembolsado

O payload de CONSUMPTION_REQUEST inclui um consumptionRequestReason com o motivo dado pelo cliente. A Apple documenta cinco valores: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL e OTHER. Guarde-o. Com o tempo, diz-lhe se os reembolsos vêm de compras acidentais, de bugs ou de pessoas que simplesmente não gostaram do produto.

Responder ao pedido de consumo

A Apple diz que “usa uma variedade de fatores” para decidir sobre um reembolso, e que a informação de consumo que envia é um deles. É a sua única forma de pôr factos à frente de quem analisa.

As regras

A documentação da Apple é estrita em três pontos:

1. Primeiro o consentimento. Só pode enviar dados se o cliente consentiu partilhá-los com a Apple. Se não consentiu, a Apple diz para não responder de todo ao CONSUMPTION_REQUEST. O servidor rejeita qualquer pedido em que customerConsented não seja true com um erro HTTP 400.
2. 12 horas. Responda no prazo de 12 horas após receber a notificação.
3. O consentimento é responsabilidade sua. A Apple afirma que é “o único responsável por obter um consentimento válido”, que este tem de ser livre, específico, informado e inequívoco, e que não deve usar o pedido de App Tracking Transparency para isso. Se adotar a API, tem também de declarar essa utilização de dados nos detalhes de privacidade da sua app.

O pedido

Chama PUT https://api.storekit.apple.com/inApps/v2/transactions/consumption/ seguido do ID da transação da notificação. O corpo ConsumptionRequest tem cinco campos:

Campo	O que pôr nele
customerConsented	true, o único valor que a Apple aceita
deliveryStatus	DELIVERED, ou um de UNDELIVERED_QUALITY_ISSUE, UNDELIVERED_WRONG_ITEM, UNDELIVERED_SERVER_OUTAGE, UNDELIVERED_OTHER
consumptionPercentage	Quanto foi consumido, em milésimas. Tem de ser 0 se o item não foi entregue
refundPreference	Opcional: GRANT_FULL, GRANT_PRORATED ou DECLINE
sampleContentProvided	Se ofereceu uma amostra gratuita, um teste ou uma descrição da funcionalidade antes da compra

Para subscrições com renovação automática, há uma restrição importante: se escolher GRANT_PRORATED, não envie consumptionPercentage. A Apple calcula ela própria a percentagem para subscrições.

Escolher o que dizer

Seja honesto, porque é o correto e porque a Apple tem a última palavra de qualquer forma. Um conjunto simples de regras:

• A app falhou (indisponibilidade, funcionalidade avariada, conteúdo nunca desbloqueado): defina o estado UNDELIVERED_* correspondente, um consumo de 0 e GRANT_FULL. Lutar contra um reembolso por algo que não funcionou não faz sentido.
• Compra acidental, sem utilização: DELIVERED, consumo de 0 ou perto de 0, e GRANT_FULL ou nenhuma preferência.
• Utilização real e continuada ao longo do período: DELIVERED e DECLINE ou GRANT_PRORATED, consoante a sua política.
• Teste gratuito antes do período pago: defina sampleContentProvided como true.

Os números têm de vir dos seus próprios dados de utilização, medidos da mesma forma para todos os clientes. Isso significa que precisa de utilização associada à transação da App Store, o que na prática significa definir um appAccountToken na compra para poder associar a transação da Apple ao seu utilizador.

Quando um reembolso é concedido

Uma notificação REFUND significa que o dinheiro se foi. A referência de notificações da Apple diz que o revocationDate da transação contém a data e hora do reembolso e o revocationReason contém o motivo. Há dois valores de motivo:

• 0: reembolsado por outros motivos, por exemplo uma compra acidental;
• 1: reembolsado por causa de um problema real ou percebido na sua app.

Passos práticos:

1. Revogue o acesso à transação reembolsada e diga-o na app com uma mensagem curta. O guia da Apple recomenda “mensagens contextuais na app para quaisquer ações que tome em consequência do reembolso”.
2. Registe o motivo. Uma proporção crescente do motivo 1 é um sinal sobre o produto, não sobre a faturação.
3. Esteja atento às reversões. Se chegar um REFUND_REVERSED, a Apple diz que tem de repor o conteúdo ou o serviço. Para subscrições com renovação automática, a data de renovação mantém-se.
4. Recupere eventos perdidos. O Get Refund History devolve os reembolsos aprovados pela App Store de um cliente, 20 por página, e a Apple sugere-o para recuperar notificações de reembolso perdidas durante uma indisponibilidade.

E os chargebacks?

Os clientes podem pedir um reembolso ao emissor do cartão, mas na App Store a disputa é entre o banco e a Apple. Não vai receber pedidos de provas para disputas e não há nada a submeter. O que vai ver é o resultado: um REFUND se o dinheiro foi devolvido, e REFUND_REVERSED se a Apple reverteu um reembolso depois de uma disputa do cliente.

Por isso, o “trabalho de chargebacks” numa app iOS é sobretudo prevenção e deteção:

• Torne fácil de encontrar o caminho de reembolso dentro da sua app (a folha beginRefundRequest), para que os clientes insatisfeitos o usem em vez do banco.
• Responda a todos os pedidos de consumo a que pode responder, a tempo.
• Associe os reembolsos às contas. O guia da Apple sugere associar as notificações REFUND às suas contas de utilizador para “identificar compras reembolsadas repetidamente” e atividade suspeita.

Erros comuns

• Enviar dados sem consentimento. É rejeitado pela API e viola as regras da Apple.
• Falhar a janela de 12 horas. Processe o CONSUMPTION_REQUEST numa fila com alerta, não num lote noturno.
• Enviar sempre DECLINE. A sua preferência é apenas um fator, e alegar uma utilização que não consegue provar não ajuda.
• Não revogar depois de um reembolso, ou não repor depois de uma reversão.
• Nenhuma ligação entre as transações da Apple e os seus utilizadores. Sem appAccountToken não consegue medir o consumo, e não consegue responder.

Fazer isto com o NoChurn

O NoChurn lê as suas App Store Server Notifications, por isso os pedidos de reembolso, os reembolsos, as recusas e as reversões aparecem na cronologia de cada cliente com o motivo dado pela Apple. Quando a Apple envia um pedido de consumo para um cliente que consentiu, o NoChurn pode responder com a utilização real desse cliente a partir dos seus dados, dentro da janela da Apple. Os reembolsos alimentam também o score de churn. A Apple fica com o pagamento, a decisão de reembolso e tudo o que envolve o banco do cliente; o NoChurn nunca finge o contrário. A configuração e os limites estão em NoChurn + App Store.