BillingMeld: por que o servidor deve verificar a compra em vez do aplicativo

Comprar dentro de um aplicativo móvel geralmente parece simples apenas para o usuário. Ele clica no botão, confirma o pagamento, acessa a função ou assinatura — e espera que tudo continue a funcionar automaticamente.

Para o desenvolvedor, por trás deste botão começa um processo muito mais complexo. É preciso confirmar a compra em si, considerar renovações, encerramento de assinatura, reembolsos, feedbacks de operações, troca de dispositivo e diferenças entre as lojas Apple e Google.

O principal problema surge quando o servidor passa a considerar o aplicativo cliente como a fonte da verdade.

Se o aplicativo informa: "Compra realizada", o servidor concede acesso e continua a se basear no estado obtido uma vez. Mas o ciclo de vida da compra não termina aí.

A assinatura pode ser renovada, a renovação automática pode ser desativada, o pagamento pode ser reembolsado, e a operação pode ser revertida pela loja.

Por isso, no BillingMeld, a compra é confirmada não pelo aplicativo, mas pelo servidor.

Cliente informa, mas não decide

Na arquitetura do BillingMeld, o aplicativo móvel não é a principal fonte de informações sobre a compra.

O cliente pode fornecer dados sobre a operação concluída, mas isso é apenas uma base para verificação. A decisão final é tomada pela parte de servidor do BillingMeld, que verifica as informações através da infraestrutura da Apple ou Google.

Essa é uma diferença fundamental.

O aplicativo no telefone pode trabalhar com um estado antigo, não receber a alteração em tempo hábil ou transmitir dados que já não correspondem ao estado atual da compra.

Além disso, o cliente não deve ter a capacidade de decidir sozinho se o usuário deve ter acesso pago.

O BillingMeld verifica, por exemplo:

• se a compra realmente existe;

• se ela se refere ao aplicativo e produto corretos;

• se o período pago está ativo;

• se houve uma nova renovação;

• se a renovação automática foi desativada;

• se houve reembolso;

• se a operação foi revogada;

• se o período pago ainda está vigente.

Assim, a mensagem do cliente passa a não ser uma prova definitiva da compra, mas um motivo para verificar seu estado real.

Uma fonte única da verdade para servidores

Serviços conectados não precisam implementar uma integração completa com Apple e Google ao mesmo tempo.

Eles consultam o BillingMeld e recebem um estado normalizado da compra.

Por exemplo: acesso ativo, período pago expirou, renovação confirmada, renovação automática desativada ou compra revogada.

Isso permite separar claramente as responsabilidades.

A Apple e o Google são as fontes do estado da operação na loja. O BillingMeld verifica esses dados, os padroniza e mantém seu estado atualizado. O produto final decide sobre o acesso baseado no status do BillingMeld.

Para os servidores de produtos, isso significa um contrato único, ao invés de múltiplas integrações independentes.

Não é necessário implementar regras do App Store e Google Play separadamente em cada serviço, nem ajustar diferentes formatos, eventos e status em uma lógica comum.

Por que não devemos confiar totalmente no cliente

O aplicativo no dispositivo do usuário funciona na sua máquina.

Ele pode ser fechado, reiniciado, restaurado de um backup, atualizado ou executado em outro dispositivo. Pode trabalhar por algum tempo com informações antigas ou simplesmente não receber o evento que ocorreu após a compra inicial.

Sem qualquer intervenção do usuário, isso torna o cliente uma fonte inadequada para o estado final da assinatura.

Por exemplo, o usuário faz uma assinatura e ganha acesso. Depois, pode haver um reembolso ou a operação pode ser revogada pela loja.

Se o servidor só conhece a mensagem inicial do cliente, continuará considerando a compra como válida.

Outra situação: o usuário desativa a renovação automática. Nesse caso, o período já pago ainda deve permanecer ativo até seu final.

Se o sistema opera apenas com um status simples de "assinatura presente/não presente", ele pode acabar fechando o acesso precocemente ou mantendo-o após o término de direito.

O BillingMeld é construído com uma lógica diferente: o cliente não confirma seus direitos; ele informa um evento, e o servidor determina o estado real da compra.

Compra não é um evento único

Um erro comum na arquitetura de billing é tratar uma compra como um evento isolado.

Na verdade, ela possui um ciclo de vida.

Primeiro, ocorre a operação de compra. Depois, ela é confirmada pela loja. Para uma assinatura, começa o período pago. Pode-se fazer uma renovação subsequente.

O usuário pode desativar a renovação automática, ainda assim usando a assinatura até o fim do período pago.

Pode haver uma tentativa de novo pagamento na renovação.

Reembolsos podem ser feitos.

Em alguns casos, a compra pode ser revogada.

Portanto, uma simples afirmação de "esta compra existiu no passado" não é suficiente.

É fundamental que o servidor saiba o que está acontecendo com ela no momento.

Reembolso não passa despercebido

Essa necessidade de arquitetura server-side se torna evidente especialmente em caso de reembolsos e revogações.

A compra inicial pode ter sido totalmente correta. O usuário realmente pagou pelo produto e obteve acesso.

Mas, posteriormente, o estado da operação mudou.

Se o BillingMeld recebe uma atualização, ele ajusta seu próprio estado de compra e, se necessário, verifica os dados na loja novamente.

Após isso, o serviço conectado trabalha com o novo status.

Assim, o aplicativo não continua a confiar na afirmação de sucesso feita semanas ou meses atrás pelo cliente.

Se a loja deixar de reconhecer o direito correspondente, o BillingMeld reflete isso em seu estado.

Cancelar assinatura e término de acesso não são a mesma coisa

Aqui há uma distinção importante.

Se o usuário desativa a renovação automática, isso geralmente não significa que o acesso deve ser encerrado imediatamente.

O período pago atual pode continuar ativo.

Nesse caso, o BillingMeld deve armazenar a informação de que a renovação foi desativada, mas também deve entender a data de fim do período pago atual.

E somente após seu término o acesso deixa de ser considerado ativo, se não houver uma nova confirmação de renovação.

Esse é um exemplo de porque um simples valor booleano subscription = true não é suficiente para um billing adequado.

O estado da assinatura sempre envolve tempo e eventos do ciclo de vida.

Renovações também demandam verificações separadas

Uma assinatura não termina na primeira compra.

O servidor precisa detectar se houve uma renovação subsequente e se o próximo período pago foi realmente confirmado pela loja.

O BillingMeld acompanha essas mudanças e atualiza o estado da assinatura.

Se a renovação for confirmada, o direito de acesso continua.

Se o pagamento não ocorrer ou a loja não confirmar o próximo período, o sistema não deve simplesmente estender o acesso por suposição.

Para o usuário, o acesso parece válido enquanto a assinatura estiver realmente ativa.

Para o desenvolvedor, isso significa que a lógica de renovação pode ser compartilhada, sem precisar republicá-la em cada app.

Um cenário comum

O usuário faz uma assinatura pelo aplicativo móvel.

O cliente obtém informações da compra e passa os dados ao BillingMeld. Mas essa mensagem ainda não é uma confirmação definitiva.

O BillingMeld verifica a operação no respectivo loja.

Se a App Store ou Google Play confirma a compra e seu estado está de acordo com as regras do produto, o BillingMeld registra o direito ativo.

Depois, o serviço conectado fornece as funcionalidades pagas ao usuário.

O estado continua vigente independentemente da mensagem original do cliente.

Se a assinatura for renovada, o BillingMeld atualiza o período pago.

Se o usuário desativar a renovação automática, o período atual continua até seu fim.

Se a operação for reembolsada ou revogada, o estado muda novamente.

Nessa arquitetura, o aplicativo não mantém uma "verdade" própria sobre a compra. Ele trabalha com o estado confirmado e armazenado pelo BillingMeld.

O que acontece na troca de dispositivo

O modelo server-side é especialmente útil quando o usuário troca de telefone ou reinstala o aplicativo.

O direito de compra não deve depender de o dispositivo específico ter visto uma transação bem-sucedida um dia.

Por outro lado, reinstalar o aplicativo não deve apagar o direito confirmado do usuário.

Se o estado da compra estiver no servidor e ligado a uma operação confirmada na loja, o novo dispositivo pode obter a situação atual através do servidor.

Esse é mais um motivo para não guardar toda a lógica de acesso apenas dentro do cliente móvel.

O que isso oferece aos desenvolvedores

Para equipes que lançam vários aplicativos ou trabalham com iOS e Android simultaneamente, o billing rapidamente vira uma infraestrutura à parte.

É preciso considerar:

• formatos diferentes de Apple e Google;

• confirmação da compra inicial;

• renovações de assinatura;

• fim do período pago;

• desativação da renovação automática;

• reembolsos;

• revogação de operações;

• reinstalação do aplicativo;

• troca de dispositivo;

• recuperação de compras;

• alterações de estado sem intervenção do cliente.

O BillingMeld extrai toda essa lógica para uma camada especializada.

Os servidores de produto trabalham com um contrato único e não precisam interpretar as particularidades de cada loja individualmente.

Isso reduz código duplicado e, mais importante, diminui o risco de diferentes aplicativos interpretarem de formas distintas o mesmo cenário de pagamento.

O que não é mais importante: o recibo e o evento inicial

O que mais me chamou atenção nessa arquitetura foi a mudança do foco de verificar uma compra específica para monitorar o estado atual.

O fato do pagamento bem-sucedido uma vez não responde mais à questão principal do produto:

o usuário tem direito à função paga agora?

A compra inicial pode ter sido bem-sucedida, mas o período já pode ter terminado.

A assinatura pode ter a renovação desativada, mas o período pago ainda está ativo.

Pode haver uma renovação confirmada.

Pode haver um reembolso realizado.

A loja pode revogar a operação.

Por isso, o principal não é mais o recibo ou a resposta inicial do cliente, mas o direito atual do usuário, baseado no estado confirmado da compra.

É esse estado que o BillingMeld fornece para os outros serviços.

BillingMeld como limite entre lojas e produtos

Como resultado, surge uma fronteira arquitetônica bastante clara.

De um lado, estão a App Store e Google Play com seus formatos, eventos, regras e ciclos de vida das compras.

De outro, os aplicativos e serviços internos que, na maioria dos casos, precisam de uma resposta mais simples: quais direitos o usuário tem agora.

Entre eles está o BillingMeld.

Ele aceita dados das lojas, verifica, os padroniza e fornece a infraestrutura uma consequência já normalizada.

Assim, os produtos não precisam conhecer todas as particularidades de cada plataforma de pagamento.

Por que isso é importante para o usuário

Para o usuário, uma arquitetura de billing correta idealmente deve ser invisível.

Se a compra está confirmada e o período pago ativo, o acesso deve estar disponível.

Se o usuário desativou a renovação automática, o período já pago não deve terminar mais cedo.

Se uma nova renovação bem-sucedida acontece, o acesso deve continuar.

Se a loja confirma reembolso ou revogação, o sistema deve refletir corretamente a mudança de direito.

Ao trocar de dispositivo ou reinstalar o aplicativo, o usuário não precisa provar manualmente para toda a infraestrutura que a compra realmente ocorre.

O resultado é uma regra simples:

o cliente informa a compra, a loja é uma fonte externa de seu estado, o BillingMeld verifica e normaliza esse estado, e os demais serviços tomam a decisão baseada nos dados confirmados pelo BillingMeld.

Por isso, o BillingMeld não é apenas mais um módulo de pagamento.

Ele é uma camada de confiança server-side entre o aplicativo móvel, as lojas da Apple e Google, e os produtos que precisam saber exatamente quais direitos pagos estão atualmente ativos para o usuário.

Mais sobre o projeto em: billingmeld.de.