> ## 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 juin 2026)
> Relances automatiques de paiement d'abonnement pour récupérer les revenus de renouvellement échoués, paramètres de proratisation au niveau de l'entreprise avec dérogations par collection de produits et collecte du nom commercial pour les factures B2B — plus des corrections de bugs et des améliorations.
## Nouvelles Fonctionnalités
### 1. **Relances de Paiement d'Abonnement**
Les paiements de **renouvellement** d'abonnement échoués peuvent maintenant être relancés automatiquement pour récupérer les revenus, sans nécessité de travail d'intégration. Activez-le depuis **Paramètres → Récupération**, définissez une fenêtre de récupération et Dodo Payments relance le renouvellement selon un calendrier intelligent jusqu'à ce qu'il réussisse ou que la fenêtre se ferme.
| Paramètre | Description | Par défaut |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------- | ------------------ |
| **Activer les relances de paiement** | Relancer automatiquement les paiements de renouvellement d'abonnement échoués pour récupérer les revenus. | Désactivé (opt-in) |
| **Fenêtre de récupération (jours)** | Durée pendant laquelle essayer de relancer un paiement échoué avant d'abandonner (1–30). | 13 |
**Comment ça fonctionne**
1. Un paiement de renouvellement d'abonnement échoue et l'abonnement passe à `on_hold`.
2. Si le refus est relançable (un refus temporaire tel que des fonds insuffisants ou une erreur réseau temporaire), la prochaine tentative est programmée automatiquement.
3. Les relances sont effectuées hors session selon un calendrier de repli, limité par votre fenêtre de récupération.
4. Lors de la première relance réussie, l'abonnement revient à `active` et la prochaine date de facturation est avancée normalement.
**Calendrier de relance**
Les relances se rétractent progressivement, ancrées au moment où la facture échouée a été créée. Jusqu'à **8 tentatives** sont effectuées, tant qu'elles rentrent dans votre fenêtre de récupération :
| Tentative | Délai après la précédente |
| --------- | ------------------------- |
| 1 | 12 heures |
| 2 | 24 heures |
| 3 | 48 heures |
| 4 | 72 heures |
| 5 | 96 heures |
| 6 | 120 heures |
| 7 | 7 jours |
| 8 | 7 jours |
Seules les **déclinaisons douces** sont relancées (par ex. fonds insuffisants, refus générique, erreurs de traitement ou réseau). Les **déclinaisons dures** interrompent immédiatement la chaîne de relance, car relancer ne changerait pas le résultat.
Cela complète les outils de récupération existants — **Subscription Dunning** envoie un e-mail au client pour mettre à jour son mode de paiement, tandis que Payment Retries retente discrètement l'existant. Ils fonctionnent bien ensemble.
En savoir plus : [Subscription Payment Retries](/features/recovery/payment-retries) | [Subscription Dunning](/features/recovery/subscription-dunning)
### 2. **Paramètres de Proratisation d'Entreprise**
Vous pouvez maintenant définir le **comportement par défaut de l'upgrade et downgrade** au niveau de l'entreprise au lieu de passer des paramètres de proratisation à chaque changement de plan. Ces paramètres par défaut s'appliquent chaque fois qu'un client change son plan depuis le portail client, et vous pouvez **les remplacer par collection de produits**.
Chaque direction (upgrade et downgrade) a deux contrôles indépendants, plus une politique d'échec de paiement partagée :
| Paramètre | Champ | Par défaut (mise à niveau) | Par défaut (rétrogradation) |
| ----------------------------------- | --------------------------------------------------------------------------- | -------------------------- | --------------------------- |
| **Quand le nouveau plan commence** | `effective_at_on_upgrade` / `effective_at_on_downgrade` | `immediately` | `next_billing_date` |
| **Comment le client est facturé** | `proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade` | `difference_immediately` | `difference_immediately` |
| **Si le paiement du client échoue** | `on_payment_failure` | `apply_change` | `apply_change` |
**Quand le nouveau plan commence** (`effective_at`)
| Valeur | Comportement |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| `immediately` | Le client passe immédiatement au nouveau plan. |
| `next_billing_date` | Le client reste sur son plan actuel jusqu'à la prochaine date de facturation, puis passe au nouveau. |
**Comment le client est facturé** (`proration_billing_mode`)
| Valeur | Comportement |
| ------------------------ | -------------------------------------------------------------------------------------------------------- |
| `prorated_immediately` | Facturer un montant proratisé maintenant, basé sur le temps restant dans le cycle de facturation actuel. |
| `full_immediately` | Facturer immédiatement le prix total du nouveau plan. |
| `difference_immediately` | Facturer uniquement la différence de prix entre le nouveau plan et l'actuel. |
| `do_not_bill` | Ne rien facturer maintenant. Tout ajustement est appliqué sur la prochaine facture. |
**Si le paiement du client échoue** (`on_payment_failure`)
| Valeur | Comportement |
| ---------------- | -------------------------------------------------------------------------------------------------------------------- |
| `prevent_change` | Garder le client sur son plan actuel si le paiement n'est pas effectué. |
| `apply_change` | Passer le client au nouveau plan même si le paiement n'est pas effectué. Vous pouvez collecter le montant plus tard. |
**Remplacements par collection**
Chaque collection de produits peut remplacer l'un de ces paramètres par défaut. Chaque champ est indépendant — laissez-le sur **Hériter de l'entreprise** pour suivre le paramètre par défaut de l'entreprise, ou définissez une valeur explicite pour le remplacer uniquement pour cette collection.
Chaque paramètre est résolu dans cet ordre :
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
Une valeur par demande passée à l'[API de changement de plan](/api-reference/subscriptions/change-plan) (`proration_billing_mode`, `effective_at`, `on_payment_failure`) prend toujours le pas sur les paramètres par défaut de la collection et de l'entreprise. Les nouveaux paramètres ne changent ce qui se passe que lorsqu'aucune valeur explicite n'est fournie — ce qui est le cas pour tous les changements de plan du portail client.
En savoir plus : [Subscription Upgrade & Downgrade](/developer-resources/subscription-upgrade-downgrade) | [Product Collections](/features/product-collections)
### 3. **Collecter le Nom Commercial pour les Factures B2B**
Les clients B2B peuvent maintenant voir leur **nom commercial légal** apparaître sur la facture à la place du nom personnel de l'acheteur. Lorsqu'un numéro de TVA valide est fourni lors de la commande, vous pouvez également collecter le `customer_business_name` associé afin que la facture reflète l'entité acheteuse.
Lorsque le client sélectionne **Achat en tant qu'entreprise** lors de la commande, il est invité à fournir à la fois un **Nom de l'entreprise** et un **Numéro ID TVA**.
Le nom commercial apparaît sur la facture uniquement lorsque **toutes** les trois conditions sont remplies :
1. La transaction est B2B (`b2b = true`)
2. Un `tax_id` est présent
3. Un `customer_business_name` non vide est fourni
Sinon, le nom personnel du client est utilisé.
**Le collecter à la commande**
Définissez `customer_business_name` directement, et/ou activez `allow_customer_editing_business_name` pour permettre au client de le saisir ou de le modifier sur la page de commande avec son numéro de TVA :
```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'
});
```
**Où cela s'applique**
| Surface | Champ | Remarques |
| -------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------- |
| Sessions de paiement | `customer_business_name`, `feature_flags.allow_customer_editing_business_name` | Max 250 caractères ; drapeau par défaut `false` |
| Paiements | `customer_business_name` | Max 250 caractères |
| Abonnements | `customer_business_name` | Définir ou effacer via `PATCH /subscriptions/{id}` |
`customer_business_name` ne peut pas être défini sans un `tax_id`. L'envoi d'un nom commercial sans ID TVA est rejeté. Le nettoyage du `tax_id` efface également le nom commercial, car les deux sont couplés sur la facture.
Les espaces blancs environnants sont supprimés, et les valeurs uniquement composées d'espaces sont traitées comme un effacement explicite — de sorte que les données stockées correspondent toujours à celles rendues sur la facture.
En savoir plus : [B2B Payments](/features/b2b-payments) | [Invoice Management](/features/invoice-generation) | [Checkout Session](/developer-resources/checkout-session)
## Corrections de Bugs & Améliorations
* Corrections de bugs mineurs et améliorations de la stabilité sur l'ensemble de la plateforme.