Skip to main content

Prerequisites

To integrate the Dodo Payments API, you’ll need:
  • A Dodo Payments merchant account
  • API credentials (API key and webhook secret key) from the dashboard
For a more detailed guide on the prerequisites, check this section.

API Integration

Checkout Sessions

Use Checkout Sessions to sell subscription products with a secure, hosted checkout. Pass your subscription product in product_cart and redirect customers to the returned checkout_url.
Mixed Checkout: You can combine subscription products with one-time products in the same checkout session. This enables use cases like setup fees with subscriptions, hardware bundles with SaaS, and more. See the Checkout Sessions guide for examples.

API Response

The following is an example of the response:
Redirecione o cliente para checkout_url.

Webhooks

Ao integrar assinaturas, você receberá webhooks para acompanhar o ciclo de vida da assinatura. Esses webhooks ajudam você a gerenciar estados de assinatura e cenários de pagamento de forma eficaz. Para configurar seu endpoint de webhook, siga nosso Guia de Integração Detalhado.

Tipos de Eventos de Assinatura

Os seguintes eventos de webhook acompanham as mudanças de status de assinatura:
  1. subscription.active - Assinatura ativada com sucesso.
  2. subscription.updated - Objeto de assinatura foi atualizado (acionado em qualquer alteração de campo).
  3. subscription.on_hold - Assinatura suspensa devido a falha na renovação.
  4. subscription.failed - Falha na criação da assinatura durante a criação do mandato.
  5. subscription.renewed - Assinatura renovada para o próximo período de cobrança.
Para uma gestão confiável do ciclo de vida da assinatura, recomendamos acompanhar esses eventos de assinatura.
Use subscription.updated para receber notificações em tempo real sobre qualquer alteração na assinatura, mantendo o estado do seu aplicativo em sincronia sem fazer polling na API.

Cenários de Pagamento

Fluxo de Pagamento Bem-Sucedido Os webhooks que você recebe e o momento em que são enviados dependem de o produto ter um período de teste. Cobrança imediata (0 dias de teste):
  1. subscription.active: o mandato é autorizado e a assinatura é ativada.
  2. payment.succeeded: confirma a primeira cobrança. Espere recebê-lo em 2 a 10 minutos após o checkout.
Com um período de teste:
  1. No início do teste (checkout): subscription.active é disparado assim que o método de pagamento é autorizado. Nenhuma cobrança recorrente é realizada ainda. A primeira cobrança real é adiada até o término do teste.
  2. No término do teste: o valor recorrente é cobrado, e você recebe payment.succeeded junto com subscription.renewed.
A cada renovação subsequente:
  • subscription.renewed: é disparado em cada ciclo de cobrança quando o pagamento da renovação é debitado, sempre junto com payment.succeeded. Ele também inclui o next_billing_date atualizado.
Sempre que um valor é realmente debitado para um produto de assinatura, você recebe subscription.renewed e payment.succeeded. Use subscription.renewed (em vez de usar apenas payment.succeeded) como sinal para estender o acesso para o próximo ciclo.
Cenários de falha de pagamento
  1. Falha na assinatura
  • subscription.failed - A criação da assinatura falhou porque não foi possível criar um mandato.
  • payment.failed - Indica um pagamento malsucedido.
  1. Assinatura suspensa
  • subscription.on_hold - A assinatura é suspensa devido a uma falha no pagamento da renovação ou na cobrança da alteração do plano.
  • Quando uma assinatura é suspensa, ela não será renovada automaticamente até que o método de pagamento seja atualizado.
Boa prática: para simplificar a implementação, recomendamos acompanhar principalmente os eventos da assinatura para gerenciar o ciclo de vida da assinatura.
Para obter um passo a passo completo sobre como ler error_code/error_message, decidir quando tentar novamente e apresentar as falhas aos clientes, consulte Como lidar com falhas de pagamento.

subscription.failed vs. subscription.on_hold

É fácil confundir esses dois eventos, mas eles exigem tratamentos muito diferentes:
subscription.failed é terminal. A assinatura não pode ser reativada. O cliente deve criar uma nova assinatura. Nunca conceda direitos quando esse evento for disparado.

Como lidar com uma assinatura suspensa

Quando uma assinatura entra no estado on_hold, você precisa atualizar o método de pagamento para reativá-la. Esta seção explica quando as assinaturas são suspensas e como lidar com elas.

Quando as assinaturas são suspensas

Uma assinatura é suspensa quando:
  • O pagamento da renovação falha: a cobrança automática da renovação falha devido a fundos insuficientes, cartão expirado ou recusa do banco
  • A cobrança da alteração do plano falha: uma cobrança imediata durante o upgrade ou downgrade do plano falha
  • A autorização do método de pagamento falha: não é possível autorizar o método de pagamento para cobranças recorrentes
Assinaturas no estado on_hold não serão renovadas automaticamente. Você deve atualizar o método de pagamento para reativar a assinatura.

Reativando assinaturas suspensas

Para reativar uma assinatura no estado on_hold, use a API Update Payment Method. Isso automaticamente:
  1. Cria uma cobrança pelos valores pendentes
  2. Gera uma fatura para a cobrança
  3. Processa o pagamento usando o novo método de pagamento
  4. Reativa a assinatura para o estado active após o pagamento bem-sucedido
1

Handle subscription.on_hold webhook

Ao receber um webhook subscription.on_hold, atualize o estado da sua aplicação e notifique o cliente:
2

Update payment method

Quando o cliente estiver pronto para atualizar o método de pagamento, chame a API Update Payment Method:
Você também pode usar um ID de método de pagamento existente se o cliente tiver métodos de pagamento salvos:
3

Monitor webhook events

Após atualizar o método de pagamento, monitore estes eventos de webhook:
  1. payment.succeeded - A cobrança pelos valores pendentes foi bem-sucedida
  2. subscription.active - A assinatura foi reativada

Exemplo de payload de evento de assinatura


Alterando planos de assinatura

Você pode fazer upgrade ou downgrade de um plano de assinatura usando o endpoint da API de alteração de plano. Isso permite modificar o produto, a quantidade e tratar o rateio proporcional da assinatura.

Change Plan API Reference

Para obter informações detalhadas sobre como alterar planos de assinatura, consulte nossa documentação da API Change Plan.

Opções de rateio proporcional

Ao alterar planos de assinatura, você tem duas opções para tratar a cobrança imediata:

1. prorated_immediately

  • Calcula o valor proporcional com base no tempo restante do ciclo de cobrança atual
  • Cobra do cliente apenas a diferença entre o plano antigo e o novo
  • Durante um período de teste, isso muda imediatamente o usuário para o novo plano, cobrando o cliente na hora

2. full_immediately

  • Cobra do cliente o valor integral da assinatura do novo plano
  • Ignora qualquer tempo ou crédito restante do plano anterior
  • Útil quando você deseja redefinir o ciclo de cobrança ou cobrar o valor integral independentemente do rateio proporcional

3. difference_immediately

  • Ao fazer upgrade, o cliente é cobrado imediatamente pela diferença entre os valores dos dois planos.
  • Por exemplo, se o plano atual custa 30 dólares e o cliente fizer upgrade para um plano de 80 dólares, serão cobrados $50 instantaneamente.
  • Ao fazer downgrade, o valor não utilizado do plano atual é adicionado como crédito interno e aplicado automaticamente às futuras renovações da assinatura.
  • Por exemplo, se o plano atual custa 50 dólares e o cliente mudar para um plano de 20 dólares, os $30 restantes serão creditados e usados no próximo ciclo de cobrança.

4. do_not_bill

  • Aplica a alteração do plano imediatamente, mas não cobra nada no momento da alteração.
  • O plano atualizado (e a quantidade/add-ons) será cobrado na próxima renovação programada, e a data de cobrança original será preservada.
Todos os três modos de “cobrar agora” redefinem o ciclo de cobrança. prorated_immediately, difference_immediately e full_immediately movem o next_billing_date da assinatura para a data da alteração. Somente do_not_bill mantém a data de renovação original, mas não aplica nenhuma cobrança imediata.

Comportamento

  • Quando você chama esta API, Dodo Payments inicia imediatamente uma cobrança com base na opção de rateio proporcional selecionada
  • Se a alteração do plano for um downgrade e você usar prorated_immediately, os créditos serão calculados e adicionados automaticamente ao saldo de créditos da assinatura. Esses créditos são específicos dessa assinatura e serão usados somente para compensar pagamentos recorrentes futuros da mesma assinatura
  • A opção full_immediately ignora os cálculos de crédito e cobra o valor integral do novo plano
Escolha cuidadosamente a opção de rateio proporcional: use prorated_immediately para uma cobrança justa que considere o tempo não utilizado ou full_immediately quando quiser cobrar o valor integral do novo plano independentemente do ciclo de cobrança atual.

Processamento da cobrança

  • A cobrança imediata iniciada após a alteração do plano geralmente termina de ser processada em menos de 2 minutos
  • Se essa cobrança imediata falhar por qualquer motivo, a assinatura será automaticamente suspensa até que o problema seja resolvido

Assinaturas sob demanda

As assinaturas sob demanda permitem cobrar dos clientes com flexibilidade, e não apenas em uma programação fixa. Esse recurso está disponível para todas as contas.
Para criar uma assinatura sob demanda: Para criar uma assinatura sob demanda, use o endpoint da API POST /subscriptions e inclua o campo on_demand no corpo da solicitação. Isso permite autorizar um método de pagamento sem uma cobrança imediata ou definir um preço inicial personalizado. Para cobrar uma assinatura sob demanda: Para cobranças subsequentes, use o endpoint POST /subscriptions//charge e especifique o valor a ser cobrado do cliente nessa transação.
Para obter um guia completo e passo a passo (incluindo exemplos de solicitação/resposta, políticas de nova tentativa seguras e tratamento de webhooks), consulte o Guia de assinaturas sob demanda.

Principais informações sobre a cobrança de assinaturas

Defina o período da assinatura como maior que a frequência de pagamento. Se o período da assinatura for igual à frequência de pagamento (por exemplo, período = 1 mês, frequência = 1 mês), a assinatura será válida por um único ciclo e passará para expired em vez de ser renovada. Para um plano mensal contínuo, defina um período de assinatura longo (por exemplo, 20 anos) com uma frequência de pagamento mensal.
A moeda é definida na primeira cobrança bem-sucedida. Sempre informe billing_currency e billing_address.country explicitamente ao criar o checkout. Se omitidos, eles serão detectados a partir do IP do cliente (Adaptive Currency); depois que a assinatura receber sua primeira cobrança, a moeda será fixada durante toda a sua vigência. Um cliente que viajar posteriormente não poderá alterá-la.
Os períodos de teste fazem uma autorização de $0, não uma cobrança. Quando uma assinatura tem um período de teste, o início do teste cria uma autorização de mandato de $0 para salvar o cartão; a primeira cobrança real ocorre quando o teste termina. Na lista de pagamentos, uma assinatura em período de teste exibe exatamente um pagamento com amount: 0.
Ciclo de vida da assinatura: on_hold = uma renovação falhou (recuperável: solicite ao cliente que atualize o método de pagamento; novas tentativas de cobrança são aplicadas). expired = o período terminou sem renovação e não pode ser reativado. O cliente deve assinar novamente. cancelled = encerrada pelo cliente ou pelo merchant. A maioria das falhas de renovação são recusas do emissor (fundos insuficientes, cartão recusado), não um erro da Dodo.
Cartões indianos usam um e-mandato do RBI. Cobranças off-session (renovações e cobranças de alteração de plano) podem levar até aproximadamente 48 horas para serem liquidadas, e débitos automáticos recorrentes acima de ₹15.000 exigem uma nova autenticação do cliente (portanto, um upgrade que ultrapasse esse limite não pode usar o mandato existente). Enquanto uma cobrança ainda estiver processing, uma segunda cobrança na mesma assinatura falhará com “Cannot create new charge as previous payment is not successful yet.” Cartões de fora da Índia são confirmados quase instantaneamente.
As cobranças de assinatura têm um mínimo de $1 (ou o equivalente na moeda). Valores de $0.01–$0.99 são rejeitados com product_price: value out of range; somente $0 é permitido, por meio de uma configuração sob demanda mandate_only.

Referência de API relacionada

Create Subscription

Referência da API para criar produtos de assinatura e gerenciar o ciclo de vida das assinaturas

Change Subscription Plan

Referência da API para fazer upgrade, downgrade ou alterar planos de assinatura com opções de rateio proporcional

Update Payment Method

Referência da API para atualizar métodos de pagamento e reativar assinaturas suspensas

Patch Subscription

Referência da API para atualizar detalhes e configurações de assinaturas
Última modificação em 31 de julho de 2026