Pagamentos para empresa solo: Stripe, Paddle, Lemon Squeezy ou WeChat Pay

Aviso: este texto não é orientação tributária, jurídica, societária, cambial ou de elegibilidade. Para Merchant of Record, VAT/GST/sales tax, entidades nacionais ou estrangeiras e repasses, consulte os termos dos serviços e profissionais qualificados.

Seu pricing.ts define starter_monthly, pro_yearly, lifetime_license e wechat_one_time, mas o banco só tem is_paid. O webhook checkout.session.completed chega e o cliente volta por success_url, porém entitlements continua vazio. O problema não é o botão: o sistema não conecta produtos, pedidos, assinaturas e acesso.

Antes de escolher o provedor, responda cinco perguntas: o que vender, como cobrar, para quem, quem responde pela transação e pelo imposto sobre vendas e quem libera o acesso após o pagamento. Stripe, Paddle, Lemon Squeezy e WeChat Pay não são quatro botões equivalentes; cobrem camadas diferentes.

Defina o modelo de venda antes do provedor de pagamento

Compra única depende de pedido e entrega. Assinatura SaaS exige todo o billing lifecycle. Cobrança por uso também requer dados rastreáveis. Leve o modelo primeiro para products, prices e tabelas locais.

Modelo de venda	Pontos de partida	Eventos assíncronos principais	Tabelas locais
Produto digital de compra única	Stripe / Paddle / Lemon Squeezy	checkout.session.completed / transaction.completed / order_created	orders + entitlements
Assinatura SaaS	Stripe Billing / Paddle Billing / Lemon Squeezy	customer.subscription.* / subscription.*	subscriptions + entitlements + usage_events quando necessário
Assinatura e compra única	Stripe Billing / Paddle Billing	Vários eventos	orders + subscriptions + entitlements
China continental ou WeChat	WeChat Pay (JSAPI/H5/Native)	Callback e consulta do pedido	orders + wechat_prepay

Três pontos importam:

• Produto único precisa de pedido, entrega, reembolso e reenvio, não de todo o ciclo de assinatura.
• SaaS recorrente precisa de subscriptions com current_period_start/end, cancel_at e status; cobrança por uso adiciona usage_events auditáveis.
• WeChat Pay é meio de pagamento e sistema de lojista, não Merchant of Record global nem plataforma de SaaS billing.

Os recursos mudam. Antes de integrar, revise região da conta, modo do produto, meios de pagamento, versão da API e termos.

Merchant of Record não elimina todas as responsabilidades

Merchant of Record, ou MoR, é o vendedor registrado da transação. Paddle e Lemon Squeezy usam esse modelo para produtos digitais elegíveis e tratam pagamento, imposto sobre vendas, reembolso ou disputa dentro desse escopo. Isso reduz a operação fiscal global, mas não elimina obrigações de renda, entidade, produto, dados e contabilidade.

Com Stripe, o lojista geralmente continua sendo o vendedor. Stripe Tax ajuda a calcular sales tax, VAT e GST e oferece ferramentas de monitoramento e registro, mas não transforma Stripe automaticamente em Merchant of Record. Registro, declaração e entidade dependem da jurisdição e da transação.

Não escolha um MoR por um limite fixo de receita. Compare estas dimensões:

Dimensão	Stack próprio de pagamento e billing	Merchant of Record
Personalização	Combinar Checkout, Billing, Tax, faturas e processos internos	Seguir política de produto, checkout, contrato e regras de repasse
Operação fiscal e de cobrança	O lojista confirma registro, declaração, faturas, reembolsos e disputas	O MoR assume imposto, pagamento e parte do compliance nas transações cobertas
Custo	Somar ferramentas fiscais, engenharia, financeiro e suporte à taxa	Avaliar repasses, reembolsos, adicionais e limites, não só percentual
Melhor encaixe	Muita personalização, operação existente ou contratos especiais	Menos trabalho fiscal global e de assinaturas para produtos elegíveis

O limite contratual e fiscal depende de entidade, território, produto e cliente. Página de marketing não substitui termos nem orientação profissional.

Como escolher Stripe, Paddle, Lemon Squeezy ou WeChat Pay

Se você precisa de assinaturas e WeChat Pay, separe os problemas. Ciclo da assinatura, pagamentos globais e China podem usar serviços diferentes. Um método listado não funciona necessariamente em toda região, modo Checkout ou recorrência.

Serviço	Responsabilidade	Assinaturas e compras únicas	Pagamentos na China	Licença nativa	Bom ponto de partida
Stripe	Payment, Billing e Tax; normalmente não MoR	Checkout e Billing personalizáveis	Alipay/WeChat Pay dependem de região, moeda e modo	Sem License Key geral	SaaS que controla pagamentos, assinaturas, impostos e processos
Paddle	Merchant of Record	Paddle Billing e Checkout	Conferir Dashboard e documentação por conta e região	Aplicativo gerencia acesso	Software que quer reduzir imposto global e operação recorrente
Lemon Squeezy	Merchant of Record	Digitais, assinaturas simples e consumo	Alipay/WeChat Pay em compra única; recorrência mais limitada	License Keys	Produtos digitais, licenças e primeiras assinaturas
WeChat Pay	Meio de pagamento e sistema de lojista	JSAPI/H5/Native; billing próprio	China continental e WeChat	Nenhuma	Compras únicas em RMB e checkout WeChat

A documentação oficial confirmava em 18 de julho de 2026:

• Stripe Checkout oferece páginas hospedadas, incorporadas e componentes combináveis. Os métodos dependem de região, moeda e modo Checkout.
• Paddle entrega webhooks ao menos uma vez. Sem 200 em cinco segundos, tenta novamente. Eventos podem duplicar ou chegar fora de ordem; use event_id e occurred_at.
• Lemon Squeezy lista Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay e bank debits. Assinaturas aceitam apenas Cards, Apple Pay, Google Pay e PayPal.
• WeChat Pay H5 exige pedido no servidor, callback e consulta ativa. O retorno do navegador não é definitivo.

Taxas, métodos, repasses, países e políticas mudam. Abra preços e contratos atuais ao montar o orçamento.

O webhook é a fronteira da sincronização de acesso

Dois erros comuns:

1. checkout.session.completed chega e success_url abre, mas entitlements não muda e o cliente não acessa.
2. O mesmo evento entra duas vezes em webhook_events e o handler emite duas licenças.

Os dois tratam uma requisição HTTP ou página de sucesso como verdade final. Eventos podem duplicar, atrasar ou chegar fora de ordem; alguns estados exigem consulta ou evento posterior.

Princípios para o endpoint webhook

Princípio	Stripe	Paddle	Lemon Squeezy	WeChat Pay
HTTPS endpoint	Obrigatório	Obrigatório	Obrigatório	Obrigatório
Verificação de assinatura	Stripe-Signature	Paddle-Signature	X-Signature	Assinatura WeChat Pay API v3
Chave idempotente	ID de evento ou objeto	event_id	Tipo + ID do objeto ou chave única	out_trade_no e ID da transação
Resposta	Validar e guardar, responder rápido e processar em segundo plano	200 em cinco segundos	Responder sucesso e processar em segundo plano	Seguir o contrato atual
Compensação	Consultar pagamento ou assinatura	Consultar entidades e reconciliar	Consultar pedido ou assinatura	Consultar, conciliar e recuperar manualmente

Regras operacionais:

• Webhook ou callback inicia a sincronização. success_url apenas mostra processamento.
• Valide a assinatura e guarde o evento ou campos em webhook_events; leve o trabalho complexo para um job assíncrono.
• Aplique restrição única e registre event_id, source, occurred_at, processed_at, status e payload_hash.
• Para desordem, compare horário, atualização do objeto ou versão do estado, não apenas chegada.
• Execute reconciliation, consulte pedido ou assinatura e mantenha recuperação manual.

Tabelas de pedidos, assinaturas, acesso e eventos

Tabela	Campos principais	Stripe	Paddle	Lemon Squeezy
orders	provider_order_id, customer_id, amount, currency, status, created_at	Checkout Session / PaymentIntent	transaction	order
subscriptions	provider_subscription_id, customer_id, status, current_period_end, cancel_at	subscription	subscription	subscription
entitlements	user_id, product_id, feature_key, source, status, expires_at	Derivado de order ou subscription	Derivado de transaction ou subscription	Derivado de order, subscription ou license
webhook_events	provider, event_id, occurred_at, processed_at, status, payload_hash	Idempotência e auditoria	Idempotência e ordem	Idempotência e auditoria

Não copie cada objeto da API. Defina campos estáveis para decidir acesso e guarde IDs do provedor para consultas e reconciliation.

Estratégias de sincronização de acesso

Estratégia	Quando usar	Implementação
Lean cache	Maioria dos SaaS recorrentes	Guardar customer, subscription, status, price e product necessários e atualizar por eventos
State mirror	Visões offline ou painéis complexos	Replicar mais dados, registrar atualização e evitar divergência com reconciliation
License key	Produto digital único ou desktop	Guardar instance ID e validar store, product, variant e customer; chave não é sistema de usuários

Paddle recomenda lean cache para a maioria dos aplicativos. Use state mirror apenas para consultas locais realmente necessárias. Chaves Lemon Squeezy também exigem validar produto e cliente e associar a instance à conta e ao dispositivo.

Pontos de integração de cada serviço

Estes pontos delimitam a primeira implementação e não substituem a documentação completa.

Integrar Stripe

Um SaaS inicial pode usar Checkout hospedado e Customer Portal em vez de manter formulário de cartão. Stripe Billing gerencia assinaturas, faturas, consumo e recuperação de receita. Stripe Tax é ferramenta fiscal, não Merchant of Record.

Produtos e preços devem mapear acesso local: product_id é produto ou pacote; price_id, mensal, anual, seat ou usage. Não deixe só is_paid em users.

Veja o tutorial de carrinho Next.js e Stripe para Checkout Session, endpoint webhook e pedidos.

Integrar Paddle

Confirme que o tutorial usa Paddle Billing, não Paddle Classic. Mudam API, webhooks, Paddle.js e Product/Price.

Paddle Checkout mostra a caixa, mas o aplicativo faz provisioning. Normalmente customer, subscription, status, price, product e scheduled change bastam. Crie state mirror só se operações precisar de dados completos.

Atualize por webhook e execute reconciliation. Merchant of Record não sabe automaticamente quem usa cada recurso.

Integrar Lemon Squeezy

Lemon Squeezy atende produtos digitais, licenças e assinaturas simples. Oferece Merchant of Record, checkout, subscriptions, usage-based billing, webhooks e License Keys. Confirme taxas e escopo no store plan atual.

Após ativar a chave, guarde instance ID e valide store_id, product_id, variant_id e customer. Chave alheia ou revendida não deve ativar Pro.

Para assinatura WeChat Pay, confira separadamente os métodos recorrentes. A documentação lista WeChat Pay e Alipay, mas assinaturas aceitam Cards, Apple Pay, Google Pay e PayPal.

Limites do WeChat Pay

WeChat Pay funciona na China continental e no WeChat, mas não é Merchant of Record global nem ciclo SaaS completo. O lojista gerencia estado, assinatura, consultas, reembolsos, reconciliation, faturas e acesso.

H5, JSAPI, Mini Program e Native são cenários de pagamento. No H5, o backend cria o pedido e entrega h5_url; na volta do navegador, consulta e aplica o callback ao mesmo out_trade_no.

Confira permissões, entidade, domínios, taxas e parâmetros na documentação atual do WeChat Pay.

Próximo passo: transformar o botão em máquina de estados testável

Depois de escolher, divida a integração em tarefas verificáveis:

1. Crie orders, subscriptions, entitlements e webhook_events; adicione usage_events para consumo.
2. Implemente assinatura, idempotência, desordem, resposta rápida e recuperação em cada webhook ou callback.
3. Faça a página de sucesso consultar o pedido local em vez de gravar is_paid=true.
4. Adicione testes de consulta, reconciliation, reembolso, renovação falha e recuperação manual.
5. Reenvie eventos e inverta atualizações no sandbox; o acesso não pode duplicar nem regredir incorretamente.

Para backend e banco de dados, continue em Supabase Edge Functions e nos artigos de backend e dados desta série. Concluir não é voltar da página de pagamento: pedidos, assinaturas e acesso precisam convergir apesar de duplicidade, atraso, desordem e reembolso.