Skip to main content
O pacote @dodopayments/remix fornece três handlers de requisição para seu app Remix. 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. Cada handler recebe um Request e retorna um Response, então você o chama a partir de loader ou action de uma rota.

Checkout Handler

Crie URLs de checkout a partir do seu app Remix.

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 o Remix 2 (remix 2.16.8 ou posterior) e o zod 3.25 ou posterior como peer dependencies.
2

Set Up Environment Variables

Crie um arquivo .env na raiz do seu projeto:
Crie a chave de API em Developer → API Keys. Adicione seu endpoint de webhook em Developer → Webhooks e copie o segredo de assinatura 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 ambiente, os handlers usarão live_mode.
Nunca faça commit do arquivo .env nem de segredos no controle de versão.

Exemplos de Route Handlers

Os exemplos são resource routes do Remix, que exportam um loader para requisições GET ou um action para requisições POST, sem um componente. Com flat file routes, app/routes/api.checkout.tsx fornece /api/checkout.
Use este handler para adicionar o checkout do Dodo Payments ao seu app Remix. O loader fornece o checkout estático. O action fornece o checkout dinâmico aqui. Para fornecer sessões de checkout, o fluxo recomendado, retorne checkoutSessionHandler(request) de action.
A solicitação de sessão de checkout funciona quando action retorna checkoutSessionHandler(request).

Checkout Route Handler

O handler de checkout é compatível com as três formas de receber 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 obsoletos.
  • 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:

Parâmetros de Query 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
Linha do 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 desabilitar o campo de nome completo.
boolean
Defina como true para desabilitar o campo de primeiro nome.
boolean
Defina como true para desabilitar o campo de sobrenome.
boolean
Defina como true para desabilitar o campo de e-mail.
boolean
Defina como true para desabilitar o campo de país.
boolean
Defina como true para desabilitar o campo de linha do endereço.
boolean
Defina como true para desabilitar o campo de cidade.
boolean
Defina como true para desabilitar o campo de estado.
boolean
Defina como true para desabilitar o campo de CEP.
string
Moeda do pagamento, por exemplo USD.
boolean
padrão:"true"
Mostra ou oculta o seletor de moeda.
number
Fixa o valor cobrado, em unidades principais da moeda, por exemplo 12.5 para $12.50. Funciona apenas 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 query que comece com metadata_ é passado como metadata.
O handler adiciona returnUrl da configuração ao link como redirect_url.
Se productId estiver ausente, o handler retorna uma resposta 400. Parâmetros de query inválidos e IDs de produtos 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 usa como proxy os endpoints obsoletos 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 configuração.Para obter mais detalhes e ver todos os campos compatíveis, consulte o Guia de Integração de Checkout Sessions.Uma sessão criada com payment_method_id não retorna uma URL de checkout, então o handler responde com 400. Para cobrar um método de pagamento salvo, 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 route handler do Customer Portal cria uma sessão do Customer Portal para o cliente informado e redireciona o navegador para ela com uma resposta 307.
O handler não verifica quem está fazendo a chamada. Qualquer pessoa que o solicite com um ID de cliente obterá o portal desse cliente. Proteja a rota com sua própria autenticação e passe apenas o ID de cliente do usuário autenticado.

Parâmetros de Query

string
obrigatório
O ID do cliente para a 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 route handler de webhook verifica cada requisição antes de executar seu código:
  • Método: Apenas requisições POST são compatíveis. Outros métodos retornam 405.
  • Verificação de assinatura: Verifica o corpo bruto da requisiçã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.
  • Validação do payload: Valida o payload com Zod. Retorna 400 para um payload inválido.
  • 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.
O adaptador não captura erros lançados nos seus handlers. Eles são propagados para o Remix, e a requisiçã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 Guia de Eventos de Webhook.

Prompt para LLM

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