Skip to main content
O pacote @dodopayments/sveltekit fornece três handlers de rota ao seu app SvelteKit. Checkout retorna URLs de checkout, CustomerPortal envia um cliente ao Customer Portal, e Webhooks verifica eventos de webhook e os encaminha ao seu código.

Checkout Handler

Crie URLs de checkout no seu app SvelteKit.

Customer Portal

Permita que os clientes gerenciem suas assinaturas e seus dados.

Webhooks

Receba e verifique eventos de webhook do Dodo Payments.

Instalação

1

Install the Package

Execute este comando na raiz do seu projeto:
O pacote lista SvelteKit 2 (@sveltejs/kit 2.20.3 ou posterior) e zod 3.25 ou posterior como peer dependencies.
2

Set Up Environment Variables

Crie um arquivo .env na raiz do seu projeto:
Crie a API key em Developer → API Keys. Adicione seu endpoint de webhook em Developer → Webhooks e copie o signing secret para DODO_PAYMENTS_WEBHOOK_KEY. DODO_PAYMENTS_RETURN_URL é o local para onde os clientes são direcionados após o checkout. Se você não passar um environment, os handlers usarão live_mode.
Nunca faça commit do seu arquivo .env ou de secrets no controle de versão.

Exemplos de Route Handlers

Os exemplos são endpoints +server.ts do SvelteKit em src/routes/api/. Eles importam suas credenciais de $env/static/private, que o SvelteKit mantém fora do código executado no cliente.
Use este handler para adicionar o checkout do Dodo Payments ao seu app SvelteKit. Checkout retorna um handler GET para checkout estático e um handler POST para sessões de checkout, ou para checkout dinâmico quando você define type: "dynamic". Exporte GET de um handler criado com type: "static" ou sem type, pois o handler GET de um handler session ou dynamic retorna 400.
A solicitação de checkout dinâmico funciona quando POST vem de um handler criado com type: "dynamic". Com type: "session", como na rota de exemplo, envie a solicitação da sessão de checkout.

Checkout Route Handler

O checkout handler oferece suporte às três formas de aceitar pagamentos com o Dodo Payments:
  • Static Payment Links: URLs compartilháveis que coletam pagamentos sem código.
  • Dynamic Payment Links: links de pagamento gerados por você com detalhes personalizados. Eles usam endpoints deprecated.
  • Checkout Sessions: checkout hospedado com carrinho de produtos, dados do cliente e opções de personalização. Este é o fluxo recomendado.
Checkout aceita estas opções:

Query Parameters compatíveis

string
obrigatório
Identificador do produto, por exemplo ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
padrão:"1"
Quantidade do produto.
string
Nome completo do cliente. Ignorado se firstName ou lastName for fornecido.
string
Nome do cliente.
string
Sobrenome do cliente.
string
Endereço de e-mail do cliente.
string
País do cliente, como um código ISO 3166-1 alpha-2.
string
Linha de endereço do cliente.
string
Cidade do cliente.
string
Estado ou província do cliente.
string
CEP ou código postal do cliente.
boolean
Defina como true para desativar o campo de nome completo.
boolean
Defina como true para desativar o campo de nome.
boolean
Defina como true para desativar o campo de sobrenome.
boolean
Defina como true para desativar o campo de e-mail.
boolean
Defina como true para desativar o campo de país.
boolean
Defina como true para desativar o campo de linha de endereço.
boolean
Defina como true para desativar o campo de cidade.
boolean
Defina como true para desativar o campo de estado.
boolean
Defina como true para desativar o campo de CEP.
string
Moeda do pagamento, por exemplo USD.
boolean
padrão:"true"
Mostra ou oculta o seletor de moeda.
number
Define o valor cobrado, em unidades principais da moeda, por exemplo 12.5 para $12.50. Funciona somente com produtos Pay What You Want e é ignorado se estiver abaixo do preço mínimo do produto.
boolean
padrão:"true"
Mostra ou oculta a seção de descontos.
string
Qualquer query parameter que comece com metadata_ é passado como metadata.
O handler adiciona returnUrl da sua configuração ao link como redirect_url.
Se productId estiver ausente, o handler retorna uma resposta 400. Query parameters inválidos e IDs de produto inexistentes também retornam 400.

Formato da resposta

O checkout estático retorna uma resposta JSON com a URL de checkout. No modo de teste, a URL usa test.checkout.dodopayments.com.
O checkout dinâmico funciona como proxy dos endpoints deprecated POST /payments e POST /subscriptions. Ele continua funcionando para integrações existentes, mas novas integrações devem usar sessões de checkout.

Formato da resposta

O checkout dinâmico retorna uma resposta JSON com a URL de checkout:
As sessões de checkout criam um checkout hospedado para compras únicas e assinaturas, com controle total da personalização. product_cart é o único campo obrigatório. Se o corpo não tiver return_url, o handler usará returnUrl da sua configuração.Para obter mais detalhes e consultar todos os campos compatíveis, veja o Checkout Sessions Integration Guide.Uma sessão criada com payment_method_id não retorna uma URL de checkout, portanto o handler responde com 400. Para cobrar uma payment method salva, crie a sessão usando o SDK.

Formato da resposta

As sessões de checkout retornam uma resposta JSON com a URL de checkout:

Customer Portal Route Handler

O Customer Portal route handler cria uma sessão do Customer Portal para o cliente informado e redireciona o navegador para ela com uma resposta 302.
O handler não verifica quem está fazendo a chamada. Qualquer pessoa que fizer uma solicitação com um customer ID terá acesso ao portal desse cliente. Proteja a rota com sua própria autenticação e passe somente o customer ID do usuário autenticado.

Query Parameters

string
obrigatório
O customer ID da sessão do portal, por exemplo ?customer_id=cus_123.
boolean
Se definido como true, o Dodo Payments também enviará o link do portal por e-mail ao cliente.
Retorna 400 se customer_id estiver ausente e 500 se a sessão do portal não puder ser criada.

Webhook Route Handler

O webhook route handler verifica cada solicitação antes de executar seu código:
  • Method: somente solicitações POST são compatíveis. Outros métodos retornam 405.
  • Signature Verification: verifica o corpo bruto da solicitação e os headers webhook-id, webhook-timestamp e webhook-signature com webhookKey, seguindo a especificação Standard Webhooks. Retorna 401 se a verificação falhar.
  • Payload Validation: valida o payload com Zod. Retorna 400 para um payload inválido.
  • Error Handling:
    • 401: assinatura inválida
    • 400: payload inválido
    • 500: erro interno durante a verificação
  • Event Routing: chama onPayload para cada evento, depois o handler correspondente ao tipo do evento, e retorna 200.
O adaptor não captura erros lançados nos seus handlers. Eles são propagados para o SvelteKit, e a solicitação falha.

Handlers de eventos de webhook compatíveis

Cada handler recebe o payload verificado correspondente ao seu tipo de evento:
Para saber o significado de cada evento, consulte o Webhook Event Guide.

Prompt para LLM

Copie este prompt no seu assistente de programação com IA para que ele adicione o adaptor ao seu projeto. Para também fornecer ao seu agent a documentação e as skills do Dodo Payments, instale o Agent Plugin.
Última modificação em 26 de setembro de 2026