@dodopayments/bun fornece três handlers de requisição ao seu servidor Bun. 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 padrão e retorna um Response, portanto você o chama a partir do handler fetch de Bun.serve().
Checkout Handler
Crie URLs de checkout com fluxos estáticos, dinâmicos e de sessão de checkout.
Customer Portal
Permita que os clientes gerenciem suas assinaturas e seus dados.
Webhooks
Receba e processe eventos de webhook do Dodo Payments.
Instalação
1
Install the Package
Execute este comando na raiz do seu projeto:O pacote também requer
zod 3.25 ou posterior, listado como uma peer dependency.2
Set Up Environment Variables
Crie um arquivo O Bun lê arquivos
.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:.env automaticamente, portanto os exemplos leem esses valores de process.env. 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 usam live_mode. Uma API key do modo de teste funciona somente com test_mode.Exemplos de handlers de rota
Todos os exemplos usam o servidor nativo do Bun,
Bun.serve(), e encaminham as requisições por caminho e método no handler fetch.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Use este handler para adicionar o checkout do Dodo Payments ao seu servidor Bun. O handler estático atende requisições
GET. Os handlers de sessão e dinâmico atendem requisições POST. O exemplo de checkout dinâmico pressupõe que o servidor retorne dynamicCheckoutHandler(request) para requisições POST.Handler de rota de checkout
O handler de checkout é compatível com as três formas de receber pagamentos com o Dodo Payments:- Links de pagamento estáticos: URLs compartilháveis que coletam pagamentos sem código.
- Links de pagamento dinâmicos: links de pagamento gerados por você com dados personalizados. Eles usam endpoints deprecated.
- Sessões de checkout: checkout hospedado com carrinho de produtos, dados do cliente e opções de personalização. Este é o fluxo recomendado.
Checkout aceita estas opções:
O handler fornece checkout estático para requisições
GET. Para requisições POST, ele cria um link de pagamento dinâmico quando type é dynamic e uma sessão de checkout nos demais casos.
Static Checkout (GET)
Static Checkout (GET)
Parâmetros de consulta compatíveis
string
obrigatório
Identificador do produto, por exemplo
?productId=pdt_xxx.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
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 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 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 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.email com disableEmail=true. O handler adiciona returnUrl da sua configuração ao link como redirect_url.Formato da resposta
O checkout estático retorna uma resposta JSON com a URL de checkout. No modo de teste, a URL usatest.checkout.dodopayments.com:Dynamic Checkout (POST)
Dynamic Checkout (POST)
- Envie os parâmetros como um corpo JSON em uma requisição POST.
- Compatível com 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(comstreet,city,state,countryezipcode) ecustomer, além deproduct_idouproduct_cart. As assinaturas precisam deproduct_id. - Para cada campo de corpo compatível, consulte:
Formato da resposta
O checkout dinâmico retorna uma resposta JSON com o link de pagamento como URL de checkout:Checkout Sessions (POST)
Checkout Sessions (POST)
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 e precisa de pelo menos um produto. Se o corpo não tiver return_url, o handler usará returnUrl da sua configuração.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.Para obter mais detalhes e consultar todos os campos compatíveis, veja o Guia de integração de sessões de checkout.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 informado e redireciona o navegador para ela.CustomerPortal aceita as mesmas opções bearerToken e environment que Checkout.
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, o Dodo Payments também enviará o link do portal por e-mail ao cliente.customer_id estiver ausente e 500 se não for possível criar a sessão do portal.
Handler de rota de webhook
O handler de rota de webhook verifica cada requisição com o secret do seu webhook, passado comowebhookKey, antes de executar seu código:
- Método: somente requisições POST são compatíveis. Outros métodos retornam 405.
- Verificação de assinatura: verifica os headers
webhook-id,webhook-timestampewebhook-signaturecomwebhookKey, seguindo a especificação Standard Webhooks. Retorna 401 se a verificação falhar. - Validação do payload: analisa o corpo como JSON e o valida com Zod. Retorna 400 para JSON inválido ou payload inválido.
- Tratamento de erros:
- 401: assinatura inválida
- 400: payload inválido
- 500: erro interno durante a verificação
- Encaminhamento de eventos: chama
onPayloadpara cada evento, depois o handler correspondente ao tipo do evento, e retorna 200.
Bun.serve() e a requisição falha.