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

Checkout Handler

Erstelle Payment Links und Checkout-Sessions aus deiner Fastify-App.

Customer Portal

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

Webhooks

Überprüfe und verarbeite Dodo Payments-Webhooks.

Installation

1

Install the Package

Führe den folgenden Befehl im Stammverzeichnis deines Projekts aus:
Das Paket erfordert Fastify 5.4.0 oder höher.
2

Set Up Environment Variables

Erstelle im Stammverzeichnis deines Projekts eine .env-Datei:
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 für den Testmodus mit DODO_PAYMENTS_ENVIRONMENT=test_mode, da ein Schlüssel für den Testmodus nur im Testmodus funktioniert. DODO_PAYMENTS_RETURN_URL ist optional.
Füge deine .env-Datei oder Geheimnisse niemals zur Versionsverwaltung hinzu.

Beispiele für Routen-Handler

Die Beispiele registrieren Routen auf einer mit Fastify() erstellten Fastify-Instanz. Die Webhook-Route benötigt den unverarbeiteten Request-Body. Daher fügt das Beispiel einen String-Body-Parser innerhalb eines Plugins hinzu, das nur die Webhook-Route enthält.
Verwende diesen Handler, um Dodo Payments Checkout in deine Fastify-App zu integrieren. Unterstützt statische (GET), dynamische (POST) und Session-basierte (POST) Payment-Flows. Checkout() gibt für den statischen Flow eine getHandler und für die dynamischen und Session-Flows eine postHandler zurück. Registriere jeden POST-Flow unter einem eigenen Pfad.

Checkout-Routen-Handler

Der Adapter unterstützt alle drei Dodo Payments-Checkout-Flows. Setze type in der Handler-Konfiguration, um den Flow auszuwählen, den eine Route bereitstellt. Jeder Flow 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 überprüft wurde, dass das Produkt existiert.
  • Dynamische Payment Links: type: "dynamic", POST. Erstellt abhängig davon, ob das Produkt wiederkehrend ist, eine einmalige Zahlung oder ein Abonnement mit einem Payment Link.
  • Checkout-Sessions: type: "session", POST. Erstellt eine Checkout-Session anhand eines Produkt-Warenkorbs und von Kundendaten. Verwende diesen Flow für neue Integrationen.
Checkout akzeptiert die folgenden Optionen: Checkout gibt ein Objekt mit zwei Handlern zurück. Registriere getHandler für GET, wenn type static ist, und postHandler für POST, wenn type dynamic oder session ist.

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
Stadt des Kunden.
string
Bundesland oder Provinz des Kunden.
string
Postleitzahl 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 Adressfeld zu deaktivieren.
boolean
Auf true setzen, um das Stadtfeld zu deaktivieren.
boolean
Auf true setzen, um das Feld für das Bundesland zu deaktivieren.
boolean
Auf true setzen, um das Postleitzahlfeld zu deaktivieren.
string
Die Zahlungswährung, zum Beispiel USD.
boolean
Standard:"true"
Währungswähler ein- oder ausblenden.
number
Legt den berechneten Betrag in den 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 ist und das entsprechende 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

Statisches Checkout gibt eine JSON-Antwort mit der Checkout-URL zurück:
  • Übergebe 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) und customer sowie 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. Für Abonnements leitet er zusätzlich addons, on_demand und trial_period_days weiter. Andere Felder werden ignoriert.
  • Einzelheiten zu den Feldern findest du unter:
Dynamic Checkout ruft die veralteten Endpunkte POST /payments und POST /subscriptions auf. Verwende für neue Integrationen Checkout-Sessions.

Antwortformat

Dynamic Checkout gibt eine JSON-Antwort mit dem Payment Link als Checkout-URL zurück:
Sende eine Checkout-Session-Payload 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 funktioniert einmal 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-Routen-Handler

Der Customer-Portal-Routen-Handler erstellt eine Customer-Portal-Session für den Kunden in customer_id und leitet die Anfrage zum Portal-Link weiter. CustomerPortal akzeptiert die Optionen bearerToken und environment, genauso wie Checkout. 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-Routen-Handler

Der Webhook-Handler überprüft jede Anfrage mit deinem Webhook-Geheimnis, das als webhookKey übergeben wird, und ruft anschließend deine Event-Handler auf.
Der Webhook-Handler benötigt den unverarbeiteten Request-Body als String. Füge für application/json einen Content-Type-Parser mit parseAs: 'string' hinzu. Fastify wendet einen Parser auf jede Route in dem Bereich an, in dem du ihn hinzufügst. Füge ihn wie im Beispiel innerhalb eines Plugins hinzu, das nur die Webhook-Route registriert. Auf der Root-Instanz würde er auch den POST-Checkout-Handlern einen String übergeben, woraufhin diese 400 zurückgeben.
  • Methode: Es werden nur POST-Anfragen unterstützt. Andere Methoden geben 405 zurück.
  • Signaturüberprüfung: Überprüft die Header webhook-id, webhook-timestamp und webhook-signature mit webhookKey gemäß der Standard-Webhooks-Spezifikation. Gibt 401 zurück, wenn die Überprüfung fehlschlägt.
  • Payload-Validierung: Wird mit Zod validiert. Ungültige Payloads führen zu 400.
  • Fehlerbehandlung:
    • 401: Ungültige Signatur
    • 400: Ungültige Payload
    • 500: Interner Fehler bei der Überprüfung
  • Event-Routing: Ruft für jedes Ereignis onPayload und anschließend den Handler für den Ereignistyp auf und gibt nach deren Abschluss 200 zurück. Der Handler fängt keine Fehler ab, die deine Event-Handler auslösen.

Unterstützte Webhook-Event-Handler

Jeder Handler ist optional und asynchron. Die Payload jedes Ereignisses findest du im Webhook-Event-Leitfaden.

Prompt für LLM

Zuletzt geändert am 26. September 2026