Skip to main content
Der @dodopayments/express-Adapter stellt deiner Express-App drei Route-Handler bereit: checkoutHandler gibt Checkout-URLs zurück, CustomerPortal leitet einen Kunden zum Customer Portal weiter und Webhooks verifiziert Webhook-Anfragen und ruft deine Event-Handler auf.

Checkout Handler

Erstelle Payment Links und Checkout-Sessions in deiner Express-App.

Customer Portal

Ermögliche Kunden, ihre Abonnements und Daten zu verwalten.

Webhooks

Verifiziere und verarbeite Dodo Payments-Webhook-Events.

Installation

1

Install the Package

Führe den folgenden Befehl im Stammverzeichnis deines Projekts aus:
2

Set Up Environment Variables

Erstelle eine .env-Datei im Stammverzeichnis deines Projekts:
Erstelle den API-Schlüssel unter Developer → API Keys. Füge deinen Webhook-Endpunkt unter Developer → Webhooks hinzu und kopiere das Signaturgeheimnis in DODO_PAYMENTS_WEBHOOK_KEY. Verwende während der Entwicklung einen API-Schlüssel im Testmodus mit DODO_PAYMENTS_ENVIRONMENT=test_mode, da ein Schlüssel im Testmodus nur im Testmodus funktioniert. DODO_PAYMENTS_RETURN_URL ist optional.
Übertrage deine .env-Datei oder Geheimnisse niemals in die Versionsverwaltung.

Beispiele für Route-Handler

Die Beispiele registrieren Routen in einer mit express() erstellten Express-App. Die POST-Checkout-Handler und der Webhook-Handler lesen req.body. Deshalb registriert jedes Beispiel express.json() vor seinen Routen.
Verwende diesen Handler, um Dodo Payments Checkout in deine Express-App zu integrieren. Unterstützt statische (GET), dynamische (POST) und Session-basierte (POST) Zahlungsabläufe. Registriere jeden POST-Ablauf unter einem eigenen Pfad, da der zuerst für einen Pfad registrierte Handler jede Anfrage an diesen Pfad beantwortet.

Checkout-Route-Handler

Der Adapter unterstützt alle drei Dodo Payments-Checkout-Abläufe. Lege type in der Handler-Konfiguration fest, um den von einer Route bereitgestellten Ablauf auszuwählen. Jeder Ablauf antwortet mit JSON, das eine checkout_url enthält, die der Kunde öffnen kann.
  • Statische Payment Links: type: "static", GET. Erstellt anhand von Query-Parametern einen Payment Link für ein Produkt, nachdem geprüft wurde, dass das Produkt existiert.
  • Dynamische Payment Links: type: "dynamic", POST. Erstellt eine einmalige Zahlung oder ein Abonnement mit einem Payment Link, abhängig davon, ob das Produkt wiederkehrend ist.
  • Checkout-Sessions: type: "session", POST. Erstellt eine Checkout-Session aus einem Produkt-Warenkorb und Kundendaten. Verwende diesen Ablauf für neue Integrationen.
checkoutHandler akzeptiert die folgenden Optionen: Registriere den Handler für GET, wenn type static entspricht, und für POST, wenn type dynamic oder session entspricht. Der Handler gibt für andere Methoden 405 zurück.

Unterstützte Query-Parameter

string
erforderlich
Produktkennung, zum Beispiel ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
Standard:"1"
Menge des Produkts.
string
Vollständiger Name des Kunden. Wird ignoriert, wenn firstName oder lastName angegeben ist.
string
Vorname des Kunden.
string
Nachname des Kunden.
string
E-Mail-Adresse des Kunden.
string
Land des Kunden als ISO-3166-1-Alpha-2-Code.
string
Straßenadresse des Kunden.
string
Ort des Kunden.
string
Bundesland oder Region des Kunden.
string
Postleitzahl oder ZIP-Code des Kunden.
boolean
Auf true setzen, um das Feld für den vollständigen Namen zu deaktivieren.
boolean
Auf true setzen, um das Vornamenfeld zu deaktivieren.
boolean
Auf true setzen, um das Nachnamenfeld zu deaktivieren.
boolean
Auf true setzen, um das E-Mail-Feld zu deaktivieren.
boolean
Auf true setzen, um das Länderfeld zu deaktivieren.
boolean
Auf true setzen, um das Feld für die Adresszeile zu deaktivieren.
boolean
Auf true setzen, um das Ortsfeld zu deaktivieren.
boolean
Auf true setzen, um das Feld für das Bundesland zu deaktivieren.
boolean
Auf true setzen, um das ZIP-Code-Feld zu deaktivieren.
string
Die Zahlungswährung, zum Beispiel USD.
boolean
Standard:"true"
Währungswähler ein- oder ausblenden.
number
Legt den berechneten Betrag in Haupteinheiten der Währung fest, zum Beispiel 12.5 für $12.50. Funktioniert nur mit Pay-What-You-Want-Produkten und wird ignoriert, wenn der Wert unter dem Mindestpreis des Produkts liegt.
boolean
Standard:"true"
Rabattbereich ein- oder ausblenden.
string
Jeder Query-Parameter, der mit metadata_ beginnt, wird als Metadaten an Checkout übergeben, zum Beispiel metadata_orderId=123.
Ein Deaktivierungs-Flag wird nur wirksam, wenn es true entspricht und das zugehörige Feld einen Wert enthält, zum Beispiel email mit disableEmail. Der Handler übergibt diese Parameter an einen statischen Payment Link.
Wenn productId fehlt, gibt der Handler eine 400-Antwort zurück. Ungültige Query-Parameter oder ein Produkt, das in deinem Konto nicht existiert, führen ebenfalls zu einer 400-Antwort.

Antwortformat

Statischer Checkout gibt eine JSON-Antwort mit der Checkout-URL zurück:
  • Sende Parameter als JSON-Body in einer POST-Anfrage.
  • Unterstützt einmalige und wiederkehrende Zahlungen. Der Handler ruft das Produkt ab und erstellt anschließend ein Abonnement, wenn das Produkt wiederkehrend ist, andernfalls eine einmalige Zahlung.
  • Der Body benötigt billing (mit street, city, state, country und zipcode) sowie customer und zusätzlich product_id (mit einem optionalen quantity) oder product_cart. Abonnements benötigen product_id.
  • Der Handler leitet außerdem metadata, allowed_payment_method_types, billing_currency, discount_codes (oder das veraltete discount_code), return_url, show_saved_payment_methods und tax_id weiter. Bei Abonnements leitet er zusätzlich addons, on_demand und trial_period_days weiter. Andere Felder werden ignoriert.
  • Details zu den Feldern findest du hier:
Dynamic Checkout verwendet die veralteten Endpunkte POST /payments und POST /subscriptions. Verwende Checkout Sessions für neue Integrationen.

Antwortformat

Dynamic Checkout gibt eine JSON-Antwort zurück, die den Payment Link als Checkout-URL enthält:
Sende eine Checkout-Session-Nutzlast als JSON-Body. Der Handler erstellt eine Checkout-Session, die den vollständigen Zahlungsablauf für einmalige Käufe und Abonnements abwickelt, und gibt deren checkout_url zurück. product_cart ist erforderlich und muss mindestens ein Produkt enthalten.Jede checkout_url kann einmal verwendet werden und läuft nach 24 Stunden ab oder nach 15 Minuten, wenn du confirm: true übergibst. Eine mit payment_method_id erstellte Session gibt keine checkout_url zurück, daher antwortet der Handler mit 400.Weitere Informationen und eine vollständige Liste der unterstützten Felder findest du im Integrationsleitfaden für Checkout Sessions.

Antwortformat

Checkout Sessions geben eine JSON-Antwort mit der Checkout-URL zurück:

Customer-Portal-Route-Handler

Der Customer-Portal-Route-Handler erstellt eine Customer-Portal-Session für den Kunden in customer_id und leitet die Anfrage an den Portal-Link weiter. CustomerPortal akzeptiert die Optionen bearerToken und environment, ebenso wie checkoutHandler. Wenn Dodo Payments die Session nicht erstellen kann, gibt der Handler 500 zurück.

Query-Parameter

string
erforderlich
Die Kunden-ID für die Portal-Session, zum Beispiel ?customer_id=cus_123.
boolean
Wenn auf true gesetzt, wird dem Kunden eine E-Mail mit dem Portal-Link gesendet.
Gibt 400 zurück, wenn customer_id fehlt. Der Handler authentifiziert die Anfrage nicht und öffnet das Portal für jede empfangene customer_id. Schütze die Route daher mit deiner eigenen Authentifizierung und übergib nur die Kunden-ID des angemeldeten Benutzers.

Webhook-Route-Handler

Der Webhook-Handler verifiziert jede Anfrage mit deinem Webhook-Geheimnis, das als webhookKey übergeben wird, und ruft anschließend deine Event-Handler auf.
Registriere express.json() vor der Webhook-Route. Der Handler verifiziert die Signatur anhand von req.body und weist jede Anfrage zurück, sofern der Body nicht als JSON geparst wurde. Verwende express.raw() nicht für diese Route.
  • Methode: Es werden nur POST-Anfragen unterstützt. Andere Methoden geben 405 zurück.
  • Signaturverifizierung: Verifiziert die Header webhook-id, webhook-timestamp und webhook-signature mit webhookKey gemäß der Spezifikation Standard Webhooks. Gibt 401 zurück, wenn die Verifizierung fehlschlägt.
  • Validierung der Nutzlast: Wird mit Zod validiert. Gibt 400 für ungültige Nutzlasten zurück.
  • Fehlerbehandlung:
    • 401: Ungültige Signatur
    • 400: Ungültige Nutzlast
    • 500: Interner Fehler während der Verifizierung
  • Event-Routing: Ruft für jedes Event onPayload und anschließend den Handler für den Event-Typ auf. Nach deren Abschluss wird 200 zurückgegeben. Der Handler fängt keine Fehler ab, die deine Event-Handler auslösen.

Unterstützte Webhook-Event-Handler

Jeder Handler ist optional und asynchron. Informationen zur Nutzlast jedes Events findest du im Webhook-Event-Leitfaden.

Prompt für LLM

Zuletzt geändert am 28. September 2026