Resposta rápida: Antes de enviar dados de consumo para a Apple em resposta a um CONSUMPTION_REQUEST, você precisa ter consentimento válido do cliente e definir customerConsented como true. A notificação da Apple não informa se o consentimento existe — por design, a Apple espera que seu app, e não seu servidor, colete esse consentimento. E como é você quem compartilha dados coletados do usuário, a responsabilidade legal por esse consentimento é inteiramente sua, não da Apple. Errar nesse ponto é um problema de lei de privacidade, não apenas uma chamada de API rejeitada.
A lacuna que a maioria dos desenvolvedores ignora
Guias sobre automação de reembolso adoram falar sobre a janela de 12 horas e os campos de consumo. Quase nenhum deles se detém no único detalhe mais capaz de colocar um desenvolvedor em apuros: a notificação CONSUMPTION_REQUEST não traz nenhuma indicação sobre consentimento.
Isso surpreende as pessoas. É razoável supor que, se a Apple está solicitando dados, a Apple já cuidou da permissão para compartilhá-los. Não é o caso. A posição da Apple é o oposto: os dados que você enviaria são dados que você coletou do seu usuário, então a responsabilidade de ter permissão para compartilhá-los é sua. A Apple simplesmente exige que você ateste isso definindo customerConsented como true, e rejeita o envio se você não o fizer. Esse é o cerne dos requisitos de consentimento da Apple Consumption API.
Portanto, o campo não é uma caixa de seleção que você marca só para agradar a API. É uma atestação legal. Definir esse valor como true quando você não obteve consentimento de fato não é um detalhe técnico — é uma falha de conformidade esperando para ser descoberta.
Por que o consentimento é responsabilidade do desenvolvedor
Pense em quem detém o quê. A Apple administra a loja e a decisão sobre o reembolso. Mas o tempo de conta, o tempo de uso, o status de entrega e o histórico de uso que você colocaria em um ConsumptionRequest são registros seus sobre seu usuário, coletados sob a sua política de privacidade. Ao enviá-los para a Apple, você está divulgando dados pessoais a terceiros.
De acordo com os regimes de privacidade aplicáveis, essa divulgação precisa de uma base legal adequada. A documentação específica da API da Apple exige consentimento válido antes de compartilhar os dados pessoais por meio da Consumption Information API, embora os requisitos legais precisos dependam da jurisdição do usuário. A Apple afirma que os desenvolvedores são responsáveis por determinar a conformidade com as leis aplicáveis.
É por isso que o ônus recai sobre o desenvolvedor, e por que "a Apple pediu" não é uma defesa se um órgão regulador questionar como você tinha permissão para compartilhar os dados de um usuário. Em um fluxo de consentimento para reembolso da Apple, o importante é que o consentimento exista antes de os dados serem compartilhados.
Onde o consentimento precisa ser coletado
Esta é a parte que importa na prática: o consentimento precisa ser coletado no seu app, antes do fluxo de reembolso — e não inferido no servidor quando a notificação chega.
No momento em que um CONSUMPTION_REQUEST chega ao seu servidor, já é tarde demais para perguntar. Não há usuário presente, e restam cerca de 12 horas no relógio. O consentimento já precisa existir, capturado anteriormente como parte de como seu app faz o onboarding e divulga suas práticas de dados, para que, quando a solicitação chegar, você possa definir customerConsented como true com veracidade.
Na prática, isso significa que os termos, a política de privacidade e o fluxo de compra ou onboarding do seu app precisam divulgar claramente que dados de consumo podem ser compartilhados com a Apple para processar solicitações de reembolso, e obter uma concordância que você consiga sustentar. Consentimento vago, agrupado ou escondido é exatamente o que a legislação de privacidade moderna foi feita para rejeitar. Isso também é central para a privacidade em reembolsos da Apple, já que a Apple exige especificamente consentimento válido antes de os dados de consumo serem compartilhados.
Como isso se relaciona com GDPR e DPDP
Se algum dos seus usuários estiver na UE/Reino Unido (GDPR), Índia (DPDP), Califórnia (CCPA) ou em uma lista crescente de outras jurisdições, o compartilhamento de dados de consumo se enquadra diretamente nessas estruturas legais. Alguns princípios que se aplicam de forma consistente:
O consentimento precisa ser informado e específico. O usuário deve entender que dados relacionados a reembolso podem ser compartilhados com a Apple, e não apenas concordar com um bloco de texto jurídico.
O consentimento deve ser separável. Agrupar o consentimento para compartilhamento de dados com termos não relacionados em uma única caixa de seleção obrigatória é um anti-padrão reconhecido.
Você precisa conseguir comprová-lo. Se questionado, o argumento "tínhamos consentimento" precisa ser comprovável, o que significa que a captura do seu consentimento precisa ser registrada, não presumida.
Sua política de privacidade realmente precisa dizer isso. Se sua política não divulgar o compartilhamento de dados de consumo com a Apple para fins de reembolso, seu consentimento para isso fica em terreno instável.
Para equipes que estão revisando os requisitos de GDPR para dados de consumo, o ponto importante é que a própria Apple exige consentimento válido para essa API, embora os requisitos legais exatos e a base jurídica possam variar por jurisdição. A orientação da Apple diz que o consentimento deve ser dado livremente, específico, informado e inequívoco, e que os desenvolvedores são responsáveis por determinar a conformidade de acordo com a lei aplicável.
Para apps voltados à Índia, o consentimento para reembolso sob a DPDP também deve ser revisado à luz dos requisitos aplicáveis, em vez de presumir que a exigência da API da Apple, por si só, resolve todas as obrigações de privacidade.
Isto não é aconselhamento jurídico, e os detalhes das suas obrigações dependem dos seus usuários e jurisdições, mas a direção é clara: o consentimento por trás do campo customerConsented precisa ser real, informado e documentado.
Como é uma configuração em conformidade
Juntando tudo, uma configuração defensável tem três partes funcionando antes de qualquer reembolso:
Divulgação: sua política de privacidade e seus termos declaram claramente que dados de consumo/uso podem ser compartilhados com a Apple para processar solicitações de reembolso.
Captura: seu app obtém o consentimento informado e separável do usuário, e o registra.
Atestação: quando um CONSUMPTION_REQUEST chega, sua resposta reflete esse consentimento registrado de forma honesta no campo customerConsented.
O RefundSensor foi construído com essa cadeia em mente. A plataforma cuida da resposta de reembolso e da atestação de customerConsented como parte do fluxo automatizado, e publicamos um conjunto completo de documentos de conformidade — política de privacidade, termos, DPA, políticas de cookies e de reembolso alinhados a GDPR, DPDP e CCPA — para que o lado da divulgação e do processamento seja coberto, e não improvisado. A captura de consentimento no seu app continua sendo sua decisão, como deve ser, mas tudo o que vem depois disso é tratado.
Para equipes avaliando software de conformidade para reembolsos ou uma ferramenta de automação de reembolso da Apple, essa separação é importante: a automação pode cuidar da resposta técnica, mas não deve inventar ou presumir o consentimento do cliente.
Os erros mais comuns
Definir customerConsented como true por padrão. A forma mais rápida de transformar um recurso de reembolso em um passivo de conformidade.
Presumir que a Apple cuida do consentimento. Não cuida, e diz isso claramente.
Tentar coletar consentimento no momento do reembolso. Não há usuário nem tempo disponível para isso — o consentimento precisa existir antecipadamente.
Não divulgar nada na política de privacidade. Se a política é omissa sobre o compartilhamento de dados com a Apple, o consentimento por trás disso fica difícil de defender.
Agrupar tudo em uma única caixa de seleção obrigatória. O consentimento separável é o padrão; agrupar o compromete.
Usar o App Tracking Transparency como mecanismo de consentimento. A documentação da Apple afirma explicitamente que o consentimento necessário para a Consumption Information API é separado do App Tracking Transparency.
Fontes oficiais
Tanto os requisitos quanto as regulamentações mudam, então trate estas fontes como a autoridade final:
Automação de reembolso que respeita a cadeia de consentimento. O RefundSensor cuida da resposta de reembolso e da atestação de customerConsented como parte de um fluxo automatizado, apoiado por um conjunto completo de documentos de conformidade alinhados a GDPR/DPDP/CCPA. Para equipes em busca de automação de reembolso para apps, a cadeia de consentimento continua sendo parte da implementação. Comece grátis
Perguntas frequentes
Sim. Você precisa ter consentimento válido e informado, além de definir customerConsented como true. A Apple exige essa atestação e rejeita respostas sem ela, e você é legalmente responsável por ter obtido o consentimento.
No seu app, antes do fluxo de reembolso. Quando um CONSUMPTION_REQUEST chega ao seu servidor, não há usuário presente e restam cerca de 12 horas no relógio, então o consentimento já precisa existir e estar registrado.
Não. A notificação não traz nenhuma indicação de consentimento. A Apple espera que seu app já o tenha coletado, e espera que você o ateste na sua resposta.
Pode estar, se a cadeia de consentimento for feita corretamente: divulgação clara na sua política, consentimento informado e separável capturado no app e registrado, e atestação honesta na resposta da API. A automação cuida da resposta; a captura do consentimento no app é sua responsabilidade.
A Apple não processará os dados de consumo, então você perde a chance de influenciar essa decisão de reembolso. O caminho correto é obter consentimento real antecipadamente, em vez de enviar dados sem ele.
