> ## 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 août 2026)
> Les codes de réduction prennent désormais en charge les remises d'un montant fixe, la planification, les règles d'éligibilité des clients et les options par devise, parallèlement à une expérience native des webhooks entièrement repensée avec alertes par e-mail — ainsi que Cash App Pay pour les abonnements, SEPA Direct Debit pour les paiements EUR ponctuels, des messages d'échec de paiement plus clairs pour les clients, les webhooks de versement, la modification autonome de l'adresse e-mail de connexion, un paramètre permettant aux clients d'annuler eux-mêmes leurs abonnements et un filtre par devise pour les paiements listés.
## Nouvelles fonctionnalités
### 1. **Codes de réduction : remises d'un montant fixe, planification et règles d'éligibilité**
Les codes de réduction ne se limitent plus aux pourcentages. Un code peut désormais déduire un montant fixe, commencer selon un calendrier, appliquer un prix différent pour chaque devise et limiter les personnes autorisées à l'utiliser.
**Remises d'un montant fixe**
Définissez `type` sur `flat` pour déduire un montant fixe plutôt qu'un pourcentage. La déduction est regroupée sur l'ensemble du panier au lieu d'être appliquée à chaque ligne.
| Type | Valeur API | Comportement |
| ----------- | ------------ | -------------------------------------------------------------------------- |
| Pourcentage | `percentage` | Réduit le prix d'un pourcentage, avec éventuellement un plafond par devise |
| Montant | `flat` | Déduit un montant fixe, regroupé sur l'ensemble du panier |
**Options par devise**
`currency_options` permet à un même code de fonctionner correctement dans toutes les devises que vous vendez. Chaque entrée définit, pour une devise donnée, la remise maximale (la déduction elle-même pour un code de type Montant, un plafond pour un code de type Pourcentage) et la valeur minimale du panier. Une remise d'un montant fixe nécessite au moins une option de devise avec une valeur par défaut résolvable ; les options par devise restent facultatives pour les remises en pourcentage.
**Éligibilité des clients**
`customer_eligibility` contrôle les personnes autorisées à utiliser un code :
| Valeur | Qui peut l'utiliser |
| ------------ | -------------------------------------------------------------------------- |
| `any` | Tout client. Il s'agit de la valeur par défaut. |
| `first_time` | Les clients qui n'ont encore rien acheté chez vous. |
| `existing` | Les clients qui ont déjà acheté chez vous. |
| `specific` | Uniquement les clients que vous ajoutez à la liste d'autorisation du code. |
Gérez la liste d'autorisation depuis le tableau de bord ou avec les nouveaux endpoints : `GET /discounts/{discount_id}/customers` pour lister les clients associés, `POST /discounts/{discount_id}/customers` pour les associer et `DELETE /discounts/{discount_id}/customers/{customer_id}` pour en dissocier un.
Un code `specific` commence avec **zéro** client éligible et refuse toute utilisation tant que vous ne lui avez pas associé de clients.
**Planification et limites par client**
Définissez `starts_at` pour planifier le lancement futur d'un code — si vous ne le définissez pas, le code reste immédiatement actif, et cette valeur doit être strictement antérieure à `expires_at`. Utilisez `per_customer_usage_limit` pour limiter le nombre d'utilisations d'un code par un même client, comme plafond distinct qui ne peut pas dépasser la valeur globale `usage_limit`.
La valeur minimale du panier est toujours calculée à partir des prix d'origine du panier, jamais du total intermédiaire après l'application partielle d'une combinaison de remises. L'ordre d'application ne change donc jamais le fait qu'un minimum soit atteint.
En savoir plus : [Remises](/features/discount-codes) | [Créer une remise](/api-reference/discounts/create-discount)
### 2. **Une expérience des webhooks entièrement repensée**
La section webhooks du tableau de bord a été reconstruite comme une expérience native, en remplacement du portail intégré. Tout se trouve désormais dans le tableau de bord, avec des tableaux, des filtres et une navigation cohérents, et fonctionne correctement sur mobile.
* **Endpoints** — créez et modifiez des endpoints dans un panneau latéral, sélectionnez les types d'événements dans un arbre de recherche et consultez d'un coup d'œil le taux d'erreur des dernières 24 heures.
* **Activité et journaux** — suivez les tentatives de livraison au fil du temps sur le graphique **Activité des livraisons**, parcourez les messages livrés et ouvrez une page de **détails du message** pour examiner la payload et chaque tentative de livraison avec son code de réponse et sa durée. Chaque tentative peut y être rejouée.
* **Catalogue des événements** — parcourez tous les types d'événements envoyés par Dodo Payments, avec leur schéma et un exemple de payload.
* **Vue d'ensemble de l'endpoint** — statistiques de livraison des dernières 24 heures, secret de signature à afficher ou à faire pivoter et **Historique des rejoués**.
* **Tests** — envoyez un événement exemple à un endpoint pour vérifier votre récepteur avant la mise en production.
* **Avancé** — limitez le débit des livraisons, gérez les en-têtes personnalisés envoyés avec chaque requête vers cet endpoint et modifiez sa transformation.
* **Rejeu groupé** — depuis un endpoint, récupérez les messages échoués, rejouez ceux qui n'ont jamais été distribués ou rejouez une plage filtrée.
* **Alertes par e-mail** — un nouvel onglet **Paramètres** permet de lister les adresses auxquelles envoyer un e-mail lorsque les livraisons vers un endpoint commencent à échouer. Séparez plusieurs adresses par des virgules et laissez le champ vide pour désactiver les alertes.
Il s'agit uniquement d'une modification du tableau de bord. Vos endpoints existants, secrets de signature, vérifications de signature, noms d'événements et payloads restent inchangés — aucune modification d'intégration n'est nécessaire.
En savoir plus : [Webhooks](/developer-resources/webhooks) | [Événements webhook](/developer-resources/webhooks/intents/webhook-events-guide)
### 3. **Cash App Pay pour les abonnements**
Cash App Pay peut désormais financer un abonnement récurrent, et pas seulement un paiement ponctuel. Il est disponible lors des checkouts américains facturés en USD, aux côtés des options de carte existantes.
En savoir plus : [Portefeuilles numériques](/features/payment-methods/digital-wallets)
### 4. **SEPA Direct Debit**
SEPA Direct Debit est désormais disponible dans toute la zone euro, ce qui permet aux clients de payer directement depuis leur compte bancaire plutôt qu'avec une carte. Il est proposé lors des checkouts en EUR pour les paiements ponctuels.
SEPA Direct Debit n'est pas instantané. Un paiement prend **6 jours ouvrés** à être confirmé ; ne considérez donc pas l'autorisation comme un règlement — n'exécutez la commande qu'une fois le paiement passé à l'état réussi.
En savoir plus : [Moyens de paiement européens](/features/payment-methods/europe)
### 5. **Des messages d'échec de paiement plus clairs**
Lorsqu'un paiement échoue, vous et votre client voyez désormais un texte rédigé à cet effet plutôt que le texte brut du processeur. Chaque échec est associé à une taxonomie de **46 codes d'erreur unifiés**, chacun étant destiné à deux audiences :
* **Vous** voyez un titre et une action recommandée sur le paiement, afin de savoir s'il faut demander au client de réessayer, de contacter sa banque ou d'utiliser une autre carte. `error_message` sur l'objet Payment contient désormais ce texte lorsque `error_code` correspond à un code unifié reconnu.
* **Votre client** voit une explication en langage clair sur l'écran d'échec du checkout, dans le Customer Portal et dans les e-mails de relance — par exemple : *"Le code de sécurité de votre carte (CVC) ne semble pas correct. Veuillez le saisir à nouveau, puis réessayer."*
Pour les refus sensibles à la fraude — `FRAUDULENT`, `LOST_CARD`, `STOLEN_CARD` et `PICKUP_CARD` — le client voit toujours un message générique afin que la véritable raison ne soit jamais divulguée. Vous voyez toujours la véritable raison, accompagnée d'un avertissement vous indiquant de ne pas la communiquer.
En savoir plus : [Échecs de transaction](/api-reference/transaction-failures) | [Paiements](/features/transactions/payments) | [Obtenir les détails du paiement](/api-reference/payments/get-payments-1)
### 6. **Permettre aux clients d'annuler eux-mêmes leurs abonnements**
**Autoriser l'annulation d'un abonnement** est désormais un paramètre de premier ordre sous l'onglet **Abonnements** des paramètres du tableau de bord, et il est appliqué de bout en bout. Lorsque vous le désactivez, le Customer Portal désactive le bouton d'annulation et l'API refuse l'annulation initiée par le client avec une `403` — qu'il s'agisse de l'annulation immédiate ou de l'option « annuler à la prochaine date de facturation ». Auparavant, le paramètre masquait uniquement le bouton ; un client déterminé pouvait donc toujours annuler via l'API.
Le paramètre est **activé par défaut**. Vos propres annulations via l'API marchand et le tableau de bord ne sont jamais affectées, et un client peut toujours révoquer une annulation qu'il a déjà planifiée.
En savoir plus : [Customer Portal](/features/customer-portal) | [Abonnements](/features/subscription)
### 7. **Webhooks de versement**
Vous recevez désormais des webhooks pour vos propres versements, ce qui vous permet de les rapprocher dans vos systèmes comptables sans effectuer de polling.
| Événement | Déclenché lorsque |
| -------------------- | -------------------------------------------------------------------------------------------- |
| `payout.created` | Un versement est créé, par le cycle automatique ou hors cycle |
| `payout.in_progress` | La date d'échéance du versement arrive et le traitement commence |
| `payout.on_hold` | Le versement est suspendu ou placé sous vérification |
| `payout.success` | Le versement sur votre compte bancaire est réglé |
| `payout.failed` | Le versement échoue et le montant ainsi que les frais sont recrédités sur votre portefeuille |
`payout.created` était précédemment émis sous la forme `payout.not_initiated`. Si un endpoint existant filtre sur `payout.not_initiated`, mettez le filtre à jour avec `payout.created` afin qu'il continue de correspondre. Le champ `status` de la payload indique toujours `not_initiated` à ce stade.
En savoir plus : [Webhooks de versement](/developer-resources/webhooks/intents/payout) | [Processus des versements](/features/payouts/payout-structure)
### 8. **Modifier votre e-mail de connexion depuis le tableau de bord**
Vous pouvez désormais modifier l'adresse e-mail utilisée pour vous connecter sans contacter le support. L'onglet Compte a été repensé et comprend une nouvelle section **Modifier l'adresse e-mail**, avec un bouton **Modifier l'e-mail** qui lance le processus.
La vérification se déroule en deux étapes : nous envoyons un code à votre adresse **actuelle** pour confirmer votre identité, puis un second code à votre **nouvelle** adresse pour confirmer que vous la contrôlez. Une fois les deux adresses vérifiées :
* Vous vous connectez désormais avec la nouvelle adresse. L'ancienne adresse ne fonctionne plus pour les mots de passe, les liens magiques et les codes envoyés par e-mail.
* Les fournisseurs d'identité associés, tels que Google ou GitHub, sont dissociés et doivent être reconnectés.
* Votre mot de passe, vos entreprises, vos accès d'équipe et votre statut de vérification restent inchangés.
* Une notification est envoyée à votre ancienne adresse afin qu'une modification inattendue ne passe jamais inaperçue.
En savoir plus : [Mon compte](/miscellaneous/accounts)
### 9. **Analyses : nouveaux widgets et améliorations**
S'appuyant sur la refonte d'Analytics v3, cette version ajoute de nouvelles visualisations et améliore les visualisations existantes.
* **Les revenus par pays sont désormais affichés sur une carte choroplèthe pleine largeur**, avec la liste des pays classés à côté ; la carte peut être partagée comme les autres éléments.
* **Graphiques de tendance redessinés** avec survol par réticule, pastille de date glissante sur l'axe x et infobulle compacte.
* **Nouveaux préréglages de dates** — **30 derniers jours** remplace les 4 dernières semaines, et **6 derniers mois** s'ajoute à la liste.
* **Vos filtres sont conservés.** Le préréglage de dates et le mode de comparaison sont désormais persistants pour chaque entreprise et vous suivent d'un appareil à l'autre, au lieu d'être réinitialisés aux valeurs par défaut à chaque session.
* **Les meilleurs clients sont identifiés par leur nom**, avec l'e-mail comme solution de repli.
* Les revenus par pays renvoient désormais jusqu'aux **150 premiers** pays.
En savoir plus : [Analyses du tableau de bord](/features/analytics-and-reporting)
## Améliorations et corrections de bugs
### 10. **Filtrer les paiements par devise**
`GET /payments` accepte un paramètre de requête facultatif **`currency`**, ce qui vous permet de lister uniquement les paiements réglés dans une devise donnée — par exemple `GET /payments?currency=EUR`. Le même filtre est disponible dans le tableau Payments du tableau de bord.
En savoir plus : [Lister les paiements](/api-reference/payments/get-payments)
### 11. **Délai de réponse aux litiges prolongé à 10 jours**
Vous disposez désormais de **10 jours** pour répondre à un litige après sa création, contre 4 auparavant. Le compte à rebours du litige dans votre tableau de bord et la date limite de réponse renvoyée par l'API reflètent tous deux cette période prolongée.
En savoir plus : [Litiges](/features/transactions/disputes)
### 12. **Formulaires de compte bancaire de versement plus clairs**
L'ajout d'un compte bancaire de versement est désormais moins ambigu. Les libellés des champs, les descriptions et les infobulles s'adaptent maintenant à votre type d'entreprise ; le nom du titulaire du compte et celui du bénéficiaire ne semblent donc plus être des doublons pour les entreprises individuelles. En choisissant **Autre** comme banque, vous pouvez saisir librement son nom ; le code bancaire domestique chinois est indiqué comme **CNAPS**, et la page des versements reste visible en mode test afin que vous puissiez accéder à vos comptes associés depuis l'un ou l'autre mode.
En savoir plus : [Processus des versements](/features/payouts/payout-structure)
### Autres corrections et améliorations
* **Les crédits liés à un changement de plan sont annulés lorsqu'un paiement échoue.** Les crédits de proratisation accordés lors d'un changement de plan d'abonnement ne sont plus conservés si le paiement qui en résulte n'aboutit pas.
* **Les factures d'essai payantes affichent le montant de l'essai**, et non le prix récurrent normal.
* **Les remises en pourcentage respectent la valeur minimale du panier**, calculée à partir du prix de base plutôt que du total intermédiaire ; un délai d'expiration du verrou de remise renvoie désormais un code d'erreur distinct au lieu d'un `503` générique.
* **La suppression d'un moyen de paiement déjà supprimé réussit désormais** au lieu de renvoyer une erreur, ce qui rend l'appel correctement idempotent.
* **Correction de la devise utilisée pour le seuil du mandat en Inde** lors de la mise à jour du moyen de paiement d'un abonnement.
* **Les écritures du registre de crédits dépassant les limites autorisées** sont rejetées avec un `400` typé au lieu d'échouer ultérieurement.
* **Les produits à prix libre prennent en charge un montant fixe** dans les liens de checkout partagés, et les ID d'accès sont affichés dans le panneau de détails de l'accès.
* Corrections Analytics : séries de valeur vie client, modules complémentaires inclus dans le MRR, absence de comparaison de période sur les plages couvrant toute la période, séries s'arrêtant au compartiment actuel et libellés de plage et de comparaison plus clairs.
* Corrections mineures de bugs et améliorations de la stabilité sur l'ensemble de la plateforme.