As dores de construir seu próprio sistema de cobrança

Artigo original ↗ Discussão no Hacker News ↗

Construir seu próprio sistema de cobrança para um negócio SaaS ou online muitas vezes parece simples, mas rapidamente se torna complexo em torno de impostos, prorrateio, reembolsos, direitos de uso, conformidade legal, regras de arredondamento e integração com contabilidade e processadores de pagamento. Muitos engenheiros que já fizeram isso alertam que isso desvia enorme tempo e risco do trabalho no produto principal, defendendo plataformas especializadas de cobrança ou serviços de merchant of record — enquanto uma minoria contrapõe que sistemas internos, limitados e incrementais, podem ser viáveis para necessidades simples ou de estágio inicial. Um tema recorrente é o valor de separar cobrança de direitos de uso e tratar a cobrança como um subsistema rigorosamente auditável e orientado por políticas, em vez de um conjunto de scripts ad hoc acoplados ao Stripe ou APIs semelhantes.

Construir vs. Comprar para Cobrança

  • Há um forte consenso de que cobrança é enganosamente complexa; muitos argumentam que a maioria das empresas não deveria construir o próprio sistema e deveria usar Stripe/Braintree/Chargebee/Lago/killbill/etc.
  • Visão contrária: para produtos simples ou estágios iniciais, você pode começar pequeno, construir incrementalmente e aceitar algum trabalho manual; conselhos excessivamente genéricos do tipo “nunca construa” são vistos como exagerados.
  • Outra visão: você constrói se a cobrança for central para o seu negócio ou se você operar onde os grandes provedores não funcionam (por exemplo, algumas jurisdições fora dos EUA/UE).

Complexidade e Casos Limite Ocultos

  • A dor real está na cauda longa: regras de prorrateio, upgrades/downgrades, manutenção de condições antigas, testes, contratos corporativos personalizados, pagamentos de afiliados, reembolsos/estornos e executar todo o fluxo “ao contrário” (créditos, correções, devoluções parciais).
  • Fusos horários, diferentes ciclos de cobrança, cobrança adiantada vs. a prazo, preços baseados em uso, descontos em faixas e comportamento de arredondamento interagem de formas não óbvias.
  • Muitos relatos de sistemas caseiros causando grandes perdas financeiras por bugs de arredondamento, problemas de escala e lógica frágil de “gambiarra”.

Direitos de Uso vs. Cobrança

  • Forte defesa de separar cobrança (dinheiro, faturas, reconhecimento de receita) de direitos de uso (o que o cliente realmente pode usar).
  • Arquitetura sugerida: o sistema de direitos de uso armazena capacidades/limites; a cobrança calcula os encargos; uma camada de políticas separada conecta tudo e suporta exceções e ajustes manuais.
  • Debate sobre usar feature flags para direitos de uso: conveniente e flexível, mas pode sobrecarregar um único sistema; alguns preferem serviços dedicados de direitos de uso/autorização.

Segurança, Conformidade e Regulação

  • Discussão em torno da ideia de “jogar um arquivo no S3 + cron”: vista como ingênua, mas tecnicamente pode ser tornada robusta; criptografia em trânsito/em repouso é padrão, mas pode não atender modelos de ameaça mais rigorosos.
  • Alguns argumentam que apenas criptografia no lado do cliente com chaves independentes realmente cumpre a intenção de “criptografado em repouso”.
  • Alegações conflitantes sobre regras da UE: vários esclarecem que escrever sua própria cobrança é अनुमति/permitido; a regulamentação mira principalmente o processamento de pagamentos e fluxos PSD2, não a emissão interna de faturas.

Contabilidade, Impostos e Questões Legais

  • Integração com contabilidade/ERP, reconhecimento de receita, conciliação de dinheiro em trânsito, fechamento mensal/trimestral e auditabilidade são grandes encargos.
  • IVA/imposto sobre vendas, regras diferentes por país, faturas corretivas, numeração de documentos e requisitos de retenção são descritos como desgastantes, mas obrigatórios.
  • Erros podem levar a multas ou pior; você precisa conseguir explicar “por que este cliente pagou este valor”.

Ferramentas e Plataformas

  • Stripe é elogiada por facilitar pagamentos, mas criticada por APIs confusas, abstrações de alto nível fracas e lacunas operacionais (perda de webhooks, sincronização de estado).
  • Plataformas de cobrança open source e comerciais (por exemplo, mecanismos OSS genéricos, startups de cobrança baseada em uso, serviços de merchant of record) são mencionadas como opções, embora a opacidade de preços seja uma reclamação comum.

Padrões de Design e Anti-padrões

  • Padrões recomendados: separação clara de responsabilidades (direitos de uso vs. livro-razão vs. faturamento), contabilidade em estilo livro-razão, processos agendados em vez de acoplamento em tempo real, operações idempotentes, regras de arredondamento configuráveis.
  • Anti-padrões: “blob” monolítico de cobrança, acoplamento estreito de direitos de uso a pagamentos, efeitos colaterais em tempo real em todos os lugares e históricos ingênuos de máquina de estados que não escalam.

Anedotas e Atitudes

  • As histórias incluem cheques de “dinheiro mágico” de seguradoras, reconciliação caótica de contas a receber na saúde, sistemas de viagens e telecom que se tornaram inviáveis de manter e uma pequena história de sucesso em que a cobrança personalizada desbloqueou métodos de pagamento flexíveis.
  • Vários engenheiros experientes comparam cobrança a “encanamento séptico”: desagradável, arriscado e subestimado, mas tecnicamente interessante e sempre em demanda.