Vender assinaturas dentro do app
Dentro do app instalado da loja, quem cobra é a loja, não o seu gateway. Este guia explica como ligar cada plano do seu app a um produto da App Store ou do Google Play, e por que o botão de assinar às vezes não aparece.
Por que dentro do app é diferente
No site publicado, a assinatura passa pelo gateway que você conectou (Stripe, Mercado Pago, Pagar.me). Dentro do app instalado da loja, isso é violação de política das duas lojas para conteúdo digital, e a punição é a remoção do app.
Por isso a plataforma nunca cai no gateway dentro do app. Ou existe compra pela loja, configurada e pronta, ou o app mostra o estado mudo. Um botão que abre a loja e falha é pior que botão nenhum.
A loja fica com uma comissão sobre cada venda, e os dois programas têm faixas diferentes conforme o faturamento e o tempo de assinatura. Confira nas páginas oficiais da Apple e do Google Play antes de definir seu preço.
O que precisa estar pronto
- o app nativo publicado ou pelo menos configurado na aba Aplicativo;
- o recurso de compra no app ativado no passo Recursos;
- os planos do seu app já cadastrados (é o que a aba Dados chama de planos, e é o que o app vende);
- as credenciais de verificação: no iOS, a chave de In-App Purchase; no Android, a conta de serviço do Play;
- cada plano ligado a um produto da loja, que é o assunto do resto deste guia.
Ligar cada plano a um produto da loja
Na aba Aplicativo, a seção de assinaturas mostra os planos do seu app lado a lado com o que a loja realmente tem, uma loja de cada vez (Google Play e App Store são catálogos separados: estar ligado numa não diz nada sobre a outra). Cada plano aparece com um estado:
| Estado | O que quer dizer |
|---|---|
| sem produto | o plano não está ligado a nada na loja |
| não encontrado na loja | há um identificador salvo aqui, mas a loja não o reconhece |
| criado, mas não vendável | o produto existe e ainda não pode ser comprado (rascunho, sem preço, sem revisão) |
| vendável | pronto: o app pode vender esse plano |
Só vendável libera a compra. É uma distinção que importa: no Google, a API responde com sucesso enquanto o plano-base ainda está em rascunho, e a compra falha no aparelho com "item indisponível".
No Google Play
Duas ações, e a escolha depende de onde você começou:
- Criar na loja: a plataforma cria o produto e ativa o plano-base para você. Antes de confirmar, confira o identificador que aparece em "Será criado como";
- Vincular a um produto existente: se você já montou o catálogo no Play Console, informe o identificador do produto e o do plano-base. A plataforma confere e mostra as diferenças entre o seu plano e o que está na loja (preço, período), sem decidir por você.
Na App Store
Aqui a plataforma não cria a assinatura, e não é limitação nossa: a Apple exige que a primeira assinatura seja enviada junto de uma versão do app, dentro de um grupo de assinaturas, com preço por território e revisão.
O caminho é criar no App Store Connect e depois vincular aqui:
- no App Store Connect, abra o app e vá em Monetization → Subscriptions;
- crie um grupo de assinaturas (o grupo é o que permite ao cliente trocar de plano dentro dele);
- crie a assinatura, com identificador, duração e preço;
- preencha tudo até o status ficar Ready to Submit;
- na página da versão do app, na seção de compras dentro do app, marque a assinatura e envie as duas juntas para revisão;
- depois de aprovada, volte à aba Aplicativo e vincule o plano ao identificador.
Isso vale para a primeira assinatura. Depois que existe uma aprovada no grupo, as próximas podem ser enviadas sozinhas.
Identificadores são permanentes
Nas duas lojas, o identificador de um produto não pode ser renomeado nem reaproveitado depois de criado. No Google Play nem é possível apagar assinatura, plano-base ou oferta: eles ficam para sempre no relatório.
Por isso a tela avisa antes de criar, e por isso ela se recusa a inventar uma variação quando o identificador já existe: nesse caso o certo é vincular, não criar outro.
A chave de In-App Purchase (iOS)
A verificação de uma compra no iOS usa uma chave diferente da que envia os builds. Ela é gerada em Users and Access → Integrations → In-App Purchase e conectada na própria seção de assinaturas.
Sem ela, a loja cobraria no aparelho e a verificação recusaria depois: dinheiro movido, nada liberado, e o cliente com um recibo na mão. É por isso que, sem essa chave, o app fica mudo em vez de vender.
O botão de assinar não aparece: por quê
O servidor decide isso em um lugar só, e sempre para estreitar, nunca para alargar. Cada motivo é uma configuração faltando, e todos têm conserto:
| O que está faltando | O que fazer |
|---|---|
| o cliente já tem assinatura ativa | nada: cobrar de novo por outro caminho geraria uma segunda cobrança |
| o app não tem versão nativa | configure a aba Aplicativo |
| a compra no app não está ativada | ative o recurso no passo Recursos |
| a plataforma daquele aparelho não está ligada | ative iOS ou Android no passo Lojas |
| falta a credencial de verificação | conecte a chave de In-App Purchase (iOS) ou a conta de serviço (Android) |
| o plano não existe | confira os planos do app na aba Dados |
| o catálogo não está pronto | ligue o plano a um produto vendável na loja |
Cancelamento e reembolso
Quem cancela uma assinatura de loja é o cliente, na loja, não no seu app: é assim nas duas e não há como mudar. Renovações, cancelamentos e reembolsos chegam até nós por notificação da própria loja, e o acesso do cliente é ajustado a partir disso.
Uma consequência prática no Android: uma compra que o app não confirma é reembolsada automaticamente pelo Google em três dias. A confirmação é feita pela plataforma assim que a verificação passa, então o caminho normal já cuida disso; se um cliente relatar reembolso sem motivo, é aí que se olha primeiro.
O aparelho nunca decide
Vale saber, porque explica várias respostas do sistema: o identificador de transação que o app devolve é uma alegação, não uma prova. Tudo que move dinheiro (qual produto, de quem, até quando, ainda ativo) é perguntado à loja com a credencial do dono do app.
É o que impede que um recibo forjado libere acesso pago, e também o motivo de uma compra levar alguns segundos entre a loja aceitar e o app liberar.