> ## 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 junio de 2026)
> Reintentos de pago de suscripción automáticos para recuperar ingresos por renovaciones fallidas, prorrateo por defecto a nivel empresarial con excepciones por colección de productos, y recolección del nombre comercial para facturas B2B — además de correcciones de errores y mejoras.
## Nuevas Características
### 1. **Reintentos de Pago de Suscripción**
Los pagos de **renovación** de suscripción fallidos ahora pueden ser reintentados automáticamente para recuperar ingresos, sin requerir integración. Actívalo desde **Configuración → Recuperación**, establece un periodo de recuperación, y Dodo Payments reintenta la renovación en un horario inteligente hasta que tenga éxito o el periodo termine.
| Configuración | Descripción | Predeterminado |
| ---------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------- |
| **Activar Reintentos de Pago** | Reintentar automáticamente los pagos de renovación de suscripción fallidos para recuperar ingresos. | Desactivado (opt-in) |
| **Ventana de recuperación (días)** | Cuánto tiempo seguir intentando un pago fallido antes de rendirse (1–30). | 13 |
**Cómo funciona**
1. Un pago de renovación de suscripción falla y la suscripción pasa a `on_hold`.
2. Si el rechazo es reintentable (un rechazo suave como fondos insuficientes o un error de red temporal), el siguiente intento se programa automáticamente.
3. Los reintentos se realizan fuera de sesión en un horario escalonado, limitado por tu ventana de recuperación.
4. En el primer reintento exitoso, la suscripción vuelve a `active` y la siguiente fecha de facturación se adelanta de manera normal.
**Horario de reintentos**
Los reintentos retroceden progresivamente, anclados al momento en que se creó la factura fallida. Se hacen hasta **8 intentos**, siempre que entren dentro de tu ventana de recuperación:
| Intento | Retraso después del anterior |
| ------- | ---------------------------- |
| 1 | 12 horas |
| 2 | 24 horas |
| 3 | 48 horas |
| 4 | 72 horas |
| 5 | 96 horas |
| 6 | 120 horas |
| 7 | 7 días |
| 8 | 7 días |
Solo se reintentan los **rechazos suaves** (p. ej. fondos insuficientes, rechazo genérico, errores de procesamiento o red). Los **rechazos duros** terminan inmediatamente la cadena de reintentos, ya que reintentarlos no cambiará el resultado.
Esto complementa las herramientas de recuperación existentes — **Subscription Dunning** envía un correo al cliente para actualizar su método de pago, mientras que Payment Retries reintenta silenciosamente el existente. Funcionan bien juntos.
Más información: [Reintentos de Pago de Suscripción](/features/recovery/payment-retries) | [Subscription Dunning](/features/recovery/subscription-dunning)
### 2. **Configuración de Prorrateo Empresarial**
Ahora puedes establecer el **comportamiento predeterminado de actualización y degradación** una vez a nivel empresarial en lugar de pasar parámetros de prorrateo en cada cambio de plan. Estos valores predeterminados se aplican siempre que un cliente cambia su plan desde el portal del cliente, y puedes **anularlos por colección de productos**.
Cada dirección (actualización y degradación) tiene dos controles independientes, además de una política de fallo de pago compartida:
| Configuración | Campo | Predeterminado (actualización) | Predeterminado (degradación) |
| -------------------------------- | --------------------------------------------------------------------------- | ------------------------------ | ---------------------------- |
| **Cuándo inicia el nuevo plan** | `effective_at_on_upgrade` / `effective_at_on_downgrade` | `immediately` | `next_billing_date` |
| **Cómo se cobra al cliente** | `proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade` | `difference_immediately` | `difference_immediately` |
| **Si el pago del cliente falla** | `on_payment_failure` | `apply_change` | `apply_change` |
**Cuándo inicia el nuevo plan** (`effective_at`)
| Valor | Comportamiento |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| `immediately` | El cliente pasa al nuevo plan de inmediato. |
| `next_billing_date` | El cliente permanece en su plan actual hasta la próxima fecha de facturación, luego cambia al nuevo. |
**Cómo se cobra al cliente** (`proration_billing_mode`)
| Valor | Comportamiento |
| ------------------------ | ------------------------------------------------------------------------------------------------------ |
| `prorated_immediately` | Cobrar ahora una cantidad prorrateada, basada en el tiempo restante en el ciclo de facturación actual. |
| `full_immediately` | Cobrar el precio completo del nuevo plan ahora mismo. |
| `difference_immediately` | Cobrar solo la diferencia de precio entre el nuevo plan y el actual. |
| `do_not_bill` | No cobrar nada ahora. Cualquier ajuste se aplica en la próxima factura. |
**Si el pago del cliente falla** (`on_payment_failure`)
| Valor | Comportamiento |
| ---------------- | -------------------------------------------------------------------------------------------------- |
| `prevent_change` | Mantener al cliente en su plan actual si el pago no se procesa. |
| `apply_change` | Pasar al cliente al nuevo plan incluso si el pago no se procesa. Puedes cobrar el monto más tarde. |
**Excepciones por colección**
Cada colección de productos puede anular cualquiera de estos valores predeterminados. Cada campo es independiente — déjalo en **Heredar de la empresa** para seguir el valor predeterminado de la empresa, o establece un valor explícito para anularlo solo para esa colección.
Cada configuración se resuelve en este orden:
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
Un valor por solicitud pasado a la [API de Cambio de Plan](/api-reference/subscriptions/change-plan) (`proration_billing_mode`, `effective_at`, `on_payment_failure`) siempre tiene prioridad sobre los valores predeterminados de la colección y la empresa. Las nuevas configuraciones solo cambian lo que sucede cuando no se suministra un valor explícito, que es el caso para todos los cambios de plan en el portal del cliente.
Más información: [Actualización y Degradación de Suscripción](/developer-resources/subscription-upgrade-downgrade) | [Colecciones de Productos](/features/product-collections)
### 3. **Recoger Nombre de Empresa para Facturas B2B**
Los clientes B2B ahora pueden tener su **nombre comercial legal** en la factura en lugar del nombre personal del comprador. Cuando se proporciona un ID Fiscal válido al finalizar la compra, también puedes recopilar el asociado `customer_business_name` para que la factura refleje la entidad compradora.
Cuando el cliente selecciona **Comprando como empresa** al finalizar la compra, se le solicita tanto un **Nombre de Empresa** como un **Número de ID Fiscal**.
El nombre de la empresa aparece en la factura solo cuando se cumplen **las tres** condiciones:
1. La transacción es B2B (`b2b = true`)
2. Se presenta un `tax_id`
3. Se proporciona un `customer_business_name` no vacío
De lo contrario, se usa el nombre personal del cliente.
**Recogiéndolo al finalizar la compra**
Configura `customer_business_name` directamente, y/o habilita `allow_customer_editing_business_name` para permitir que el cliente lo ingrese o edite en la página de pago junto a su 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'
});
```
**Dónde se aplica**
| Superficie | Campo | Notas |
| ---------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------ |
| Sesiones de Pago | `customer_business_name`, `feature_flags.allow_customer_editing_business_name` | Máx. 250 caracteres; la bandera por defecto es `false` |
| Pagos | `customer_business_name` | Máx. 250 caracteres |
| Suscripciones | `customer_business_name` | Establecer o borrar vía `PATCH /subscriptions/{id}` |
`customer_business_name` no se puede configurar sin un `tax_id`. Enviar un nombre comercial sin un ID Fiscal es rechazado. Borrar el `tax_id` también borra el nombre comercial, ya que están acoplados en la factura.
El espacio en blanco circundante se recorta, y los valores que solo contienen espacio en blanco se tratan como un claro explícito, por lo que los datos almacenados siempre coinciden con lo que se ve en la factura.
Más información: [Pagos B2B](/features/b2b-payments) | [Gestión de Facturas](/features/invoice-generation) | [Sesión de Pago](/developer-resources/checkout-session)
## Correcciones de Errores y Mejoras
* Correcciones de errores menores y mejoras de estabilidad en toda la plataforma.