Pular para o conteúdo
supastack
Explorar a documentação
WebNext.js

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/web/billing.md (or send Accept: text/markdown).

Pagamentos e subscrições

Checkout Stripe, gestão de planos e a fronteira de entitlements.

Perguntar sobre este guia
Abrir em

Escolha e teste seu serviço de pagamento

O faturamento trata dos pagamentos. As permissões de acesso são armazenadas separadamente como autorizações. Conclua a configuração da conta persistente e abra /faturamento no aplicativo Web em execução para ver a interface do plano. Com BILLING_PROVIDER=local, você explora o comportamento local em vez de coletar dinheiro real.

Escolha um provedor de pagamento compatível, siga seu guia de configuração, crie seu próprio produto de teste e preço e copie as configurações do servidor nomeado em apps/web/.env.local. Salve e reinicie o servidor Web. Conclua uma verificação usando as instruções de sandbox desse provedor e, em seguida, inspecione o estado de acesso do workspace após a chegada do webhook do provedor. Um webhook é a mensagem assinada pelo provedor ao seu servidor sobre um evento de pagamento.

Uma página de sucesso por si só não desbloqueia recursos. Se a finalização da compra for concluída, mas o acesso permanecer inativo, verifique a entrega do webhook do provedor e o processamento de eventos do seu servidor antes de repetir o pagamento. Cancelamento de teste e acesso expirado também. As compras por telefone usam a configuração RevenueCat/loja separada, não esta finalização pela Web.

Faturação web

O aplicativo da Web oferece suporte ao provedor de cobrança selecionado com BILLING_PROVIDER; Stripe é uma opção. Abertura/faturamento para planos Web e gerenciamento de assinaturas. Siga o guia do provedor selecionado para definir suas credenciais somente de servidor, IDs de produto ou preço e configurações de verificação de webhook no teste correspondente ou no ambiente ativo.

Autoriza através de permissões

Um redirecionamento de checkout não é prova de acesso ativo. A permissão do servidor decide se um workspace pode usar uma capacidade paga. Verifica essa permissão na fronteira da ação mesmo quando a interface já esconde a ação.

Verifica o ciclo de vida

Usa eventos sandbox para verificar ativação, atualizações, cancelamento e processamento de webhooks. Mantém eventos repetidos seguros e garante que uma permissão inativa bloqueia operações pagas. Compras nativas mobile continuam a ser uma fronteira de integração RevenueCat separada.

Instalação e configuração

O catálogo de planos vive em src/product-plans.ts e orienta a superfície /billing e o passo de onboarding /choose-plan. A faturação configura-se no servidor com BILLING_PROVIDER=stripe, STRIPE_SECRET_KEY, os price ids por plano e intervalo, e STRIPE_WEBHOOK_SECRET. O Lemon Squeezy está disponível como adaptador alternativo.

Os planos baseados em assentos usam os seletores editáveis de assentos (src/seat-count.ts); a quantidade segue com a sessão de checkout para que os assentos cobrados correspondam ao workspace. Os planos também podem declarar meteredUsage em src/product-plans.ts para que a tarefa horária billing.usage-report envie os deltas de usage_counter aos medidores de cobrança da Stripe, enquanto os proprietários do workspace definem orçamentos mensais de IA e tetos rígidos por medidor em Configurações → Uso (USAGE_METERS em src/usage-meters.ts).

Checkout: POST /api/billing/checkout
Portal:   POST /api/billing/portal
Webhook:  POST /api/billing/webhook  (signature-verified)

Fluxo de implementação

Um redirect de checkout é apenas uma intenção pendente — o acesso muda quando o webhook assinado chega e o entitlement do servidor é atualizado. Controla as ações pagas com a verificação de entitlement na fronteira do servidor (entitlement-gate.tsx / entitlement-check.ts) mesmo quando a interface já as oculta.

O portal do cliente gere alterações de plano, cancelamento e métodos de pagamento. Mantém o estado da subscrição legível pelos membros do workspace e as compras nativas mobile atrás da fronteira separada do RevenueCat.

Perguntas frequentes

14 perguntas

O que é o supastack?

O supastack é uma base modular para construir produtos SaaS com IA. Reúne a infraestrutura comum para que possas concentrar-te nas funcionalidades próprias do teu produto.

Suporta web e mobile?

Sim. O supastack inclui apps Next.js e Expo como pontos de partida para experiências web e mobile.

Que autenticação está incluída?

O Better Auth cobre email/palavra-passe, OTP e login social. Os workspaces pessoais são aprovisionados com a conta para que os registos fiquem delimitados desde o primeiro dia.

Como é suportada a IA?

O supastack inclui IA multi-fornecedor configurável, registo de utilização, orçamentos e suporte encriptado de chaves próprias (BYOK).

Como são geridas as subscrições?

Para produtos construídos sobre o kit, a faturação Stripe, as subscrições e as permissões formam a base do acesso pago. Os segredos de fornecedor ficam no servidor.

Onde vive o código próprio do meu produto?

As funcionalidades próprias do produto ficam num codebase separado, enquanto o produto configura e integra os módulos base do supastack.

Como funciona o preço do supastack?

O kit é uma compra única com atualizações vitalícias: Uma framework por 249 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 349 $) ou Todas as frameworks (Next.js, iOS, Android) por 499 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 599 $), mais 75 $ por lugar de programador adicional. Sem subscrição do kit. O checkout neste site entrega a tua chave de licença por email, com acesso ao repo por convite GitHub.

Como é que os workspaces delimitam os meus dados?

Os registos do utilizador são delimitados por workspaceId. Identidade, permissões, utilização de IA, eventos de faturação e entradas de auditoria ficam dentro do limite do workspace pessoal.

Como funcionam os jobs em segundo plano?

O Trigger.dev é o runtime de jobs explícito. O contrato JobRunner só promete enqueue, status e cancel — a semântica de workflow permanece específica e explícita do Trigger.dev.

Como difere o email da divulgação?

O email transacional cobre fluxos de produto como avisos de conclusão de tarefas. A divulgação fria e as campanhas pertencem ao próprio produto, fora do módulo de email deste kit.

Como funcionam as compras no aplicativo móvel?

O aplicativo móvel inclui compras nativas e restauração via RevenueCat, com acesso verificado pelo servidor. Configure as contas das lojas e conclua os testes em dispositivos antes de publicar. A cobrança web permanece separada.

Onde residem as chaves dos fornecedores de IA?

As credenciais BYOK são encriptadas e ficam no servidor. As chaves são higienizadas nos logs; a utilização e os orçamentos ficam visíveis ao nível do workspace.

Quais métodos de pagamento o checkout aceita?

O checkout hospedado na Stripe aceita cartões e também pode oferecer Alipay e WeChat Pay quando essas carteiras estiverem ativadas na conta Stripe — útil para compradores na China. As autorizações de carteira são confirmadas de forma assíncrona, então a página da licença é atualizada assim que o pagamento é liquidado.

Posso solicitar um reembolso?

Depois de obter acesso ao repositório, o supastack é seu para sempre, portanto não pode ser reembolsado. Mas fique tranquilo: você recebe o código-fonte completo com atualizações vitalícias para criar e lançar produtos ilimitados para você ou seus clientes. Você apenas não pode revender o código nem redistribuir o repositório como starter kit ou modelo.

PT
Tema