Um reembolso de Family Sharing reverte um pagamento, mas pode deixar outras cinco pessoas ainda usando seu app, e só o seu servidor pode cortar o acesso delas

Uma compra em um grupo de Family Sharing pode entregar seu app a seis pessoas. Quem pagou é uma delas. As outras cinco nunca abriram a carteira, e a Apple ainda espera que seu app funcione para todas elas. Esse é o acordo em que você entra no momento em que ativa o Family Sharing para uma compra dentro do app. É também por isso que um reembolso de Family Sharing é um bicho diferente de um comum. Quando o comprador recebe o dinheiro de volta, a venda se reverte para uma conta, mas o acesso que você concedeu a até cinco outras pessoas não se desliga sozinho. Seu servidor tem que fazer isso, e se ele foi escrito para observar apenas o comprador, não vai fazer.

Aqui está o quadro completo em um só lugar. Isto percorre como a Apple marca uma compra compartilhada, o único campo que diferencia o comprador da família, exatamente quando a Apple envia um REVOKE e como lê-lo, o detalhe discreto que separa um reembolso de alguém apenas saindo da família, e quanto um reembolso compartilhado realmente custa depois que você conta o processamento que já gastou com pessoas que nunca pagaram a você.

O que o Family Sharing distribui, e para quantas pessoas

Ative o Family Sharing para um produto e você muda quem é o seu cliente pagante. Um grupo familiar na Apple pode ter até seis pessoas, um organizador e até cinco membros. Quando qualquer pessoa do grupo compra um produto compartilhável com a família, todos no grupo passam a ter acesso a ele. Eles não pagam. Não aparecem na sua receita. Simplesmente surgem no seu app com um direito válido, porque a Apple emite para cada um deles uma transação que aponta para a mesma compra.

Apenas dois tipos de produto são compartilháveis, e consumíveis não são um deles

O Family Sharing cobre exatamente dois tipos de compra dentro do app: não consumíveis e assinaturas de renovação automática. Consumíveis, os produtos de moedas e créditos, nunca são compartilhados, e é por isso que um familiar nunca aciona um CONSUMPTION_REQUEST nem aparece no seu relatório de consumo. Se o seu app vende apenas consumíveis, os reembolsos de Family Sharing não são problema seu. Se você vende um desbloqueio vitalício ou um plano recorrente, são.

O campo que diferencia um comprador de um beneficiário

Cada transação que a Apple emite carrega um inAppOwnershipType. Ele tem dois valores. PURCHASED significa que esta conta pagou pelo produto e pode gerenciá-lo, incluindo cancelá-lo ou solicitar um reembolso. FAMILY_SHARED significa que esta conta é de um familiar que tem acesso por meio da compra de outra pessoa. Ambos dão à pessoa o direito de usar o seu produto. Apenas um deles pagou. O campo está na transação do StoreKit, no recibo e na App Store Server API, então você pode lê-lo onde já verifica os direitos.

Como um reembolso de Family Sharing chega ao seu servidor

Um reembolso em uma compra compartilhada começa do mesmo jeito que qualquer reembolso da Apple. O comprador, a única pessoa que pode, pede à Apple o dinheiro de volta. A Apple decide. Se a Apple conceder, a compra do comprador é revertida e a Apple envia ao seu servidor uma App Store Server Notification REVOKE. Tanto a V1 quanto a V2 da notificação a carregam. O REVOKE é o seu único sinal de que o direito por trás dele, e cada cópia compartilhada com a família, agora é inválido.

Não revogue uma transação, releia todo o histórico

A orientação da Apple sobre um REVOKE é direta: não o trate como um único interruptor. Quando você receber um, percorra todo o histórico de transações do cliente e reconstrua os direitos dele do zero, porque uma pessoa pode ter mais de uma transação que concede o mesmo produto ou um produto diferente. Revogue apenas a transação nomeada na notificação e você pode tanto deixar um familiar reembolsado com acesso ativo quanto cortar alguém que ainda tem um segundo direito válido. Restabeleça o quadro completo toda vez.

O único detalhe que separa um reembolso de um rompimento familiar

Aqui está a armadilha que custa uma tarde de depuração às equipes. Um REVOKE pode significar duas coisas muito diferentes para uma transação FAMILY_SHARED, e a maneira de diferenciá-las é um campo que às vezes simplesmente está ausente. Quando o comprador recebe um reembolso, a transação FAMILY_SHARED vem com um revocationDate. Quando um familiar apenas sai do grupo, o mesmo tipo de REVOKE chega sem nenhum revocationDate. Os engenheiros de comércio da Apple disseram isso diretamente nos fóruns de desenvolvedores. De qualquer forma você retira o acesso, mas apenas o que tem data é um reembolso, e apenas o reembolso é o que também reverteu um pagamento.

Quanto um reembolso compartilhado realmente custa a você

Acompanhe o dinheiro, porque é aqui que o Family Sharing silenciosamente muda a conta. Um reembolso normal reverte uma venda. A Apple devolve o preço ao comprador e devolve a sua comissão, então o lado da loja fica quase empatado. O que nunca volta é o que você já gastou para entregar o produto. Com o Family Sharing, você não gastou isso uma vez. Você gastou para até seis pessoas. O comprador e até cinco familiares cada um usou o seu processamento, chamou as suas APIs, encheu o seu armazenamento e puxou quaisquer repasses que você financia, tudo com base em um único pagamento.

Agora o comprador pede reembolso. O único pagamento se reverte. O acesso de cada familiar deveria terminar no mesmo momento, porque a coisa que justificava atendê-los, uma compra paga, se foi. Se o seu servidor revogar apenas a transação PURCHASED e deixar as FAMILY_SHARED ativas, até cinco pessoas continuam com os seus recursos pagos de graça, e você continua pagando para atendê-las, sem nada restante no sistema para cobrar. Isso não é um erro de arredondamento. É cinco vezes o custo de entrega da venda que você acabou de devolver.

Assinaturas tornam o vazamento recorrente

Para um não consumível, um familiar não revogado é uma perda única que corre até você perceber. Para uma assinatura de renovação automática é pior, porque o direito já era recorrente. Um reembolso no pedido da assinatura deveria encerrar o compartilhamento para todo o grupo, mas um familiar deixado ativo mantém o nível pago a cada período de cobrança em que você deixa de encerrá-lo. A correção é a mesma, restabelecer os direitos a partir do histórico completo a cada REVOKE, mas o custo de pular isso se acumula.

Fazendo certo, e testando antes que um reembolso real o faça

Não há nada exótico para construir aqui. Todo o trabalho é vincular o acesso ao direito, não ao comprador, e reconstruir esse acesso a cada REVOKE.

• Armazene o acesso vinculado à transação e ao seu inAppOwnershipType, não a uma única conta de comprador, para que uma transação FAMILY_SHARED conceda acesso por si só e possa ser revogada por si só.
• Em qualquer notificação REVOKE, releia todo o histórico de transações do cliente e recalcule os direitos, em vez de desligar a única transação nomeada.
• Trate uma transação FAMILY_SHARED com um revocationDate como um reembolso e encerre o acesso daquele familiar. Trate uma sem um revocationDate como uma saída da família e encerre também.
• Não coloque uma compra compartilhada recém-feita em serviço às pressas. A Apple a retém por cerca de uma hora para que o comprador possa desistir, então honre a transação que a Apple realmente emite em vez de conceder no toque de compra.
• Ensaie. A ferramenta Testing Family Sharing da Apple permite simular uma transação compartilhada, e um reembolso de sandbox dispara o mesmo REVOKE que o seu servidor de produção receberá.

Faça isso e um reembolso de Family Sharing se torna um não evento. O comprador recebe o dinheiro, o grupo inteiro perde o acesso no mesmo instante, e você para de pagar para atender pessoas que nunca estavam pagando a você.