Ei — vi sua mensagem hoje de manhã, a captura de tela de alguém perguntando "como faço para te pagar por isso" na caixa de suporte do seu app. Parabéns, de verdade. Esse é o momento em que um projeto paralelo deixa de ser uma demonstração. Também é o momento em que uma centena de pequenas decisões que você conseguiu adiar aparecem todas na mesma terça-feira. Você me pediu para simplesmente dizer o que fazer. Vou fazer isso, mas antes quero te explicar o porquê, porque o "porquê" é o que evita que você tenha que me perguntar de novo daqui a três meses, quando for Lemon Squeezy em vez de Stripe, ou assinaturas em vez de pagamento único.
A decisão que você está realmente tomando
Você formulou isso como "qual provedor de pagamento devo usar", mas na verdade são duas decisões empilhadas uma sobre a outra. Primeiro: você quer ser o comerciante registrado (merchant of record), ou quer que outra pessoa seja? Segundo: qual é o formato da sua cobrança — compra única, assinatura ou baseada em uso? Erre na primeira e você vai passar um fim de semana daqui a seis meses se registrando para pagar IVA em um país que nunca visitou. Erre na segunda e é uma migração chata, não legal, então é a menos assustadora das duas.
Ser o comerciante registrado significa que você é quem vende o produto, legalmente. Você recebe o dinheiro, é responsável por calcular impostos sobre vendas e IVA em cada jurisdição onde seus clientes vivem, e precisa declarar isso. O Stripe calcula esse imposto para você de bom grado (Stripe Tax), mas calcular não é o mesmo que recolher — você ainda precisa se registrar e declarar em cada lugar onde ultrapassar um limite. Um serviço de comerciante registrado como Lemon Squeezy ou Paddle tira esse problema todo das suas mãos: eles são legalmente o vendedor, coletam e recolhem impostos em todo lugar, e te pagam o valor líquido. Em troca, você abre mão de uma fatia da margem.
| Opção | Quem é o vendedor | Taxa típica | Tratamento de impostos | Ideal para |
|---|---|---|---|---|
| Stripe (direto) | Você | ~2,9% + US$ 0,30/transação, +0,5% para o Stripe Tax | Você se registra e declara, o Stripe só calcula | Você espera escalar além de alguns milhares por mês e quer taxas menores a longo prazo |
| Lemon Squeezy | Lemon Squeezy | ~5% + US$ 0,50/transação | Totalmente gerenciado, eles são o vendedor registrado | Desenvolvedor solo, primeiro produto, não quer pensar em impostos de jeito nenhum |
| Paddle | Paddle | ~5% + taxas variam por região | Totalmente gerenciado, mais voltado para o segmento corporativo | SaaS com assinaturas e algumas necessidades de faturamento |
| PayPal | Você | ~3,5-4,5%, disputas favoráveis ao comprador | Você lida com isso | Clientes que confiam especificamente no PayPal, não é a escolha padrão |
Para onde você está agora — um cliente, um produto simples, sem ainda saber se isso vai virar um negócio —, eu recomendaria Lemon Squeezy ou Paddle em vez do Stripe puro. Os dois pontos percentuais a mais de taxa são um seguro barato contra virar acidentalmente um contribuinte fiscal em um estado onde você nunca pisou. Você pode migrar para o Stripe direto depois, quando o volume justificar a mudança e você tiver estômago para a papelada. Ninguém migra provedor de pagamento por diversão, mas é uma terça-feira solucionável, não um ano solucionável.
Eu mesmo cometi esse erro num projeto anterior — fui direto para o Stripe porque "todo mundo usa Stripe", recebi algumas centenas de dólares por mês de um punhado de clientes europeus, e então recebi um e-mail muito educado, mas muito confuso, sobre registro no VAT MOSS dezoito meses depois. Custou uma tarde de contador e quarenta minutos de puro pânico pesquisando "será que devo dinheiro para a Holanda". Não foi catastrófico. Mas também totalmente evitável.
Antes de mexer nas chaves de produção
Seja qual for sua escolha, não configure em modo de produção primeiro. Todos esses provedores têm um modo de teste/sandbox com números de cartão falsos que disparam resultados específicos — cobrança bem-sucedida, cartão recusado, exige 3D Secure, fundos insuficientes. Passe por todos eles antes de tocar em uma chave real. Os caminhos de falha são os que você realmente vai encontrar na primeira semana, e são muito menos divertidos de depurar ao vivo com o cartão de uma pessoa real vinculado.
No seu chat de construção, seja explícito de que quer isso em etapas: peça a integração configurada em modo de teste primeiro, com um banner ou indicador claramente visível para que ninguém — nem mesmo você no futuro — cobre acidentalmente um cartão real durante os testes. Depois faça uma segunda etapa, deliberada, para trocar pelas chaves de produção. Dois comandos, não um, mesmo que seja mais rápido apenas dizer "adicione pagamentos" e deixar que ele adivinhe o modo. O atrito é o objetivo.
Você também precisa decidir o que acontece quando um webhook dispara e seu servidor está fora do ar, ou lento, ou o evento chega duplicado. Isso não é hipotético — acontece na primeira semana, de forma confiável. Os eventos que você realmente precisa tratar, no mínimo:
checkout.session.completed(ou equivalente) — conceder acesso, este é o momento em que o cliente se torna clienteinvoice.payment_failed— para assinaturas, decida agora se isso é um bloqueio instantâneo ou um período de carência, porque "bloqueio instantâneo" é uma péssima primeira impressão para um cartão que teve apenas um problema temporáriocustomer.subscription.deleted— alguém cancelou, revogue o acesso ao final do período, não imediatamente, a menos que seus termos digam o contrário- Um evento de reembolso — decida uma vez, por escrito para você mesmo, qual é de fato sua política de reembolso, antes que a primeira solicitação de reembolso te force a decidir na hora
A idempotência importa mais aqui do que em quase qualquer outra parte do seu app. Se um webhook chegar duas vezes — e vai chegar, os provedores tentam novamente em qualquer resposta que não seja 200 — você não pode conceder acesso duas vezes ou, pior, duplicar uma cobrança de estado interno. Armazene o ID do evento e verifique se você ainda não o processou antes de agir sobre ele.
A questão de preços que você está evitando
Você mencionou na sua mensagem que não tinha certeza se deveria cobrar US$ 9/mês ou um valor único de US$ 49. Não acho que nenhuma das opções esteja errada, mas repare no que você está realmente evitando: a conversa com o cliente sobre qual é o valor recorrente. Um preço único é mais fácil de aceitar e mais fácil de construir (sem cobrança automática recorrente, sem tratamento de renovação falhada, sem fluxo de cancelamento). Uma assinatura é uma aposta de que você vai continuar melhorando o produto o suficiente para que as pessoas não cancelem — o que é um compromisso real, não apenas uma caixinha de seleção numa página de preços. Se você não tem certeza se ainda estará trabalhando ativamente nisso daqui a seis meses, um preço único é a oferta mais honesta. Você sempre pode adicionar um nível de assinatura depois, quando houver algo contínuo para assinar.
Mais uma coisa, e depois te deixo em paz: coloque uma política real de reembolso e cancelamento na página antes de receber o primeiro real, mesmo que sejam três frases. Não porque alguém vai te processar por uma cobrança de US$ 9, mas porque escrever isso te obriga a realmente decidir, e "resolvo quando alguém perguntar" é como você acaba tomando uma decisão de política no meio de um e-mail bravo em vez de numa tarde tranquila.
Vá configurar o sandbox primeiro. Me manda mensagem quando tiver passado um cartão recusado falso por ele — essa é a versão de "está funcionando" que realmente importa.
