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 |
- Un paiement de renouvellement d’abonnement échoue et l’abonnement passe à
on_hold.
- 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.
- Les relances sont effectuées hors session selon un calendrier de repli, limité par votre fenêtre de récupération.
- 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.
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 |
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. |
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. |
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. |
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 (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. 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 :
- La transaction est B2B (
b2b = true)
- Un
tax_id est présent
- 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 :
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'
});
| 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.
Corrections de Bugs & Améliorations
- Corrections de bugs mineurs et améliorations de la stabilité sur l’ensemble de la plateforme.
