> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# v1.112.0 (5 de agosto de 2026)
> Os códigos de desconto agora oferecem descontos por valor, agendamento, regras de elegibilidade de clientes e opções por moeda, junto com uma experiência nativa de webhooks reconstruída com alertas por e-mail — além de Cash App Pay para assinaturas, SEPA Direct Debit para pagamentos únicos em EUR, mensagens de falha de pagamento mais claras para clientes, webhooks de payout, alteração autônoma do e-mail de login, uma configuração que permite que clientes cancelem suas próprias assinaturas e um filtro de moeda na lista de pagamentos.
## Novos recursos
### 1. **Códigos de desconto: descontos por valor, agendamento e regras de elegibilidade**
Os códigos de desconto não são mais limitados a percentuais. Agora, um código pode deduzir um valor fixo, começar conforme um agendamento, ter preços diferentes por moeda e restringir quem pode resgatá-lo.
**Descontos por valor**
Defina `type` como `flat` para deduzir um valor fixo em vez de um percentual. A dedução é acumulada em todo o carrinho, em vez de ser aplicada a cada item de linha.
| Tipo | Valor da API | Comportamento |
| ---------- | ------------ | ----------------------------------------------------------------- |
| Percentual | `percentage` | Reduz o preço por um percentual, opcionalmente limitado por moeda |
| Valor | `flat` | Deduz um valor fixo, acumulado em todo o carrinho |
**Opções por moeda**
`currency_options` permite que um único código funcione corretamente em todas as moedas que você vende. Cada entrada define, para uma única moeda, o desconto máximo (a própria dedução para um código de valor, um limite para um código percentual) e o valor mínimo do carrinho. Um desconto por valor exige pelo menos uma opção de moeda com um padrão resolvível; as opções de moeda permanecem opcionais para descontos percentuais.
**Elegibilidade de clientes**
`customer_eligibility` controla quem pode resgatar um código:
| Valor | Quem pode resgatar |
| ------------ | ----------------------------------------------------------- |
| `any` | Qualquer cliente. Este é o padrão. |
| `first_time` | Clientes que nunca compraram de você. |
| `existing` | Clientes que já compraram de você. |
| `specific` | Somente clientes que você adicionar à allow list do código. |
Gerencie a allow list no dashboard ou com os novos endpoints: `GET /discounts/{discount_id}/customers` para listar os clientes associados, `POST /discounts/{discount_id}/customers` para associá-los e `DELETE /discounts/{discount_id}/customers/{customer_id}` para remover um deles.
Um código `specific` começa com **zero** clientes elegíveis e rejeita todos os resgates até que você associe clientes a ele.
**Agendamento e limites por cliente**
Defina `starts_at` para agendar o lançamento de um código — deixá-lo vazio mantém o código ativo imediatamente, e ele deve ser estritamente anterior a `expires_at`. Use `per_customer_usage_limit` para limitar a frequência com que um único cliente pode resgatar um código, como um limite separado que não pode exceder o `usage_limit` geral.
Um valor mínimo do carrinho é sempre medido com base nos preços originais do carrinho, nunca no total acumulado durante a aplicação de uma sequência. Portanto, a ordem de aplicação nunca altera se um mínimo foi atingido.
Saiba mais: [Descontos](/features/discount-codes) | [Criar desconto](/api-reference/discounts/create-discount)
### 2. **Uma experiência de webhooks reconstruída**
A seção de webhooks do dashboard foi reconstruída como uma experiência nativa, substituindo o portal incorporado. Agora tudo fica dentro do dashboard, com tabelas, filtros e navegação consistentes, funcionando corretamente em dispositivos móveis.
* **Endpoints** — crie e edite endpoints em um painel lateral, escolha tipos de evento em uma árvore pesquisável e veja rapidamente a taxa de erros das últimas 24 horas.
* **Atividade e logs** — acompanhe as tentativas de entrega ao longo do tempo no gráfico **Atividade de entrega**, navegue pelas mensagens entregues e abra uma página de **detalhes da mensagem** para inspecionar o payload e cada tentativa de entrega, com seu código de resposta e duração. Cada tentativa pode ser reproduzida a partir daí.
* **Catálogo de eventos** — navegue por todos os tipos de evento enviados pela Dodo Payments, com seu schema e um payload de exemplo.
* **Visão geral do endpoint** — estatísticas de entrega das últimas 24 horas, o signing secret para visualizar ou alternar e o **Histórico de reproduções**.
* **Testes** — envie um evento de exemplo para um endpoint para verificar seu receiver antes de entrar em produção.
* **Avançado** — limite a entrega, gerencie os cabeçalhos personalizados enviados com cada solicitação para esse endpoint e edite sua transformação.
* **Reprodução em massa** — em um endpoint, recupere mensagens com falha, reproduza as que nunca foram despachadas ou reproduza um intervalo filtrado.
* **Alertas por e-mail** — uma nova aba de **Configurações**, na qual você pode listar os endereços que devem receber e-mails quando as entregas para um endpoint começarem a falhar. Separe vários endereços com vírgulas e deixe o campo vazio para desativar os alertas.
Esta é apenas uma alteração no dashboard. Seus endpoints existentes, signing secrets, verificação de assinaturas, nomes de eventos e payloads não foram alterados — nenhuma alteração de integração é necessária.
Saiba mais: [Webhooks](/developer-resources/webhooks) | [Eventos de webhook](/developer-resources/webhooks/intents/webhook-events-guide)
### 3. **Cash App Pay para assinaturas**
Agora o Cash App Pay pode ser usado em uma assinatura recorrente, não apenas em um pagamento único. Ele está disponível em checkouts nos EUA cobrados em USD, junto com as opções de cartão existentes.
Saiba mais: [Carteiras digitais](/features/payment-methods/digital-wallets)
### 4. **SEPA Direct Debit**
O SEPA Direct Debit agora está disponível em toda a Zona do Euro, permitindo que clientes paguem diretamente de suas contas bancárias em vez de usar um cartão. Ele é oferecido em checkouts em EUR para pagamentos únicos.
O SEPA Direct Debit não é instantâneo. Um pagamento leva **6 dias úteis** para ser confirmado, portanto não trate a autorização como liquidação — conclua o atendimento somente quando o pagamento atingir o estado succeeded.
Saiba mais: [Métodos de pagamento europeus](/features/payment-methods/europe)
### 5. **Mensagens de falha de pagamento mais claras**
Quando um pagamento falha, você e seu cliente agora veem um texto escrito para esse propósito, em vez do texto bruto do processador. Cada falha é resolvida por meio de uma taxonomia de **46 códigos de erro unificados**, cada um associado a dois públicos:
* **Você** vê um título e uma ação recomendada no pagamento, para saber se deve pedir ao cliente que tente novamente, entre em contato com o banco ou use outro cartão. `error_message` no objeto Payment agora contém esse texto sempre que `error_code` for um código unificado reconhecido.
* **Seu cliente** vê uma explicação em linguagem simples na tela de falha do checkout, no Customer Portal e nos e-mails de dunning — por exemplo, *"O código de segurança do seu cartão (CVC) parece incorreto. Insira-o novamente e tente outra vez."*
Para recusas sensíveis a fraude — `FRAUDULENT`, `LOST_CARD`, `STOLEN_CARD` e `PICKUP_CARD` — o cliente sempre vê uma mensagem genérica, para que o motivo real nunca seja exposto. Você continua vendo o motivo verdadeiro, sinalizado com um aviso para não compartilhá-lo.
Saiba mais: [Falhas de transação](/api-reference/transaction-failures) | [Pagamentos](/features/transactions/payments) | [Obter detalhes do pagamento](/api-reference/payments/get-payments-1)
### 6. **Permita que clientes cancelem suas próprias assinaturas**
**Permitir cancelamento de assinatura** agora é uma configuração de primeira classe na aba **Assinaturas** das configurações do dashboard, e é aplicada de ponta a ponta. Quando você a desativa, o Customer Portal desabilita o botão de cancelamento e a API rejeita o cancelamento iniciado pelo cliente com um `403` — tanto o cancelamento imediato quanto o fluxo de "cancelar na próxima data de cobrança". Antes, a configuração apenas ocultava o botão, então um cliente determinado ainda poderia cancelar pela API.
A configuração fica **habilitada por padrão**. Seus próprios cancelamentos pela merchant API e pelo dashboard nunca são afetados, e um cliente sempre pode revogar um cancelamento que já tenha agendado.
Saiba mais: [Customer Portal](/features/customer-portal) | [Assinaturas](/features/subscription)
### 7. **Webhooks de payout**
Agora você recebe webhooks para seus próprios payouts, podendo conciliá-los em seus sistemas contábeis sem fazer polling.
| Evento | Disparado quando |
| -------------------- | ------------------------------------------------------------------------------- |
| `payout.created` | Um payout é criado pelo ciclo automático de payouts ou fora do ciclo |
| `payout.in_progress` | A data de vencimento do payout chega e o processamento começa |
| `payout.on_hold` | O payout é pausado ou colocado em análise |
| `payout.success` | O payout para sua conta bancária é liquidado |
| `payout.failed` | O payout falha, e o valor e as tarifas são creditados novamente em sua carteira |
`payout.created` era emitido anteriormente como `payout.not_initiated`. Se um endpoint existente filtrar por `payout.not_initiated`, atualize o filtro para `payout.created` para que ele continue correspondendo. O campo `status` no payload ainda informa `not_initiated` nesta etapa.
Saiba mais: [Webhooks de payout](/developer-resources/webhooks/intents/payout) | [Processo de payouts](/features/payouts/payout-structure)
### 8. **Altere seu e-mail de login pelo dashboard**
Agora você pode alterar o endereço de e-mail usado para entrar, sem entrar em contato com o suporte. A aba Conta foi redesenhada e inclui uma nova seção **Alterar e-mail**, com um botão **Alterar e-mail** que inicia o fluxo.
A verificação ocorre em duas etapas: enviamos um código para seu endereço **atual** para confirmar que é você e, em seguida, um segundo código para seu endereço **novo** para confirmar que você tem controle sobre ele. Depois que ambos forem verificados:
* Entre com o novo endereço a partir de então. O endereço anterior deixa de funcionar para senhas, magic links e códigos enviados por e-mail.
* Todos os identity providers vinculados, como o login do Google ou GitHub, são desvinculados e precisam ser reconectados.
* Sua senha, empresas, acesso da equipe e status de verificação permanecem inalterados.
* Uma notificação é enviada para o endereço anterior, para que uma alteração inesperada nunca passe despercebida.
Saiba mais: [Minha conta](/miscellaneous/accounts)
### 9. **Analytics: novos widgets e refinamentos**
Com base na reconstrução do Analytics v3, esta versão adiciona novas visualizações e aprimora as existentes.
* **A receita por país agora é um mapa coroplético em largura total**, com a lista de países ordenada ao lado, e o card pode ser compartilhado como os demais.
* **Gráficos de tendência redesenhados**, com cursor crosshair ao passar o mouse, um marcador de data móvel no eixo x e um tooltip compacto.
* **Novas predefinições de data** — **Últimos 30 dias** substitui Últimas 4 semanas, e **Últimos 6 meses** entra na lista.
* **Seus filtros permanecem.** A predefinição de data e o modo de comparação agora persistem por empresa e acompanham você entre dispositivos, em vez de serem redefinidos para os padrões a cada sessão.
* **Os principais clientes são identificados pelo nome**, usando o e-mail como fallback.
* A receita por país agora retorna até os **150 principais** países.
Saiba mais: [Analytics do dashboard](/features/analytics-and-reporting)
## Melhorias e correções de bugs
### 10. **Filtre pagamentos por moeda**
`GET /payments` aceita um parâmetro de consulta opcional **`currency`**, para que você possa listar apenas os pagamentos liquidados em uma determinada moeda — por exemplo, `GET /payments?currency=EUR`. O mesmo filtro está disponível na tabela Payments do dashboard.
Saiba mais: [Listar pagamentos](/api-reference/payments/get-payments)
### 11. **Janela de resposta a disputas ampliada para 10 dias**
Agora você tem **10 dias** para responder a uma disputa depois que ela é criada, em vez de 4. A contagem regressiva da disputa no dashboard e o prazo de resposta retornado pela API refletem a janela maior.
Saiba mais: [Disputas](/features/transactions/disputes)
### 12. **Formulários de conta bancária para payouts mais claros**
Adicionar uma conta bancária para payouts ficou menos ambíguo. Os rótulos dos campos, as descrições e as dicas de ferramenta agora se adaptam ao tipo da sua empresa, evitando que os nomes do titular da conta e do beneficiário pareçam duplicados para empresários individuais. Ao escolher **Outro** como seu banco, você pode digitar o nome livremente; o código bancário doméstico da China é identificado como **CNAPS**; e a página de payouts permanece visível no modo de teste, para que você possa acessar suas contas vinculadas em qualquer um dos modos.
Saiba mais: [Processo de payouts](/features/payouts/payout-structure)
### Outras correções e melhorias
* **Os créditos de alteração de plano são revertidos quando um pagamento falha.** Os créditos de proration emitidos durante uma alteração de plano de assinatura não permanecem quando o pagamento resultante não é bem-sucedido.
* **As faturas de testes pagos mostram a cobrança do teste**, não o preço recorrente regular.
* **Os descontos percentuais respeitam o valor mínimo do carrinho**, medido com base no preço inicial, e não no total acumulado; além disso, um timeout de bloqueio de desconto agora retorna um código de erro distinto em vez de um `503` genérico.
* **Excluir um método de pagamento já removido agora é bem-sucedido**, em vez de retornar um erro, tornando a chamada seguramente idempotente.
* **Corrigida a moeda usada para o limite mínimo do mandato na Índia** ao atualizar o método de pagamento de uma assinatura.
* **Entradas do ledger de créditos além dos limites permitidos** são rejeitadas com um `400` tipado, em vez de falharem posteriormente.
* **Produtos pay-what-you-want aceitam um valor fixo** em links de checkout compartilhados, e os IDs de entitlement são exibidos no painel de detalhes do entitlement.
* Correções no Analytics: séries de valor vitalício, add-ons incluídos no MRR, ausência de comparação de período em intervalos de todos os tempos, séries que terminam no bucket atual e rótulos de intervalo e comparação mais claros.
* Pequenas correções de bugs e melhorias de estabilidade em toda a plataforma.