> ## 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.101.0 (2 de junho de 2026)
> Repetição automática de pagamentos de assinatura para recuperar receita de renovações falhadas, padrões de prorrateamento em nível de negócios com substituições por coleção de produtos e coleta de nome comercial para faturas B2B — além de correções de bugs e melhorias.
## Novos Recursos
### 1. **Repetição de Pagamento de Assinatura**
Pagamentos de **renovação** de assinatura falhados agora podem ser repetidos automaticamente para recuperar a receita, sem necessidade de integração. Ative em **Configurações → Recuperação**, defina uma janela de recuperação e o Dodo Payments repetirá a renovação em um cronograma inteligente até que tenha sucesso ou a janela seja fechada.
| Configuração | Descrição | Padrão |
| ------------------------------------ | ------------------------------------------------------------------------------------------------ | ------------------- |
| **Habilitar Repetição de Pagamento** | Repetir automaticamente pagamentos de renovação de assinatura falhados para recuperar a receita. | Desativado (opt-in) |
| **Janela de Recuperação (dias)** | Quanto tempo tentar repetir um pagamento falhado antes de desistir (1–30). | 13 |
**Como funciona**
1. Um pagamento de renovação de assinatura falha e a assinatura muda para `on_hold`.
2. Se a recusa for repetível (uma recusa suave, como fundos insuficientes ou um erro temporário de rede), a próxima tentativa é agendada automaticamente.
3. As tentativas ocorrem fora da sessão em um cronograma de recuo, limitado pela sua janela de recuperação.
4. Na primeira repetição bem-sucedida, a assinatura retorna para `active` e a próxima data de cobrança é avançada normalmente.
**Cronograma de tentativas**
As tentativas recuam progressivamente, ancoradas no momento em que a fatura falhada foi criada. Até **8 tentativas** são feitas, desde que se encaixem na sua janela de recuperação:
| Tentativa | Atraso após a anterior |
| --------- | ---------------------- |
| 1 | 12 horas |
| 2 | 24 horas |
| 3 | 48 horas |
| 4 | 72 horas |
| 5 | 96 horas |
| 6 | 120 horas |
| 7 | 7 dias |
| 8 | 7 dias |
Apenas **recusas suaves** são repetidas (por exemplo, fundos insuficientes, recusa genérica, erros de processamento ou rede). **Recusas duras** encerram a cadeia de repetições imediatamente, pois repetir não mudará o resultado.
Isso complementa as ferramentas de recuperação existentes — **Cobrança de Assinatura** envia emails ao cliente para atualizar seu método de pagamento, enquanto Repetição de Pagamento tenta novamente silenciosamente o método existente. Eles funcionam bem juntos.
Saiba mais: [Repetição de Pagamento de Assinatura](/features/recovery/payment-retries) | [Cobrança de Assinatura](/features/recovery/subscription-dunning)
### 2. **Configurações de Prorrateamento de Negócios**
Agora você pode definir o **comportamento padrão de upgrade e downgrade** uma vez no nível do negócio, em vez de passar parâmetros de prorrateamento em cada alteração de plano. Esses padrões se aplicam sempre que um cliente muda seu plano pelo portal do cliente, e você pode **substituí-los por coleção de produtos**.
Cada direção (upgrade e downgrade) tem dois controles independentes, além de uma política compartilhada de falha de pagamento:
| Configuração | Campo | Padrão (upgrade) | Padrão (downgrade) |
| ------------------------------------ | --------------------------------------------------------------------------- | ------------------------ | ------------------------ |
| **Quando o novo plano começa** | `effective_at_on_upgrade` / `effective_at_on_downgrade` | `immediately` | `next_billing_date` |
| **Como o cliente é cobrado** | `proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade` | `difference_immediately` | `difference_immediately` |
| **Se o pagamento do cliente falhar** | `on_payment_failure` | `apply_change` | `apply_change` |
**Quando o novo plano começa** (`effective_at`)
| Valor | Comportamento |
| ------------------- | ------------------------------------------------------------------------------------------ |
| `immediately` | O cliente muda para o novo plano imediatamente. |
| `next_billing_date` | O cliente permanece no plano atual até a próxima data de cobrança, então muda para o novo. |
**Como o cliente é cobrado** (`proration_billing_mode`)
| Valor | Comportamento |
| ------------------------ | ---------------------------------------------------------------------------------------- |
| `prorated_immediately` | Cobrar um valor prorateado agora, com base no tempo restante no ciclo de cobrança atual. |
| `full_immediately` | Cobrar o preço total do novo plano agora mesmo. |
| `difference_immediately` | Cobrar apenas a diferença de preço entre o novo plano e o atual. |
| `do_not_bill` | Não cobrar nada agora. Qualquer ajuste é aplicado na próxima fatura. |
**Se o pagamento do cliente falhar** (`on_payment_failure`)
| Valor | Comportamento |
| ---------------- | --------------------------------------------------------------------------------------------------------------- |
| `prevent_change` | Manter o cliente no plano atual se o pagamento não for concluído. |
| `apply_change` | Mudar o cliente para o novo plano mesmo se o pagamento não for concluído. Você pode coletar o valor mais tarde. |
**Substituições por coleção**
Cada coleção de produtos pode substituir qualquer um desses padrões. Cada campo é independente — deixe em **Herdar do negócio** para seguir o padrão do negócio, ou defina um valor explícito para substituí-lo apenas para aquela coleção.
Cada configuração é resolvida nesta ordem:
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
Um valor por solicitação passado para a [API de Troca de Plano](/api-reference/subscriptions/change-plan) (`proration_billing_mode`, `effective_at`, `on_payment_failure`) sempre tem precedência sobre os padrões de coleção e de negócios. As novas configurações apenas mudam o que acontece quando nenhum valor explícito é fornecido — que é o caso para todas as mudanças de plano via portal do cliente.
Saiba mais: [Upgrade & Downgrade de Assinatura](/developer-resources/subscription-upgrade-downgrade) | [Coleções de Produtos](/features/product-collections)
### 3. **Coletar Nome da Empresa para Faturas B2B**
Clientes B2B agora podem ter seu **nome comercial legal** exibido na fatura em vez do nome pessoal do comprador. Quando um ID Fiscal válido é fornecido no checkout, você também pode coletar o `customer_business_name` associado para que a fatura reflita a entidade compradora.
Quando o cliente seleciona **Comprando como empresa** no checkout, é solicitado a ele tanto o **Nome da Empresa** quanto um **Número de ID Fiscal**.
O nome da empresa aparece na fatura apenas quando **todas as três** condições são atendidas:
1. A transação é B2B (`b2b = true`)
2. Um `tax_id` está presente
3. Um `customer_business_name` não vazio é fornecido
Caso contrário, o nome pessoal do cliente é usado.
**Coletando no checkout**
Defina `customer_business_name` diretamente, e/ou ative `allow_customer_editing_business_name` para permitir que o cliente insira ou edite no checkout juntamente com o ID Fiscal:
```typescript theme={null}
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
customer: { email: 'buyer@acme.com' },
tax_id: 'GB123456789',
customer_business_name: 'Acme Corp Ltd',
feature_flags: {
allow_tax_id: true,
allow_customer_editing_business_name: true // let the customer enter/edit it
},
return_url: 'https://yoursite.com/return'
});
```
**Onde se aplica**
| Superfície | Campo | Notas |
| ------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------- |
| Sessões de Checkout | `customer_business_name`, `feature_flags.allow_customer_editing_business_name` | Máx. 250 caracteres; opção padrão para `false` |
| Pagamentos | `customer_business_name` | Máx. 250 caracteres |
| Assinaturas | `customer_business_name` | Defina ou limpe via `PATCH /subscriptions/{id}` |
`customer_business_name` não pode ser definido sem um `tax_id`. Enviar um nome comercial sem ID Fiscal é rejeitado. Limpar o `tax_id` também limpa o nome comercial, pois os dois estão acoplados na fatura.
Espaços em branco ao redor são removidos, e valores compostos apenas por espaços em branco são tratados como uma limpeza explícita — assim, os dados armazenados sempre correspondem ao que é exibido na fatura.
Saiba mais: [Pagamentos B2B](/features/b2b-payments) | [Gestão de Faturas](/features/invoice-generation) | [Sessão de Checkout](/developer-resources/checkout-session)
## Correções de Bugs e Melhorias
* Correções de bugs menores e melhorias de estabilidade em toda a plataforma.