Contabilidade para Desenvolvedores de Extensões Chrome: Reconciliando Repasses Depois que o Google Encerrou os Pagamentos In-App

Abra hoje o painel de desenvolvedor da Chrome Web Store e você vai notar algo faltando: uma aba de "pagamentos". O Google encerrou seu próprio sistema de pagamento in-app para extensões lá em 2021, e ele nunca voltou. Se você quer cobrar por uma extensão Chrome em 2026, está por conta própria para cuidar de cobrança, assinaturas, reembolsos, coleta de impostos e — a parte que quase ninguém planeja — reconciliar o que realmente caiu na sua conta bancária com o que você vendeu.

Essa última parte trava mais desenvolvedores indie do que a precificação jamais travou. Uma operação de um único desenvolvedor rodando três ou quatro extensões via Stripe, Paddle ou um wrapper como o ExtensionPay acaba com depósitos de repasse que não mapeiam claramente para nenhum produto específico, picos de reembolso que surgem do nada depois de um atraso de revisão da Chrome Web Store, e um saldo bancário que nunca bate exatamente com o que o painel de vendas diz que deveria ser. Nada disso é um bug no seu negócio. É o resultado previsível de costurar junto uma stack de pagamentos que o Google costumava rodar para você.

Veja como construir uma contabilidade que sobrevive a isso.

Por Que o Google Saiu do Negócio de Pagamentos​

O Chrome Web Store Payments foi lançado no início dos anos 2010, quando não havia muitas boas opções para um desenvolvedor solo cobrar por uma extensão de navegador. Por volta de 2021, o Stripe, o Braintree e uma onda de serviços de "comerciante de registro" já haviam amadurecido o suficiente para que o Google decidisse que não precisava mais rodar seu próprio sistema de checkout, chave de licença e repasse. Ele descontinuou o Chrome Web Store Payments e empurrou toda extensão paga a escolher entre se tornar gratuita ou migrar para um processador terceirizado.

O resultado prático para os desenvolvedores: todo dólar que uma extensão ganha agora passa por uma stack de pagamentos que você mesmo montou, e todo problema de reconciliação que essa stack cria é seu para resolver. Não existe mais um único "relatório de repasse da Chrome Web Store" — existe o que seu processador te dá, mais o que as próprias análises de listagem da Chrome Web Store mostram, mais seu extrato bancário, e essas três coisas raramente batem à primeira vista.

Processador de Pagamento ou Comerciante de Registro — Escolha Um Por Extensão​

Antes mesmo de a reconciliação começar, você precisa saber de que lado da transação está legalmente, porque isso muda o que entra na sua contabilidade.

Um processador de pagamento (o Stripe diretamente, ou um wrapper construído em cima dele como o ExtensionPay) faz de você o vendedor. Você recebe o dinheiro, é o comerciante de registro para fins fiscais, e é responsável por descobrir as obrigações de imposto sobre vendas e IVA em cada jurisdição onde um cliente mora. As taxas são menores — a base do Stripe é 2,9% + $0,30 por cobrança, e um wrapper como o ExtensionPay tipicamente adiciona sua própria fatia em cima — mas o peso da conformidade fica com você.

Um Comerciante de Registro (Paddle, Lemon Squeezy, Fungies e similares) se torna legalmente o vendedor no seu lugar. Eles coletam o IVA ou GST, apresentam as declarações em mais de 140 países que hoje exigem isso para bens digitais, lidam com chargebacks e te pagam o lucro líquido. Você abre mão de 4–8% da receita em vez de ~3%, mas uma categoria inteira de trabalho contábil e fiscal desaparece. Para uma análise completa das trocas envolvidas e como calcular quando a mudança compensa, veja nosso guia de Comerciante de Registro.

Para a maioria dos desenvolvedores solo de extensões abaixo de alguns milhares de dólares por mês, o extra de 3–5% que um Comerciante de Registro cobra é um seguro barato contra ter que se registrar para IVA em uma dúzia de países manualmente. Assim que você estiver rodando receita recorrente real em várias extensões, refaça a comparação — a matemática muda conforme o volume cresce.

Seja qual for sua escolha, anote-a. Sua contabilidade precisa de uma resposta clara para "quem é o vendedor legal de registro desta extensão", porque isso determina se o passivo de imposto sobre vendas aparece no seu balanço patrimonial.

O Problema de Reconciliação É Estrutural, Não um Erro​

Aqui está a parte que pega os desenvolvedores de surpresa: mesmo com um processador corretamente configurado, o repasse que você recebe quase nunca é igual à receita que você gerou naquele período. Três coisas quebram a correspondência 1:1:

• Repasses em lote. O Stripe e a maioria dos Comerciantes de Registro pagam em um cronograma contínuo (geralmente 2–7 dias após a cobrança, às vezes semanalmente), então um repasse que cai no dia 5 do mês contém vendas dos últimos dias do mês anterior. Se você registra os repasses como receita no dia em que caem na sua conta, está atribuindo incorretamente a receita ao período errado todo santo mês.
• Várias extensões, uma única conta de processador. Se você roda várias extensões pela mesma conta do Stripe ou Paddle — comum para desenvolvedores que lançam um punhado de ferramentas pequenas em vez de um produto principal — o repasse é uma única quantia acumulada cobrindo todas elas. Sem marcação por extensão (os campos de metadados do Stripe, ou Produtos/Preços separados por extensão), você não consegue saber qual extensão de fato gerou a receita, o que torna impossível saber qual delas vale o seu tempo de manutenção.
• Taxas, reembolsos e conversão de moeda já descontados antes de você ver o número. O valor do repasse já é líquido de taxas de processamento, quaisquer reembolsos emitidos naquele período, e conversão de moeda se você vende internacionalmente. Registrar o repasse como receita bruta infla seu faturamento e esconde sua margem real.

A solução é uma conciliação de três vias, feita mensalmente no mínimo:

1. Relatório de vendas do processador — transações brutas, discriminadas por produto/extensão se sua conta suportar, antes de taxas e reembolsos serem descontados.
2. Relatório de repasse do processador — os valores líquidos que efetivamente foram para sua conta bancária, com taxas e reembolsos discriminados como itens separados.
3. Extrato bancário — os depósitos que realmente foram compensados.

Concilie os três. O relatório de vendas te diz o que você ganhou (receita, reconhecida quando o cliente pagou pelo período do serviço). O relatório de repasse te diz o arrasto de taxas e a atividade de reembolso para registrar como despesas e receita de contrapartida. O extrato bancário confirma que o dinheiro de fato chegou. Quando dois quaisquer dos três não batem, esse é o sinal de que algo precisa ser investigado — um repasse que falhou, um chargeback contestado ou uma taxa do processador que você não esperava.

O Risco Específico do Chrome: Atrasos de Revisão e Remoções​

Toda stack de pagamentos tem atividade de reembolso comum. As extensões Chrome têm um modo de falha extra que vale a pena rastrear como seu próprio item: atrasos de revisão e remoções por política da Chrome Web Store.

Quando a equipe de revisão do Google sinaliza uma extensão publicada por violação de política, você recebe ou uma remoção imediata (violações de moderadas a severas) ou um período de aviso de aproximadamente 7 a 30 dias para corrigir uma violação menor. De qualquer forma, os usuários perdem acesso a uma extensão pela qual estão pagando ativamente, e isso gera um pico previsível de pedidos de reembolso, chargebacks e chamados de suporte — desenvolvedores relataram perder porcentagens de dois dígitos da receita de assinatura de um mês exatamente por esse padrão, além dos reembolsos diretos.

Dois hábitos contábeis tornam isso administrável em vez de uma surpresa:

• Marque reembolsos e chargebacks por causa. Um reembolso porque o cliente não gostou da extensão é um custo normal de fazer negócio. Um reembolso porque sua extensão foi removida por uma semana é um risco de negócio distinto e rastreável. Separá-los (mesmo que só um campo de observação ou uma subconta) permite ver, ao longo de um ano, quanto da volatilidade de receita vem do risco de plataforma versus do encaixe produto-mercado.
• Trate uma revisão pendente ou um aviso de política em aberto como um evento digno de divulgação, da mesma forma que você sinalizaria o risco de perda de um cliente-chave. Se você está fazendo as contas para decidir se aumenta os preços, contrata ajuda ou pega um empréstimo, uma extensão que está atualmente sob um aviso de conformidade de 30 dias não é "receita recorrente estável" — modele-a como em risco até que a revisão seja concluída.

Reconheça a Receita Quando Você a Ganha, Não Quando o Repasse Chega​

Extensões de assinatura e de compra única precisam de tratamentos diferentes, e misturar os dois é o erro contábil mais comum nesse nicho:

• Assinaturas mensais ou anuais: reconheça a receita uniformemente ao longo do período pelo qual o cliente está pagando, não tudo de uma vez quando a cobrança acontece. Um plano anual pago antecipadamente cria um passivo de receita diferida — você já recebeu o pagamento, mas ainda não entregou onze dos doze meses de serviço, então apenas 1/12 é receita no mês da venda e o resto vai sendo reconhecido mês a mês no balanço.
• Ofertas vitalícias (um modelo de precificação popular especificamente para extensões, já que os usuários desconfiam de assinaturas contínuas para uma ferramenta de navegador): elas ainda representam uma obrigação de fornecer atualizações e suporte indefinidamente, então reconhecer 100% do valor recebido como receita no primeiro dia infla sua receita realmente ganha naquele mês. Uma abordagem mais defensável reconhece a receita da oferta vitalícia ao longo de um período de serviço estimado razoável (muitas empresas usam de 12 a 36 meses como referência) em vez de tudo de uma vez.
• Compras únicas sem obrigação contínua: reconheça integralmente quando entregue — este é o caso simples.

O MRR (receita recorrente mensal) é uma métrica de crescimento útil, mas não é o mesmo número que a receita reconhecida na sua contabilidade. O MRR te diz o ritmo das assinaturas ativas; seu livro-razão deve refletir o que você de fato ganhou nesse período depois dos diferimentos.

Uma Estrutura de Livro-Razão Que Sobrevive a Várias Extensões​

Se você mantém sua contabilidade em um sistema de partidas dobradas em texto simples, a solução para o problema de "um repasse, várias extensões" é um plano de contas que separa a receita por produto desde o início, além de contas explícitas para as deduções que um relatório de repasse já desconta:

2026-07-05 * "Stripe payout - batch #4471"
  Assets:Bank:Checking                      842.17 USD
  Income:Extensions:FocusTimer             -510.00 USD
  Income:Extensions:TabArchiver            -390.00 USD
  Expenses:PaymentProcessing:StripeFees      41.83 USD
  Expenses:Refunds:FocusTimer                16.00 USD

Cada repasse se torna uma única transação que reconcilia o depósito bancário com a receita por extensão, as taxas e os reembolsos como lançamentos separados — em vez de uma linha opaca de "depósito Stripe" que não te diz nada sobre qual produto é de fato lucrativo. Como o arquivo é texto simples, você pode usar grep ou consultá-lo por extensão, por mês, ou por causa do reembolso, exatamente a visibilidade que um relatório de repasse em lote não te dá.

Uma Checklist Mensal​

1. Pegue o relatório de vendas do processador para o mês (bruto, discriminado por produto se possível).
2. Pegue o relatório de repasse e separe taxas, reembolsos e chargebacks em itens próprios.
3. Confirme os depósitos de repasse contra o extrato bancário.
4. Registre a receita de assinaturas e ofertas vitalícias em um cronograma de reconhecimento, não no recebimento.
5. Marque qualquer reembolso ligado a um atraso de revisão ou remoção da Chrome Web Store separadamente do churn comum.
6. Se você vende internacionalmente através de um processador de pagamento direto (não um Comerciante de Registro), verifique se suas vendas acumuladas em algum país ultrapassaram um limite de registro de IVA/GST.

Mantenha a Contabilidade do Seu Negócio de Extensões Tão Limpa Quanto Seu Código​

Você não lançaria uma extensão sem controle de versão, e suas finanças merecem a mesma disciplina — especialmente depois que os repasses são divididos entre vários produtos e processadores. O Beancount.io oferece contabilidade em texto simples e com controle de versão que permite marcar a receita por extensão, rastrear receita diferida e reconciliar repasses contra seu extrato bancário com a mesma precisão que você aplica ao seu código. Comece gratuitamente e veja por que os desenvolvedores estão gerenciando sua contabilidade da mesma forma que gerenciam tudo o mais que constroem.