Olá — vi a tua mensagem esta manhã, a captura de ecrã de alguém a perguntar "como é que te pago por isto" na caixa de suporte da tua aplicação. Parabéns, sinceramente. 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 tens vindo a adiar aparecem todas na mesma terça-feira. Pediste-me para simplesmente te dizer o que fazer. Vou fazer isso, mas quero explicar-te primeiro o porquê, porque o "porquê" é o que evita que me tenhas de perguntar outra vez daqui a três meses, quando for a Lemon Squeezy em vez do Stripe, ou subscrições em vez de pagamento único.
A decisão que estás realmente a tomar
Enquadraste isto como "que fornecedor de pagamentos devo usar", mas na verdade são duas decisões sobrepostas. Primeira: queres ser tu o comerciante de registo, ou queres que seja outra entidade? Segunda: qual é a forma de faturação — compra única, subscrição, ou por utilização? Se errares na primeira, vais passar um fim de semana daqui a seis meses a registares-te para IVA num país onde nunca estiveste. Se errares na segunda, é uma migração incómoda, não legal, por isso é a menos assustadora das duas.
Ser o comerciante de registo significa que és tu quem vende o produto, legalmente. Recebes o dinheiro, és responsável por apurar o imposto sobre vendas e o IVA em cada jurisdição onde os teus clientes vivem, e fazes a respetiva declaração. O Stripe calcula-te esse imposto com gosto (Stripe Tax), mas calcular não é entregar — ainda tens de te registar e declarar em cada local onde ultrapasses um limiar. Um serviço de comerciante de registo como a Lemon Squeezy ou a Paddle tira-te esse problema todo das mãos: são eles, legalmente, o vendedor, cobram e entregam o imposto em todo o lado, e pagam-te o líquido. Em troca, cedes uma fatia da margem.
| Opção | Quem é o vendedor | Taxa típica | Gestão de impostos | Ideal para |
|---|---|---|---|---|
| Stripe (direto) | Você | ~2,9% + 0,30 $/transação, +0,5% para Stripe Tax | Tu registas e apresentas declarações, a Stripe apenas calcula | Esperas crescer para além de alguns milhares por mês e queres taxas mais baixas a longo prazo |
| Lemon Squeezy | Lemon Squeezy | ~5% + 0,50$/transação | Totalmente tratado, eles são o vendedor de registo | Criador independente, primeiro produto, não queres pensar em impostos de todo |
| Paddle | Paddle | ~5% + taxas variam por região | Totalmente tratado, mais orientado para empresas | SaaS com subscrições e algumas necessidades de faturação |
| PayPal | Você | ~3,5-4,5%, disputas favoráveis ao comprador | Tu tratas disso | Clientes que confiam especificamente no PayPal, não uma escolha por defeito |
Para onde estás agora — um cliente, um produto simples, ainda sem ideia se isto se tornará um negócio — apontaria para o Lemon Squeezy ou o Paddle em vez da Stripe direta. Os dois pontos percentuais extra de taxa são um seguro barato contra tornares-te sem querer um contribuinte fiscal num estado onde nunca puseste os pés. Podes migrar para a Stripe diretamente mais tarde, assim que o volume justificar a mudança e tiveres estômago para a papelada. Ninguém migra fornecedores de pagamento por diversão, mas é um problema resolvível numa terça-feira, não num ano.
Eu próprio cometi este erro num projeto anterior — fui logo para a Stripe porque "toda a gente usa a Stripe", recolhi umas centenas de dólares por mês de um punhado de clientes europeus, e depois recebi um e-mail muito educado mas muito confuso sobre registo no VAT MOSS dezoito meses depois. Custou-me uma tarde de contabilista e quarenta minutos de puro pânico a pesquisar no Google "devo dinheiro à Holanda". Não foi catastrófico. Também totalmente evitável.
Antes de tocares nas chaves de produção
Seja qual for a tua escolha, não a configures em modo de produção primeiro. Cada um destes fornecedores tem um modo de teste/sandbox com números de cartão fictícios que despoletam resultados específicos — cobrança bem-sucedida, cartão recusado, requer 3D Secure, fundos insuficientes. Testa todos antes de tocares numa chave real. Os caminhos de falha são os que realmente vais encontrar na primeira semana, e são muito menos divertidos de depurar em produção com o cartão de uma pessoa real associado.
No teu chat de construção, sê explícito sobre queres isto faseado: pede a integração configurada primeiro em modo de teste, com um aviso ou indicador claramente visível para que ninguém — incluindo o teu eu futuro — cobre acidentalmente um cartão real durante os testes. Depois faz um segundo passo, deliberado, para trocar para chaves reais. Dois pedidos, não um, mesmo que fosse mais rápido dizer apenas "adiciona pagamentos" e deixar o sistema adivinhar o modo. O atrito é o objetivo.
Também precisas de decidir o que acontece quando um webhook dispara e o teu servidor está em baixo, ou lento, ou o evento chega duas vezes. Isto não é hipotético — acontece na primeira semana, de forma consistente. Os eventos que realmente precisas de tratar, no mínimo:
checkout.session.completed(ou o equivalente) — concede acesso, este é o momento em que o cliente se torna clienteinvoice.payment_failed— para subscrições, decide agora se isso é um bloqueio instantâneo ou um período de tolerância, porque "bloqueio instantâneo" é genuinamente uma má primeira impressão para um cartão que acabou de ter uma falha temporáriacustomer.subscription.deleted— alguém cancelou, revoga o acesso no final do período, não imediatamente, a menos que os teus termos digam o contrário- Um evento de reembolso — decide de uma vez, por escrito para ti próprio, qual é realmente a tua política de reembolso, antes de o primeiro pedido de reembolso te obrigar a decidir isso ao vivo
A idempotência importa mais aqui do que quase em qualquer outro lugar da tua aplicação. Se um webhook chegar duas vezes — e vai chegar, os fornecedores tentam novamente em qualquer resposta que não seja 200 — não podes conceder acesso duas vezes ou, pior, cobrar duas vezes o estado interno. Guarda o ID do evento e verifica se já não o processaste antes de agires sobre ele.
A questão de preços que estás a evitar
Mencionaste na tua mensagem que não tinhas a certeza se devias cobrar 9€/mês ou um valor único de 49€. Não acho que nenhuma das opções esteja errada, mas repara no que estás realmente a evitar: 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 gestão de cobranças falhadas, sem fluxo de cancelamento). Uma subscrição é uma aposta em que vais continuar a melhorar o produto o suficiente para que as pessoas não cancelem — o que é um compromisso real, não apenas uma caixa de seleção numa página de preços. Se não tens a certeza de que ainda estarás a trabalhar ativamente nisto daqui a seis meses, um preço único é a proposta mais honesta. Podes sempre adicionar um nível de subscrição mais tarde, quando houver algo contínuo para subscrever.
Mais uma coisa, e depois deixo-te voltar ao trabalho: coloca uma política real de reembolso e cancelamento na página antes de receberes o primeiro euro, mesmo que sejam apenas três frases. Não porque alguém te vá processar por uma cobrança de 9€, mas porque escrevê-la obriga-te a decidir realmente sobre isso, e "resolvo isso quando alguém perguntar" é como acabas por tomar uma decisão de política a meio de um e-mail zangado em vez de numa tarde calma.
Vai configurar primeiro o sandbox. Manda-me uma mensagem quando tiveres passado um cartão falso recusado por ele — essa é a versão de "funciona" que realmente importa.
