Automatisches Bereitstellen von Lizenzschlüsseln, herunterladbaren Dateien, Feature Flags und Zugriff auf Plattformen wie Discord, GitHub, Telegram, Framer und Notion, wenn Kunden bezahlen.
Berechtigungen verwandeln eine erfolgreiche Zahlung oder ein aktives Abonnement in echten Zugriff: ein Lizenzschlüssel im Posteingang Ihres Kunden, ein Feature Flag, das Ihre App überprüft, eine Discord-Rolle, ein GitHub-Repository, eine Notion-Vorlage, ein Framer-Remix-Link, eine Telegram-Chat-Einladung oder ein herunterladbares Dateipaket. Dodo Payments stellt diesen Zugriff automatisch aus, verfolgt und widerruft ihn, wenn sich der Zahlungslebenszyklus ändert.
The Entitlements dashboard. Each entitlement is a reusable template; the right pane shows individual customer grants.
Eine Berechtigung ist eine wiederverwendbare Definition von etwas, das Sie einem Kunden liefern: ein Pro-Lizenzschlüssel, eine “Patrons”-Discord-Rolle, Zugang zu Ihrem privaten GitHub-Repository, ein herunterladbares eBook-Paket. Sie fügen Produkte Berechtigungen hinzu, und Dodo Payments kümmert sich um den Rest.Wenn ein Kunde das Produkt kauft, erstellt Dodo Payments einen grant, die einmalige Ausstellung dieses Anspruchs für einen einzelnen Kunden. Grants durchlaufen eine kleine Anzahl von Statuswerten: Pending, solange die Bereitstellung läuft, Delivered, sobald der Kunde Zugriff hat, Failed, wenn die Bereitstellung nicht abgeschlossen werden konnte, und Revoked, wenn der Zugriff entzogen wird.
Berechtigungen bestimmen die Erfüllung (hat der Kunde Zugang?). Credits bestimmen den Verbrauch (wie viel davon können sie nutzen?). Beide können mit demselben Produkt verbunden werden. Siehe guthabenbasierte Abrechnung für Credits.
Berechtigungen werden von denselben Zahlungs- und Abonnementereignissen angetrieben, die Sie bereits als Webhooks erhalten. Sie müssen die Grant-API nicht selbst für Käufe aufrufen. Dodo Payments erstellt und widerruft Berechtigungen basierend auf dem zugrunde liegenden Zahlungslebenszyklus automatisch.
Ein Grant wird erstellt, wenn eine Zahlung abgeschlossen wird oder ein Abonnement aktiv wird. Feature Flags springen direkt zu Delivered. Lizenzschlüssel springen ebenfalls direkt zu Delivered, wenn das Entitlement fulfillment_mode: auto verwendet (die Standardeinstellung); unter fulfillment_mode: manual wird der Grant in Pending ohne Schlüssel erstellt, bis du über Fulfill License Key Grant einen bereitstellst. Jede andere Integration startet in Pending. OAuth-basierte Integrationen (Discord, GitHub, Notion) stellen eine oauth_url bereit, die der Kunde besuchen muss, um die Einwilligung abzuschließen; das Feld ist null bei einem neu erstellten Grant und wird ausgefüllt, sobald der Kunde den Akzeptieren-Ablauf über seine Zustellungs-E-Mail oder das Kundenportal startet. Plattformdirekte Integrationen (Telegram, Framer, Digital Files) verbleiben nur kurz in Pending, während die Zustellung bereitgestellt wird, und wechseln dann zu Delivered.
2
Delivered
Sobald die Bereitstellung abgeschlossen ist (License Key generiert, Rolle zugewiesen, Repository-Zugriff gewährt, Dateilinks aufgelöst, OAuth abgeschlossen), wechselt der grant zu Delivered und delivered_at wird gesetzt.
3
Failed
Wenn der Integrationsaufruf einen nicht wiederholbaren Fehler zurückgibt (widerrufenes OAuth-Token, verweigerte Berechtigung, Datei nicht mehr vorhanden), wechselt der grant zu Failed. Die Felder error_code und error_message erfassen den Grund.
4
Revoked
Wenn der Zugriff entzogen wird (Abonnement gekündigt, Rückerstattung ausgestellt oder vom Händler initiiertem Widerruf), wechselt der grant zu Revoked. Das Feld revocation_reason zeichnet den Auslöser auf.
Einen Grant pro verknüpftem Entitlement ausstellen.
payment.succeeded (abonnementverknüpfte Zahlung)
No-op. Grants werden durch das untenstehende Abonnementereignis gesteuert.
subscription.active
Grants für alle verknüpften Entitlements ausstellen, die noch keinen Grant besitzen. Alle Grants, die zuvor für dasselbe Abonnement widerrufen wurden, erneut ausstellen.
subscription.renewed
No-op. Bestehende Grants bleiben über Verlängerungen hinweg bestehen.
subscription.on_hold
Alle zugestellten und ausstehenden Grants widerrufen. revocation_reason: subscription_on_hold.
subscription.paused
Alle zugestellten und ausstehenden Grants widerrufen. revocation_reason: SubscriptionPaused.
subscription.unpaused
Alle Grants, die zuvor für dasselbe Abonnement widerrufen wurden, erneut ausstellen, genau wie subscription.active.
subscription.cancelled
Alle widerrufen. revocation_reason: subscription_cancelled.
subscription.expired
Alle widerrufen. revocation_reason: subscription_expired.
subscription.plan_changed
Alle aktuellen Grants widerrufen und anschließend Grants für die Entitlements des neuen Plans ausstellen. revocation_reason: plan_changed.
refund.succeeded (einmalige Zahlung)
Grants für diese Zahlung widerrufen. revocation_reason: refund.
Manueller API-Widerruf
Mit revocation_reason: manual widerrufen. Manuelle Widerrufe werden bei einer Abonnementverlängerung nicht automatisch erneut ausgestellt.
Lizenzschlüssel deaktiviert
Bei Grants mit Lizenzschlüsseln widerruft die Deaktivierung des zugrunde liegenden Schlüssels den Grant mit revocation_reason: license_key_disabled. Der Grant wird automatisch reaktiviert, wenn der Schlüssel wieder aktiviert wird.
Plattformabweichung erkannt
Wenn die Plattformseite einer Integration nicht mehr synchron ist (eine Discord-Rolle manuell entfernt wurde, die GitHub App den Repositoryzugriff verliert oder ein Abgleich einen fehlenden Zielwert erkennt), wird der Grant mit revocation_reason: platform_external widerrufen. Bei einer Abonnementverlängerung wird er nicht automatisch erneut ausgestellt, bis das zugrunde liegende Plattformproblem behoben ist.
Abonnementgetriebene Berechtigungen sind idempotent pro (entitlement, customer, subscription); Erneuerungen und Reaktivierungen erzeugen keine doppelten Berechtigungen. Einmalige Berechtigungen sind idempotent pro (entitlement, customer, payment).
Gehen Sie in Ihrer Dodo Payments-Dashboard zu Berechtigungen und klicken Sie auf +, um ein neues Berechtigungsnachweis zu erstellen.
2
Pick an integration
Wählen Sie den Integrationstyp: License Key, Digital Files, Feature Flag, Discord, GitHub, Telegram, Figma, Framer oder Notion. Bei Plattformintegrationen müssen Sie zunächst Ihr Konto verbinden, falls Sie dies noch nicht getan haben.
3
Configure delivery
Füllen Sie die integrationsspezifischen Felder aus. Zum Beispiel fragt GitHub nach einem Repository und einer Berechtigungsebene; Discord fragt nach einem Server und einer optionalen Rolle; der Lizenzschlüssel fragt nach Aktivierungslimits und Ablaufdatum.
Creating a GitHub entitlement. Each integration shows the fields it needs.
4
Save
Speichern Sie das Berechtigungsnachweis. Sie können es jetzt jedem Produkt zuordnen.
Öffnen Sie ein Produkt, erweitern Sie Erweiterte Einstellungen → Berechtigungen & Credits und wählen Sie die Berechtigungen aus, die geliefert werden sollen, wenn das Produkt gekauft wird. Ein einzelnes Produkt kann mehrere Berechtigungen gleichzeitig bereitstellen. Zum Beispiel kann ein Pro-Plan einen Lizenzschlüssel, GitHub-Zugriff und eine Discord-Rolle enthalten.
Attaching entitlements to a product. Selected entitlements are delivered on every successful purchase or active subscription.
Kunden erhalten nach dem Kauf eine Liefer-E-Mail, die den Lizenzschlüssel, Download-Links, OAuth-Einladungslinks oder die Plattform-Einladung enthält, je nachdem, welche Berechtigungen auf dem Produkt angewendet werden. Dieselben Details bleiben im Kundenportal unter ihrer Bestellhistorie unbegrenzt verfügbar.
Für den Subscriber-Zugriff auf Discord, GitHub und Notion muss der Kunde Dodo Payments autorisieren, ihm Zugriff zu gewähren. Diese Grants verbleiben im Status Pending, bis der Kunde den OAuth-Ablauf über den Link aus seiner E-Mail oder dem Customer Portal abschließt. Nach der Autorisierung wechselt der grant zu Delivered und der Plattformzugriff wird sofort bereitgestellt.
Widerrufene Berechtigungen werden auf Plattformebene entfernt: die Discord-Rolle wird entfernt, der GitHub-Mitarbeiter wird entfernt, der Lizenzschlüssel wird deaktiviert. Kunden sehen die Änderung im Kundenportal widergespiegelt.
Für Digitale Dateien entfernt der Widerruf den Zugriff auf die vorgeschriebenen URLs für die Zukunft, invalidiert jedoch nicht die Kopien, die ein Kunde bereits heruntergeladen hat. Planen Sie die Inhaltsbeschränkung entsprechend.
Öffnen Sie ein Berechtigungsnachweis von Ihrem Dashboard aus, um seine Berechtigungen zu sehen. Das Detailfenster der Berechtigung zeigt die Gesamtanzahl der Berechtigungen, Statusfilter, Kundeninformationen, Lieferdaten und eine Widerrufsaktion.Sie können Berechtigungen auch programmgesteuert verwalten:
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 löst vier Webhook-Ereignisse für den Berechtigungslebenszyklus aus. Abonnieren Sie diese Ereignisse, um Ihre Anwendung mit dem in Einklang zu bringen, worauf jeder Kunde Zugriff hat.
Ereignis
Wird ausgelöst, wenn
entitlement_grant.created
Ein neuer grant erstellt wird. License-Key-Grants kommen bei auto-Fulfillment in Delivered und bei manual-Fulfillment in Pending an; jede andere Integration kommt in Pending an und wechselt zu Delivered, sobald der Plattformaufruf erfolgreich ist (oder bei OAuth-basierten Integrationen, sobald der Kunde autorisiert).
entitlement_grant.delivered
Der grant zu „delivered“ wechselt. Der Kunde hat nun Zugriff.
entitlement_grant.failed
Der grant konnte nicht bereitgestellt werden. Prüfe error_code und error_message.
entitlement_grant.revoked
Der Zugriff wurde entzogen. Prüfe revocation_reason.
Entitlement Grant Webhook Payloads
Sehen Sie sich das vollständige Payload-Schema, Beispielereignisse und revocation_reason-Referenz an.
Verwende ein Entitlement pro Zustellungskanal. Teile ein einzelnes Discord-Entitlement nicht über Produkte mit unterschiedlichen Rollenabsichten hinweg; erstelle für jede Rolle eines, damit der Widerruf sauber erfolgen kann.
Teste zuerst im Testmodus. Erstelle das Entitlement, verknüpfe es mit einem Testprodukt, führe einen Checkout durch und beobachte, wie der Grant Pending → Delivered durchläuft. Bestätige, dass das Kündigen des Testabonnements den Grant widerruft.
Höre auf entitlement_grant.delivered, nicht auf payment.succeeded. Eine Zahlung kann erfolgreich sein, bevor die Erfüllung abgeschlossen ist (insbesondere bei OAuth-Flows). Warte auf das Ereignis „zugestellt“, bevor du abhängige Funktionen in deinen eigenen Systemen freischaltest.
Behandle entitlement_grant.failed als handlungsrelevant. Ein fehlgeschlagener Grant bedeutet, dass ein Kunde bezahlt, aber keinen Zugriff erhalten hat. Leite diese Fälle an dein Supportteam weiter oder löse eine erneute Ausstellung aus.
Ordne revocation_reason deinen Kundenbindungsabläufen zu. Ein Widerruf durch subscription_on_hold ist behebbar (der Kunde kann seine Karte aktualisieren). Ein Widerruf durch manual ist beabsichtigt. Behandle sie in der Kundenkommunikation unterschiedlich.
