Livrez automatiquement des clés de licence, des fichiers téléchargeables, des indicateurs de fonctionnalité et un accès à Discord, GitHub, Telegram, Framer et Notion lorsque vos clients paient.
Les droits d’accès transforment un paiement réussi ou un abonnement actif en accès : une clé de licence dans la boîte de réception de votre client, un indicateur de fonctionnalité vérifié par votre application, un rôle Discord, un dépôt GitHub, un modèle Notion, un lien de remix Framer, une invitation à une conversation Telegram ou un ensemble de fichiers téléchargeables. Dodo Payments émet, suit et révoque automatiquement cet accès lorsque l’état du paiement évolue.
The Entitlements dashboard. Each entitlement is a reusable template; the right pane shows individual customer grants.
Un droit d’accès est une définition réutilisable de ce que vous fournissez à un client, comme une clé de licence Pro, un rôle Discord « Patrons », l’accès à votre dépôt GitHub privé ou un ensemble d’e-books téléchargeables. Vous associez des droits d’accès aux produits, puis Dodo Payments les fournit lorsqu’un client paie.Lorsqu’un client achète le produit, Dodo Payments crée une attribution : l’émission de ce droit d’accès pour un client donné. Une attribution possède l’un des quatre statuts suivants : Pending pendant la livraison, Delivered une fois que le client y a accès, Failed si la livraison n’a pas pu aboutir, et Revoked lorsque l’accès est retiré.
Les droits d’accès contrôlent la fourniture (le client y a-t-il accès ?). Les crédits contrôlent la consommation (quelle quantité peut-il utiliser ?). Vous pouvez associer les deux au même produit. Consultez la page Facturation basée sur les crédits pour en savoir plus sur les crédits.
Chaque droit d’accès est fourni via une intégration. Choisissez l’intégration correspondant à ce que vous vendez.
License Keys
Générez des clés de licence uniques avec des limites d’activation et d’expiration. Idéal pour les logiciels, les plugins et les CLIs.
Digital Files
Fournissez des fichiers téléchargeables, tels que des e-books, des modèles et des contenus multimédias, avec des URL de téléchargement présignées et des instructions facultatives.
Feature Flags
Contrôlez les fonctionnalités de votre propre application après un achat. Le droit est fourni lors de sa création, vérifié via l’API et révoqué en cas d’annulation.
Discord
Attribuez un rôle à un client sur votre serveur Discord lorsqu’il achète. Le rôle est automatiquement supprimé en cas d’annulation.
GitHub
Ajoutez des clients comme collaborateurs à un dépôt privé avec le niveau de permission que vous choisissez.
Telegram
Ajoutez des clients à un chat ou canal Telegram privé après l’achat.
Framer
Débloquez un lien de remix de modèle Framer pour les clients payants.
Notion
Dupliquez un modèle Notion dans l’espace de travail du client lors de l’achat.
Les attributions suivent les mêmes événements de paiement et d’abonnement que ceux que vous recevez sous forme de webhooks. Dodo Payments crée et révoque automatiquement les attributions pour les achats en fonction du cycle de vie du paiement ; vous n’avez donc pas besoin d’appeler vous-même l’API des attributions.
Une attribution évolue selon les statuts suivants :
1
Created
Dodo Payments crée une attribution lorsqu’un paiement est terminé ou qu’un abonnement devient actif. Les attributions d’indicateurs de fonctionnalité commencent avec Delivered. Les attributions de clés de licence commencent également avec Delivered lorsque le droit d’accès utilise fulfillment_mode: auto (la valeur par défaut). Avec fulfillment_mode: manual, l’attribution commence avec Pending, sans clé, jusqu’à ce que vous en fournissiez une avec Fulfill License Key Grant. Toutes les autres intégrations commencent avec Pending.Les intégrations basées sur OAuth (Discord, GitHub, Notion) exposent un oauth_url que le client consulte pour donner son consentement. Dodo Payments tente de générer cette URL lors de la création de l’attribution. En cas d’échec, le champ reste null jusqu’à ce que le client démarre le processus d’acceptation depuis son e-mail de livraison ou le Customer Portal. Les intégrations directes à la plateforme (Telegram, Framer, Digital Files) restent Pending uniquement pendant la mise à disposition, puis passent à Delivered.
2
Delivered
Lorsque la livraison est terminée, l’attribution passe à Delivered et delivered_at est défini. La livraison est terminée lorsque la clé de licence est générée, que le rôle est attribué, que l’accès au dépôt est accordé, que les liens vers les fichiers sont résolus ou que le flux OAuth est terminé.
3
Failed
Si l’appel d’intégration renvoie une erreur non réessayable, comme un jeton OAuth révoqué, une permission refusée ou un fichier qui n’existe plus, l’attribution passe à Failed. Les champs error_code et error_message enregistrent la raison.
4
Revoked
Lorsque l’accès est retiré, par exemple parce qu’un abonnement est annulé, qu’un remboursement est effectué ou que vous révoquez l’attribution, celle-ci passe à Revoked. Le champ revocation_reason enregistre le déclencheur.
Comportement des attributions selon les événements
Chaque événement de paiement et d’abonnement modifie les attributions comme suit :
Événement
Comportement
payment.succeeded (paiement ponctuel)
Émet une attribution par droit d’accès associé. Un droit d’accès de type License Key émet une attribution par clé.
payment.succeeded (paiement associé à un abonnement)
Aucun changement. Les événements d’abonnement ci-dessous gèrent ces attributions.
subscription.active
Émet des attributions pour les droits d’accès associés qui n’en possèdent pas encore et réémet les attributions précédemment révoquées pour le même abonnement. Les attributions révoquées avec manual, refund ou platform_external ne sont pas réémises.
subscription.renewed
Aucun changement. Les attributions existantes sont conservées lors des renouvellements.
subscription.past_due
Aucun changement. Les attributions restent fournies pendant toute la période de grâce.
subscription.on_hold
Révoque toutes les attributions fournies et en attente avec revocation_reason: subscription_on_hold.
subscription.paused
Révoque toutes les attributions fournies et en attente avec revocation_reason: SubscriptionPaused. Contrairement aux autres motifs d’abonnement, cette valeur utilise PascalCase ; faites-la correspondre exactement.
subscription.unpaused
Réémet les attributions précédemment révoquées pour le même abonnement, de la même manière que subscription.active.
subscription.cancelled
Révoque toutes les attributions avec revocation_reason: subscription_cancelled.
subscription.expired
Révoque toutes les attributions avec revocation_reason: subscription_expired.
subscription.plan_changed
Révoque toutes les attributions actuelles avec revocation_reason: plan_changed, puis émet les attributions correspondant aux droits d’accès du nouveau plan.
refund.succeeded (paiement ponctuel)
Révoque les attributions de ce paiement avec revocation_reason: refund.
Révocation manuelle via l’API
Révoque l’attribution avec revocation_reason: manual. Les révocations manuelles ne sont pas automatiquement réémises lors du renouvellement d’un abonnement.
Clé de licence désactivée
Pour les attributions de clés de licence, la désactivation de la clé sous-jacente révoque l’attribution avec revocation_reason: license_key_disabled. La réactivation de la clé restaure automatiquement l’attribution.
Dérive de plateforme détectée
Si la partie plateforme d’une intégration n’est plus synchronisée, par exemple lorsqu’un rôle Discord est supprimé manuellement, que l’application GitHub perd l’accès au dépôt ou qu’une opération de rapprochement détecte une cible manquante, Dodo Payments révoque l’attribution avec revocation_reason: platform_external. Elle n’est pas automatiquement réémise lors du renouvellement de l’abonnement tant que le problème de plateforme n’est pas résolu.
Les attributions liées aux abonnements sont idempotentes par (entitlement, customer, subscription) ; les renouvellements et les réactivations ne créent donc pas d’attributions en double. Les attributions ponctuelles sont idempotentes par (entitlement, customer, payment).
Accédez à Entitlements dans le tableau de bord, puis cliquez sur + pour créer un droit d’accès.
2
Pick an Integration
Choisissez le type d’intégration : License Key, Digital Files, Feature Flag, Discord, GitHub, Telegram, Figma, Framer ou Notion. Pour une intégration de plateforme, connectez d’abord votre compte si ce n’est pas déjà fait.
3
Configure Delivery
Renseignez les champs de l’intégration. Par exemple, GitHub demande un dépôt et un niveau de permission, Discord demande un serveur et un rôle facultatif, et License Key demande une limite d’activations et une durée de licence.
Creating a GitHub entitlement. Each integration shows the fields it needs.
4
Save
Cliquez sur Create Entitlement. Vous pouvez maintenant associer le droit d’accès à n’importe quel produit.
Ouvrez un produit, accédez à sa section Entitlements, puis sélectionnez les droits d’accès à fournir lors de l’achat du produit. Un produit peut fournir plusieurs droits d’accès à la fois. Par exemple, un plan Pro peut inclure une clé de licence, un accès GitHub et un rôle Discord.
Attaching entitlements to a product. Selected entitlements are delivered on every successful purchase or active subscription.
Après un achat, le client reçoit un e-mail de livraison contenant la clé de licence, les liens de téléchargement, les liens d’invitation OAuth ou l’invitation de plateforme correspondant aux droits d’accès du produit. Ces mêmes informations restent disponibles dans le Customer Portal, sous l’historique de ses commandes, tant que l’attribution est active.
L’accès aux abonnements Discord, GitHub et Notion nécessite que le client autorise Dodo Payments à accorder cet accès. Ces attributions restent Pending jusqu’à ce que le client termine le flux OAuth depuis le lien figurant dans son e-mail ou dans le Customer Portal. Une fois l’autorisation accordée, l’attribution passe à Delivered et Dodo Payments met en place l’accès à la plateforme.
Lorsqu’une attribution est révoquée, Dodo Payments supprime l’accès sur la plateforme : le rôle Discord est supprimé, le collaborateur GitHub est retiré ou la clé de licence est désactivée. Le client voit cette modification dans le Customer Portal.
Pour Digital Files, la révocation empêche la création de nouvelles URL de téléchargement présignées, mais elle n’invalide pas les copies déjà téléchargées par un client. Tenez-en compte lorsque vous planifiez le contrôle d’accès à votre contenu.
Ouvrez un droit d’accès depuis le tableau de bord pour consulter ses attributions. Le panneau de détails affiche le nombre total d’attributions, un filtre par statut et une ligne par attribution avec le client, la date d’accès, le statut et une action Revoke.Pour gérer les attributions par programmation, répertoriez-les avec le filtre status et révoquez une attribution donnée par son ID :
import DodoPayments from 'dodopayments';const client = new DodoPayments({ bearerToken: process.env['DODO_PAYMENTS_API_KEY'],});// List grants for an entitlementconst grants = await client.entitlements.grants.list('ent_abc123', { status: 'Delivered',});// Revoke a single grantawait client.entitlements.grants.revoke('entg_xyz789', { id: 'ent_abc123',});
Dodo Payments envoie quatre événements webhook pour le cycle de vie des attributions. Abonnez-vous à ces événements pour maintenir votre application synchronisée avec les accès de chaque client.
Événement
Déclenché lorsque
entitlement_grant.created
Une attribution est créée. Les attributions de clés de licence automatiquement fournies et les attributions d’indicateurs de fonctionnalité arrivent avec Delivered. Les attributions de clés de licence fournies manuellement et toutes les autres intégrations arrivent avec Pending, puis passent à Delivered une fois l’appel de plateforme réussi ou, pour les intégrations basées sur OAuth, une fois l’autorisation du client accordée.
entitlement_grant.delivered
Une attribution existante passe à Delivered ; le client y a donc désormais accès. Une attribution qui est Delivered dès sa création ne déclenche que created.
entitlement_grant.failed
L’attribution n’a pas pu être fournie. Examinez error_code et error_message.
entitlement_grant.revoked
L’accès a été retiré. Examinez revocation_reason.
Entitlement Grant Webhook Payloads
Consultez le schéma complet de la charge utile, des exemples d’événements et la référence revocation_reason.
Utilisez un droit d’accès par canal de livraison. Ne partagez pas un même droit d’accès Discord entre des produits dont les rôles attendus diffèrent. Créez un droit d’accès par rôle afin que la révocation reste propre.
Testez d’abord en mode test. Créez le droit d’accès, associez-le à un produit de test, effectuez un paiement et observez l’attribution passer de Pending à Delivered. Annulez ensuite l’abonnement de test et vérifiez que l’attribution est révoquée.
Écoutez entitlement_grant.delivered, et non payment.succeeded. Un paiement peut réussir avant la fin de la fourniture, en particulier pour les flux OAuth. Attendez que l’attribution atteigne Delivered avant de déverrouiller les fonctionnalités dépendantes dans vos propres systèmes. Un droit fourni dès sa création, comme une clé de licence automatiquement fournie ou un indicateur de fonctionnalité, arrive sous la forme entitlement_grant.created avec status: "Delivered".
Considérez entitlement_grant.failed comme nécessitant une action. Une attribution ayant échoué signifie qu’un client a payé sans obtenir l’accès. Présentez ces attributions à votre équipe d’assistance ou déclenchez une nouvelle attribution.
Associez revocation_reason à vos flux de rétention. Une révocation subscription_on_hold peut être récupérée, car le client peut mettre à jour sa carte. Une révocation manual est intentionnelle. Traitez-les différemment dans vos messages aux clients.
Ne révoquez pas l’accès lors de subscription.past_due. Cet événement ouvre une période de grâce, et le client conserve l’accès jusqu’à la fin de cette période. Attendez subscription.on_hold ou subscription.cancelled.
