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.
Nouvelles fonctionnalités
1. Droits
Dodo Payments est désormais fourni avec des Droits unifiés — une seule couche permettant la livraison automatique pour chaque intégration de distribution. Un seul produit peut livrer plusieurs droits à chaque achat réussi ou abonnement actif.
Cinq nouvelles intégrations de plateformes
Jusqu’à présent, Dodo Payments livrait des clés de licence et des fichiers numériques automatiquement à l’achat. Les droits étendent cette portée à cinq plateformes supplémentaires — de sorte que les clients payants puissent accéder à votre communauté, votre code ou votre contenu dès que le paiement réussit, sans aucune intervention manuelle de votre part :
| Intégration | Ce qu’elle livre | Comportement de révocation |
|---|
| Discord | Attribue un rôle choisi sur votre serveur Discord après que le client a complété OAuth | Rôle retiré lors de l’annulation/remboursement |
| GitHub | Ajoute le client comme collaborateur à un dépôt privé au niveau de permission que vous choisissez | Collaborateur retiré lors de l’annulation/remboursement |
| Telegram | Émet un lien d’invitation de demande de participation unique pour un chat ou canal privé via votre bot Telegram | Client expulsé du chat lors de l’annulation/remboursement |
| Framer | Déverrouille un lien de re-mixage de modèle Framer protégé par un code d’accès | Code d’accès désactivé lors de l’annulation/remboursement |
| Notion | Duplique une page modèle Notion dans l’espace de travail du client après qu’il a autorisé via OAuth | Page livrée archivée lors de l’annulation/remboursement |
Ces intégrations rejoignent les Clés de licence existantes (clés uniques avec des limites d’activation et d’expiration) et les Fichiers numériques (URL de téléchargement signées pour les e-books, modèles, médias), toutes désormais gérées à travers le même cycle de vie des concessions.
Ce que vous obtenez par défaut
| Capacité | Description |
|---|
| Modèles réutilisables | Définissez un droit une fois (limites d’activation, ensembles de fichiers, rôle Discord, permission de dépôt, etc.) et attachez-le à n’importe quel produit |
| Concessions automatiques | Émis sur payment.succeeded et subscription.active, idempotent à travers renouvèlements et ré-activations |
| Révocation consciente du cycle de vie | Révoqué sur subscription.cancelled, subscription.on_hold, subscription.expired, refund.succeeded, subscription.plan_changed, ou API/panneau de révoquer manuel — avec un revocation_reason rempli |
| Flux OAuth + directs sur la plateforme | OAuth pour Discord, GitHub, et Notion pour le consentement des abonnés ; appels directs à la plateforme pour Telegram, Framer et Fichiers numériques |
| Détection de dérive | Détecte lorsqu’un rôle Discord, un collaborateur GitHub ou une page Notion se désynchronise au niveau de la plateforme et révoque avec revocation_reason: platform_external |
| Chiffrement au repos | Tous les jetons de plateforme (OAuth, bot, installations d’applications) sont stockés avec AES-256-GCM |
Webhooks
Quatre nouveaux événements de cycle de vie se déclenchent pour chaque concession :
| Événement | Se déclenche quand |
|---|
entitlement_grant.created | Une nouvelle concession est créée pour un client |
entitlement_grant.delivered | Accès client provisionné |
entitlement_grant.failed | La livraison n’a pas pu être complétée ; inspectez error_code et error_message |
entitlement_grant.revoked | Accès retiré ; inspectez revocation_reason |
Pour les nouvelles intégrations, écoutez entitlement_grant.delivered plutôt que payment.succeeded. Le succès du paiement ne signifie pas que la livraison est terminée, en particulier pour les intégrations basées sur OAuth.
En savoir plus : Droits | Webhooks de Concession de Droits
2. Raisons de l’annulation d’abonnement dans le Portail Client
Lorsque les clients annulent un abonnement depuis le Portail Client, ils sont désormais invités à partager pourquoi ils annulent avant de confirmer. La raison capturée est stockée sur l’abonnement comme cancellation_feedback, visible dans les charges API et webhook, et disponible sur le tableau de bord pour que vous puissiez détecter les motifs de désabonnement en un coup d’œil.
Options de raison
| Valeur | Libellé visible par le client |
|---|
too_expensive | Trop cher |
missing_features | Fonctionnalités manquantes |
switched_service | Passé à un autre service |
unused | Ne l’utilisant pas assez |
customer_service | Mauvais service client |
low_quality | Basse qualité |
too_complex | Trop complexe |
other | Autre |
Où cela apparaît
- Objet abonnement : Nouveau champ
cancellation_feedback (une des valeurs ci-dessus) et cancellation_comment (texte libre optionnel), remplis lorsque le client annule
- Webhook
subscription.cancelled : Les deux champs sont inclus dans la charge utile
- API : Passez
cancellation_feedback et cancellation_comment à PATCH /subscriptions/{id} lors de la programmation ou de l’exécution d’une annulation par programmation
// Reading the captured feedback
const subscription = await client.subscriptions.retrieve('sub_123');
console.log(subscription.cancellation_feedback); // e.g., "too_expensive"
console.log(subscription.cancellation_comment); // e.g., "Switching to a competitor"
Combinez cancellation_feedback avec Subscription Dunning pour personnaliser vos e-mails de reconquête — par exemple, envoyez un code de réduction à ceux qui ANNULENT pour too_expensive et un sondage “qu’est-ce qui manque?” à ceux qui ANNULENT pour missing_features.
Plus d’informations : Portail Client | Webhooks d’Abonnement
3. Montant minimum de mandat configurable pour les mandats INR
Vous pouvez désormais configurer le seuil de mandat pour les mandats électroniques INR sur les abonnements récurrents à carte indienne. Auparavant, chaque abonnement à carte indienne inférieur à ₹15 000 utilisait un mandat à la demande fixe de ₹15 000. Maintenant, vous pouvez remplacer ce seuil au niveau du marchand — et par session de paiement ou abonnement si nécessaire.
Le montant du mandat enregistré avec la banque du client est max(mandate_min_amount_inr_paise, billing_amount), donc cette valeur agit comme plafond d’autorisation face au client chaque fois que la facturation est inférieure au seuil.
// Per-subscription override
const subscription = await client.subscriptions.create({
product_id: 'prod_inr_monthly',
customer: { email: 'customer@example.in' },
billing: { country: 'IN' /* ... */ },
mandate_min_amount_inr_paise: 2_000_000 // ₹20,000 ceiling for this subscription
});
// Or via a checkout session
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_inr_monthly', quantity: 1 }],
mandate_min_amount_inr_paise: 2_000_000,
return_url: 'https://yoursite.com/return'
});
Priorité de résolution
- Remplacement par demande (
mandate_min_amount_inr_paise sur la session de paiement, le paiement ou l’abonnement)
- Paramètre au niveau du marchand dans les paramètres de l’entreprise
- Défaut système de ₹15,000 (1,500,000 paise)
| Champ | Type | Gamme | S’applique à |
|---|
mandate_min_amount_inr_paise | integer (INR paise) | >= 1 | Abonnements en INR sur carte indienne sans connecteurs Airwallex |
Ce paramètre n’affecte que les mandats électroniques enregistrés pour les cartes émises en Inde (Visa, Mastercard, RuPay) sur les abonnements en INR. Les abonnements par UPI suivent leur propre flux AutoPay et ne sont pas affectés.
En savoir plus : Méthodes de Paiement en Inde | Abonnements avec Mandats RBI
4. Paramétrage des frais de devises adaptatives inclusifs
La devise adaptative est la fonctionnalité qui vous permet de facturer les clients dans leur devise locale. Par défaut, le frais de devise adaptative de 2 à 4 % est supporté par le client et ajouté au prix affiché. Avec le nouveau paramètre Frais inclusifs, vous pouvez inverser cela : garder le prix affiché inchangé pour le client et absorber les frais vous-même.
Où configurer
Accédez à Paramètres → Entreprise, assurez-vous que Prix adaptatif est activé et basculez Frais inclusifs dans la section Devise adaptative.
Remplacement par demande
Vous pouvez également remplacer le défaut du marchand pour des paiements, caisses individuelles et abonnements à la demande en utilisant le booléen adaptive_currency_fees_inclusive :
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
adaptive_currency_fees_inclusive: true, // override business default
return_url: 'https://yoursite.com/return'
});
| Mode | Le client voit | Le marchand règle |
|---|
| Exclusif (défaut) | Prix local + frais de 2–4 % en plus | Plein prix de base |
| Inclusif | Prix local (inchangé) | Prix de base moins les frais de 2 à 4 % |
Les transactions INR → INR sont toujours traitées comme inclusives, quel que soit le paramètre d’entreprise ou le remplacement par demande.
En savoir plus : Devise Adaptative
5. Application de bureau Dodo Payments
L’application officielle Dodo Payments Desktop est maintenant disponible sur macOS, Windows, et Linux. Exécutez votre tableau de bord de paiements comme une application native rapide, sans onglet de navigateur requis.
| Plateforme | Téléchargement |
|---|
| macOS (Apple Silicon) | Dodo.Payments_<version>_aarch64.dmg |
| macOS (Intel) | Dodo.Payments_<version>_x64.dmg |
| Windows | Dodo.Payments_<version>_x64-setup.exe (ou .msi) |
| Linux (Debian/Ubuntu) | Dodo.Payments_<version>_amd64.deb |
| Linux (Fedora/RHEL) | Dodo.Payments-<version>-1.x86_64.rpm |
| Linux (AppImage, mise à jour automatique) | Dodo.Payments_<version>_amd64.AppImage |
Ce qui est à l’intérieur
- Petit binaire natif — construit avec Tauri sur le Webview natif du système, ~5 Mo au total (pas de Chromium inclus)
- Signée et notarée — les builds macOS sont signées avec l’ID développeur Apple et notariées, donc pas d’avertissement Gatekeeper
- Mise à jour automatique — vérifie toutes les 4 heures et applique automatiquement les mises à jour signées depuis les GitHub Releases (fonctionne sur macOS, Windows, et Linux AppImage)
- Barre système + menu — réduction en icône sur macOS, menus complets Fichier/Édition/Affichage/Aide avec raccourcis clavier (
⌘⇧H aller au tableau de bord, ⌘L copier l’URL actuelle, ⌘⌥I outils de développement)
- Support des liens profonds — les liens d’authentification par lien magique s’ouvrent directement dans l’application
- Multi-fenêtre — ouvrez plusieurs tableaux de bord côte à côte
6. Paiements en Stablecoin (USDC, USDP, USDG)
Acceptez les paiements en stablecoin dans le monde entier avec règlement en USD. Les clients paient à partir de leur portefeuille stablecoin préféré sur le réseau de leur choix ; vous recevez des USD fiat sans exposition à la volatilité des crypto-monnaies, sans rejets de débit, et sans infrastructure bancaire requise du côté client.
Devises et réseaux pris en charge
| Stablecoin | Réseaux |
|---|
| USDC | Ethereum, Solana, Polygon, Base |
| USDP | Ethereum, Solana |
| USDG | Ethereum |
Couverture
| Détail | Valeur |
|---|
| Devise de facturation | USD |
| Pays pris en charge | Mondial (sauf Inde) |
| Abonnements | Non pris en charge (paiements uniques uniquement) |
| Montant minimum | 0,50 $ |
| Règlement | USD |
Configuration
Passez crypto dans allowed_payment_method_types lors de la création d’une session de caisse :
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_123', quantity: 1 }],
allowed_payment_method_types: ['crypto', 'credit', 'debit'],
return_url: 'https://example.com/success'
});
Le client voit une adresse de portefeuille et un code QR avec le montant du stablecoin calculé au taux de change en temps réel ; une fois que la blockchain confirme la transaction, votre webhook payment.succeeded se déclenche et le client est redirigé vers votre page de succès.
Les paiements en stablecoin sont irréversibles par conception — il n’y a pas de rejets de débit. Nous recommandons toujours d’offrir credit et debit comme méthodes de secours pour les clients sans portefeuille stablecoin.
En savoir plus : Paiements en Stablecoin
7. Importer des clés de licence existantes
Vous pouvez désormais importer des clés de licence depuis un autre système dans Dodo Payments en utilisant l’API de création de clé de licence. Cela permet une migration sans interruption à partir de n’importe quel fournisseur de clés de licence externe, afin que vos clients existants puissent continuer à activer, valider et désactiver leurs clés contre Dodo Payments sans nouvelle émission.
const licenseKey = await client.licenseKeys.create({
customer_id: 'cus_abc123',
product_id: 'prod_456',
key: 'YOUR-EXISTING-LICENSE-KEY',
activations_limit: 5,
expires_at: '2026-12-31T23:59:59Z',
});
Les clés importées sont étiquetées avec source: "import" (vs. source: "auto" pour les clés générées automatiquement au paiement), de sorte que vous pouvez distinguer l’inventaire migré des clés émises organicement lors de la requête GET /license_keys. Le payment_id sur les clés importées est null car elles ne sont pas liées à une transaction Dodo Payments.
Les clés de licence créées ou mises à jour via l’API ne déclenchent pas de notifications par e-mail aux clients. Si vous devez informer les clients d’une clé importée, gérez-le séparément dans votre application.
Migration de Polar.sh ou Lemon Squeezy ? Le dodo-migrate CLI automatise les importations massives de produits, clients, remises et clés de licence en une seule commande.
En savoir plus : Clés de licence | API de création de clé de licence
8. require_phone_number pour les sessions de caisse
Forcez les clients à fournir un numéro de téléphone lors du paiement en définissant feature_flags.require_phone_number: true lors de la création d’une session de caisse. Le numéro de téléphone devient un champ obligatoire sur le formulaire de paiement, avec une validation du formulaire affichant “Le numéro de téléphone est requis” si le client le laisse vide.
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
feature_flags: {
allow_phone_number_collection: true,
require_phone_number: true
},
return_url: 'https://yoursite.com/return'
});
| Drapeau | Défaut | Comportement |
|---|
allow_phone_number_collection | true | Affiche le champ du numéro de téléphone sur le paiement |
require_phone_number | false | Rend le champ du numéro de téléphone obligatoire |
require_phone_number: true nécessite allow_phone_number_collection: true. L’API rejette les sessions où require_phone_number est vrai alors que la collecte des numéros de téléphone est désactivée.
Utile pour les SaaS B2B, les industries réglementées ou tout flux où vous avez besoin d’un canal de contact vérifié pour le support, la révision des fraudes ou la conformité.
En savoir plus : Fonctionnalités de caisse | API de création de session de caisse
Correctifs et améliorations
- Corrections de bugs mineurs et améliorations de la stabilité sur toute la plateforme