Skip to main content

Pré-requisitos

Antes de começar, você precisa de:
  • Uma conta de comerciante do Dodo Payments
  • Uma chave de API em Developer → API Keys no dashboard, armazenada em DODO_PAYMENTS_API_KEY
  • Um segredo de webhook em Developer → Webhooks, armazenado em DODO_PAYMENTS_WEBHOOK_KEY
  • Pelo menos um produto de assinatura criado em Products
Para obter mais detalhes, consulte Pré-requisitos do Guia de Integração.

Integração da API

Sessões de Checkout

Crie uma assinatura construindo uma sessão de checkout com seu produto de assinatura. O cliente autoriza uma forma de pagamento e a assinatura é ativada quando ele conclui o checkout.
Você pode combinar um produto de assinatura com produtos avulsos na mesma sessão de checkout. Isso permite taxas de configuração, pacotes de hardware com SaaS e casos de uso semelhantes. Consulte Checkout Sessions para ver exemplos.Você também pode vender dois ou mais produtos de assinatura em um único checkout. O cliente paga uma vez e obtém uma assinatura independente para cada produto, cada uma com seu próprio ciclo de cobrança. Esse carrinho não pode conter produtos avulsos. Consulte Multi-Subscription Cart.

Resposta da API

A resposta inclui um checkout_url:
Redirecione o cliente para esta URL. Ele autoriza o método de pagamento e a assinatura é ativada.

Webhooks

Os webhooks notificam seu servidor quando ocorrem eventos de assinatura. Configure seu endpoint em Developer → Webhooks no dashboard. Para configurar seu endpoint de webhook, consulte Webhooks.

Tipos de eventos de assinatura

Monitore estes eventos para gerenciar o ciclo de vida da assinatura:
  1. subscription.active — A assinatura é ativada
  2. subscription.updated — Um campo da assinatura foi alterado
  3. subscription.on_hold — Uma cobrança de renovação ou alteração de plano falhou
  4. subscription.failed — A criação da assinatura falhou (terminal; o cliente precisa assinar novamente)
  5. subscription.renewed — Uma cobrança recorrente foi bem-sucedida
  6. subscription.past_due — Uma renovação falhou e o período de carência começou; o cliente mantém o acesso até past_due_ends_at
  7. subscription.plan_changed — O plano foi atualizado, rebaixado ou alterado
  8. subscription.cancelled — A assinatura foi cancelada
  9. subscription.expired — A assinatura chegou ao fim do prazo
Esses são os eventos principais. Para ver a lista completa, incluindo paused, unpaused e update_payment_method, consulte Subscription Webhooks.
Use subscription.updated para receber notificações em tempo real sobre quaisquer alterações na assinatura, mantendo o estado da sua aplicação sincronizado sem fazer polling da API.

Cenários de pagamento

Fluxo de pagamento bem-sucedido A sequência de webhooks depende de a assinatura ter ou não 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 dentro de 2–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 fim do teste.
  2. No fim do teste: o valor recorrente é cobrado, e você recebe payment.succeeded junto com subscription.renewed.
A cada renovação subsequente:
  • subscription.renewed: é disparado a cada ciclo de cobrança quando o pagamento da renovação é debitado, sempre junto com payment.succeeded. Ele também contém o next_billing_date atualizado.
Sempre que um valor é efetivamente debitado por 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. Se sua empresa tiver um período de carência, uma renovação malsucedida primeiro move a assinatura para past_due (subscription.past_due), e ela é movida para on_hold (ou cancelled, dependendo das configurações do período de carência) somente quando o período termina. Consulte Subscription States.
  • Quando uma assinatura é suspensa, ela não será renovada automaticamente até que o método de pagamento seja atualizado.
Prática recomendada: para simplificar a implementação, recomendamos acompanhar principalmente os eventos de assinatura para gerenciar o ciclo de vida da assinatura.
Para obter um guia completo sobre como ler error_code/error_message, decidir quando tentar novamente e informar as falhas aos clientes, consulte Handle Payment Failures.

subscription.failed versus 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 precisa 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 a atualização ou o rebaixamento 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ê precisa atualizar o método de pagamento para reativar a assinatura.

Reativação de 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

Quando 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

Depois de 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


Alteração de planos de assinatura

Você pode atualizar ou rebaixar um plano de assinatura usando o endpoint da API de alteração de plano. Isso permite modificar o produto, a quantidade e lidar com o rateio da assinatura.

Change Plan API Reference

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

Opções de rateio

Ao alterar planos de assinatura, você tem quatro opções para lidar com a cobrança imediata:

1. prorated_immediately

  • Credita a parte não utilizada do ciclo de cobrança atual, rateada pelo tempo restante. O crédito cobre o plano básico, a quantidade e quaisquer complementos
  • Em seguida, cobra um ciclo completo no novo plano, quantidade e complementos. A cobrança em si nunca é rateada
  • Cobrança imediata líquida = (novo ciclo completo) menos (fração restante x ciclo antigo completo). Se o crédito for maior, a diferença é mantida como crédito vinculado à assinatura para futuras renovações
  • 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 total da assinatura do novo plano, sem crédito pelo ciclo anterior
  • Tanto em uma atualização quanto em um rebaixamento, o cliente paga o preço integral do novo plano desde o início
  • É útil quando você quer cobrar o valor total independentemente de quanto tempo restava no plano antigo

3. difference_immediately

  • O cliente paga apenas a diferença entre o preço do plano antigo e o preço do novo plano
  • O valor não depende de quando no ciclo a alteração é feita. A mesma atualização custa o mesmo no dia 1 e no dia 29
  • Ao atualizar, o cliente é cobrado imediatamente pela diferença. Por exemplo, $30/mês → $80/mês = $50 cobrados instantaneamente
  • Ao rebaixar, a diferença de preço é armazenada como crédito vinculado à assinatura e aplicada automaticamente a futuras renovações. Por exemplo, $50/mês → $20/mês = $30 armazenados como crédito

4. do_not_bill

  • Aplica a alteração do plano imediatamente, mas não cobra nada no momento da alteração. O novo plano, a quantidade e os complementos podem ser usados imediatamente
  • Como nada é cobrado agora, uma atualização oferece ao cliente o plano superior gratuitamente pelo restante do ciclo atual. Um rebaixamento entra em vigor imediatamente, sem crédito pela parte não utilizada do ciclo já pago
  • Complementos concedidos por meio de do_not_bill não são creditados em uma alteração posterior de plano, pois nunca foram cobrados. Uma alteração subsequente cobra integralmente a nova quantidade de complementos
  • O plano atualizado (e a quantidade/os complementos) é cobrado na próxima renovação programada, e a data de cobrança original é preservada
Os três modos de “cobrar agora” reiniciam 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 essa API, Dodo Payments inicia imediatamente uma cobrança com base na opção de rateio selecionada
  • Com prorated_immediately, um crédito pela parte não utilizada do ciclo atual é calculado a cada alteração, seja atualização ou rebaixamento. Se esse crédito exceder a cobrança do novo ciclo, o restante será adicionado ao saldo de crédito da assinatura. Esses créditos são específicos dessa assinatura e só serão usados para compensar pagamentos recorrentes futuros da mesma assinatura
  • Com difference_immediately, o valor líquido é sempre exatamente a diferença de preço. Para rebaixamentos, o excedente é armazenado como crédito vinculado à assinatura, assim como em prorated_immediately
  • A opção full_immediately ignora os cálculos de crédito e cobra o valor total do novo plano
  • A opção do_not_bill aplica a alteração imediatamente, mas adia a cobrança até a próxima data de renovação, que é preservada
Escolha de um modo de rateio:
  • difference_immediately — o cliente paga a diferença de preço. É a opção mais previsível; a cobrança é a mesma independentemente de quando no ciclo a alteração é feita.
  • prorated_immediately — o cliente recebe crédito apenas pelo tempo não utilizado do ciclo atual. A cobrança varia conforme o momento do ciclo em que a alteração ocorre.
  • full_immediately — o cliente paga o valor total do novo plano. Não há crédito pelo ciclo anterior.
  • do_not_bill — nenhuma cobrança agora. O novo plano é cobrado na próxima renovação. É o único modo que preserva a data de cobrança original.

Processamento da cobrança

  • A cobrança imediata iniciada após a alteração do plano normalmente conclui o processamento 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 de forma flexível, 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 /checkouts e inclua o campo subscription_data.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.
POST /subscriptions está obsoleto. Ele ainda funciona para integrações existentes, mas novas integrações devem criar assinaturas sob demanda por meio de uma Checkout Session (POST /checkouts) com subscription_data.on_demand. Consulte o On-Demand Subscriptions Guide para conhecer o fluxo atual.
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 passo a passo (incluindo exemplos de solicitações/respostas, políticas seguras de novas tentativas e tratamento de webhooks), consulte o On-Demand Subscriptions Guide.

Pontos importantes 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 então 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 é bloqueada 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 pelo IP do cliente (Adaptive Currency), e, assim que a assinatura realizar sua primeira cobrança, a moeda será fixada por toda a sua duração. Um cliente que viajar posteriormente não poderá alterá-la.
Os testes gratuitos 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 teste gratuito exibe exatamente um pagamento com total_amount igual a 0. Um teste pago cobra antecipadamente seu trial_amount.
Ciclo de vida da assinatura: past_due = uma renovação falhou e o período de carência está em andamento (o cliente mantém o acesso). on_hold = uma renovação falhou (recuperável: solicite ao cliente que atualize o método de pagamento; novas tentativas de cobrança se aplicam). expired = o prazo terminou sem renovação e não pode ser reativado. O cliente precisa 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 do Dodo.
Cartões indianos funcionam com um e-mandate 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, uma atualização 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 não indianos são confirmados quase instantaneamente.
As assinaturas têm um mínimo de $1,00 em USD. O checkout rejeita um total inferior com TOTAL_PAYMENT_AMOUNT_BELOW_MINIMUM_AMOUNT. Moedas diferentes de USD, EUR e GBP também devem valer pelo menos $1,00; consulte Minimum Amounts. Uma cobrança sob demanda product_price inferior a 100 na menor unidade da moeda é rejeitada com product_price: value out of range. Um produto de assinatura com preço exatamente igual a $0 é permitido; consulte Card-Optional at Zero Price. Para autorizar um cartão sem cobrá-lo, use uma configuração on-demand mandate_only.

Referência de API relacionada

Create Subscription (Deprecated)

API legada para criar uma assinatura diretamente. Use Checkout Sessions para novas integrações

Change Subscription Plan

Referência da API para atualizar, rebaixar ou alterar planos de assinatura com opções de rateio

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 da assinatura
Última modificação em 8 de outubro de 2026