Skip to main content
O adaptador @dodopayments/fastify fornece ao seu app Fastify três handlers de rota: Checkout retorna URLs de checkout, CustomerPortal envia um cliente ao Customer Portal, e Webhooks verifica solicitações de webhook e chama seus handlers de eventos.

Checkout Handler

Crie links de pagamento e sessões de checkout no seu app Fastify.

Customer Portal

Permita que os clientes gerenciem suas assinaturas e dados.

Webhooks

Verifique e processe eventos de webhook do Dodo Payments.

Instalação

1

Install the Package

Execute o comando a seguir na raiz do seu projeto:
O pacote requer o Fastify 5.4.0 ou posterior.
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 segredo de assinatura para DODO_PAYMENTS_WEBHOOK_KEY. Durante o desenvolvimento, use uma API key do modo de teste com DODO_PAYMENTS_ENVIRONMENT=test_mode, pois uma chave do modo de teste funciona somente com o modo de teste. DODO_PAYMENTS_RETURN_URL é opcional.
Nunca faça commit do seu arquivo .env nem de segredos no controle de versão.

Exemplos de handlers de rota

Os exemplos registram rotas em uma instância do Fastify criada com Fastify(). A rota de webhook precisa do corpo bruto da solicitação, portanto o exemplo adiciona um parser de corpo do tipo string dentro de um plugin que contém somente a rota de webhook.
Use este handler para integrar o checkout do Dodo Payments ao seu app Fastify. Ele oferece suporte a fluxos de pagamento estático (GET), dinâmico (POST) e de sessão (POST). Checkout() retorna um getHandler para o fluxo estático e um postHandler para os fluxos dinâmico e de sessão. Registre cada fluxo POST em seu próprio caminho.

Handler de rota de checkout

O adaptador oferece suporte aos três fluxos de checkout do Dodo Payments. Defina type na configuração do handler para escolher o fluxo atendido por uma rota. Cada fluxo responde com JSON que contém um checkout_url para o cliente abrir.
  • Links de pagamento estáticos: type: "static", GET. Cria um link de pagamento para um produto usando parâmetros de consulta, depois de verificar se o produto existe.
  • Links de pagamento dinâmicos: type: "dynamic", POST. Cria um pagamento único ou uma assinatura com um link de pagamento, dependendo de o produto ser recorrente.
  • Sessões de checkout: type: "session", POST. Cria uma sessão de checkout a partir de um carrinho de produtos e dos dados do cliente. Use este fluxo para novas integrações.
Checkout aceita estas opções: Checkout retorna um objeto com dois handlers. Registre getHandler para GET quando type for static, e postHandler para POST quando type for dynamic ou session.

Parâmetros de consulta 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
Primeiro 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
Endereço da rua do cliente.
string
Cidade do cliente.
string
Estado ou província do cliente.
string
Código postal ou ZIP code do cliente.
boolean
Defina como true para desativar o campo de nome completo.
boolean
Defina como true para desativar o campo de primeiro 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 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 ZIP code.
string
A moeda do pagamento, por exemplo USD.
boolean
padrão:"true"
Mostra ou oculta o seletor de moeda.
number
Define o valor cobrado, em unidades maiores 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 parâmetro de consulta que comece com metadata_ é enviado ao checkout como metadata; por exemplo, metadata_orderId=123.
Um sinalizador de desativação só tem efeito quando é true e o campo correspondente tem um valor; por exemplo, email com disableEmail. O handler passa esses parâmetros para um link de pagamento estático.
Se productId estiver ausente, o handler retornará uma resposta 400. Parâmetros de consulta inválidos ou um produto que não exista na sua conta também resultarão em uma resposta 400.

Formato da resposta

O checkout estático retorna uma resposta JSON com a URL de checkout:
  • Envie os parâmetros como um corpo JSON em uma solicitação POST.
  • Oferece suporte a pagamentos únicos e recorrentes. O handler recupera o produto e cria uma assinatura se o produto for recorrente; caso contrário, cria um pagamento único.
  • O corpo precisa de billing (com street, city, state, country e zipcode) e customer, além de product_id (com um quantity opcional) ou product_cart. As assinaturas precisam de product_id.
  • O handler também encaminha metadata, allowed_payment_method_types, billing_currency, discount_codes (ou o discount_code obsoleto), return_url, show_saved_payment_methods e tax_id. Para assinaturas, ele também encaminha addons, on_demand e trial_period_days. Os outros campos são ignorados.
  • Para obter detalhes dos campos, consulte:
O checkout dinâmico chama os endpoints obsoletos POST /payments e POST /subscriptions. Use Checkout Sessions para novas integrações.

Formato da resposta

O checkout dinâmico retorna uma resposta JSON com o link de pagamento como URL de checkout:
Envie um payload de sessão de checkout como corpo JSON. O handler cria uma sessão de checkout que gerencia todo o fluxo de pagamento para compras únicas e assinaturas e retorna seu checkout_url. product_cart é obrigatório e deve conter pelo menos um produto.Cada checkout_url funciona uma vez e expira após 24 horas ou após 15 minutos quando você passa confirm: true. Uma sessão criada com payment_method_id não retorna checkout_url, portanto o handler responde com 400.Consulte o Guia de integração do Checkout Sessions para obter mais detalhes e a lista completa de campos compatíveis.

Formato da resposta

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

Handler de rota do Customer Portal

O handler de rota do Customer Portal cria uma sessão do Customer Portal para o cliente em customer_id e redireciona a solicitação para o link do portal. CustomerPortal aceita as opções bearerToken e environment, as mesmas de Checkout. Se o Dodo Payments não conseguir criar a sessão, o handler retornará 500.

Parâmetros de consulta

string
obrigatório
O ID do cliente para a sessão do portal; por exemplo, ?customer_id=cus_123.
boolean
Se definido como true, envia um e-mail ao cliente com o link do portal.
Retorna 400 se customer_id estiver ausente. O handler não autentica a solicitação e abre o portal para qualquer customer_id recebido. Portanto, proteja a rota com sua própria autenticação e passe somente o ID do cliente autenticado.

Handler de rota de webhook

O handler de webhook verifica cada solicitação com o segredo do seu webhook, passado como webhookKey, e então chama seus handlers de eventos.
O handler de webhook precisa do corpo bruto da solicitação como uma string. Portanto, adicione um parser de tipo de conteúdo para application/json com parseAs: 'string'. O Fastify aplica um parser a todas as rotas no escopo em que ele é adicionado. Adicione-o dentro de um plugin que registre somente a rota de webhook, como no exemplo. Na instância raiz, ele também passaria uma string aos handlers POST de checkout, que então retornariam 400.
  • Método: Somente solicitações POST são compatíveis. Outros métodos retornam 405.
  • Verificação de assinatura: Verifica os headers webhook-id, webhook-timestamp e webhook-signature com webhookKey, seguindo a especificação Standard Webhooks. Retorna 401 se a verificação falhar.
  • Validação do payload: Validado com Zod. Retorna 400 para payloads inválidos.
  • Tratamento de erros:
    • 401: Assinatura inválida
    • 400: Payload inválido
    • 500: Erro interno durante a verificação
  • Roteamento de eventos: Chama onPayload para cada evento, depois o handler correspondente ao tipo do evento, e retorna 200 quando eles terminam. O handler não captura erros lançados pelos seus handlers de eventos.

Handlers de eventos de webhook compatíveis

Todos os handlers são opcionais e assíncronos. Para conhecer o payload de cada evento, consulte o Guia de eventos de webhook.

Prompt para LLM

Última modificação em 26 de setembro de 2026