Skip to main content
L’adapter @dodopayments/fastify fornisce alla tua app Fastify tre handler di route: Checkout restituisce gli URL di checkout, CustomerPortal invia un cliente al Customer Portal e Webhooks verifica le richieste webhook e chiama i tuoi event handler.

Checkout Handler

Crea payment link e sessioni di checkout dalla tua app Fastify.

Customer Portal

Permetti ai clienti di gestire i propri abbonamenti e dettagli.

Webhooks

Verifica ed elabora gli eventi webhook di Dodo Payments.

Installazione

1

Install the Package

Esegui il comando seguente nella root del progetto:
Il pacchetto richiede Fastify 5.4.0 o versioni successive.
2

Set Up Environment Variables

Crea un file .env nella root del progetto:
Crea la API key in Developer → API Keys. Aggiungi il tuo endpoint webhook in Developer → Webhooks e copia il relativo signing secret in DODO_PAYMENTS_WEBHOOK_KEY. Durante lo sviluppo, usa una API key in test mode con DODO_PAYMENTS_ENVIRONMENT=test_mode, perché una chiave in test mode funziona solo con test mode. DODO_PAYMENTS_RETURN_URL è facoltativo.
Non eseguire mai il commit del file .env o dei secret nel controllo versione.

Esempi di route handler

Gli esempi registrano le route su un’istanza Fastify creata con Fastify(). La route webhook richiede il body raw della richiesta, quindi l’esempio aggiunge un body parser stringa all’interno di un plugin che contiene solo la route webhook.
Usa questo handler per integrare il checkout di Dodo Payments nella tua app Fastify. Supporta i flussi di pagamento static (GET), dynamic (POST) e session (POST). Checkout() restituisce un getHandler per il flusso static e un postHandler per i flussi dynamic e session. Registra ogni flusso POST su un percorso separato.

Checkout Route Handler

L’adapter supporta tutti e tre i flussi di checkout di Dodo Payments. Imposta type nella configurazione dell’handler per scegliere il flusso servito da una route. Ogni flusso risponde con JSON contenente un checkout_url che il cliente può aprire.
  • Static Payment Links: type: "static", GET. Crea un payment link per un prodotto dai query parameter, dopo aver verificato che il prodotto esista.
  • Dynamic Payment Links: type: "dynamic", POST. Crea un pagamento una tantum o un abbonamento con un payment link, in base al fatto che il prodotto sia ricorrente.
  • Checkout Sessions: type: "session", POST. Crea una checkout session da un carrello di prodotti e dai dettagli del cliente. Usa questo flusso per le nuove integrazioni.
Checkout accetta queste opzioni: Checkout restituisce un oggetto con due handler. Registra getHandler per GET quando type è static, e postHandler per POST quando type è dynamic o session.

Query parameter supportati

string
obbligatorio
Identificatore del prodotto, ad esempio ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
predefinito:"1"
Quantità del prodotto.
string
Nome completo del cliente. Ignorato se vengono forniti firstName o lastName.
string
Nome del cliente.
string
Cognome del cliente.
string
Indirizzo email del cliente.
string
Paese del cliente, come codice ISO 3166-1 alpha-2.
string
Indirizzo del cliente.
string
Città del cliente.
string
Stato o provincia del cliente.
string
Codice postale o ZIP del cliente.
boolean
Imposta su true per disabilitare il campo del nome completo.
boolean
Imposta su true per disabilitare il campo del nome.
boolean
Imposta su true per disabilitare il campo del cognome.
boolean
Imposta su true per disabilitare il campo dell’email.
boolean
Imposta su true per disabilitare il campo del Paese.
boolean
Imposta su true per disabilitare il campo della riga dell’indirizzo.
boolean
Imposta su true per disabilitare il campo della città.
boolean
Imposta su true per disabilitare il campo dello stato.
boolean
Imposta su true per disabilitare il campo del codice ZIP.
string
La valuta del pagamento, ad esempio USD.
boolean
predefinito:"true"
Mostra o nasconde il selettore della valuta.
number
Imposta l’importo addebitato, nelle unità principali della valuta, ad esempio 12.5 per $12.50. Funziona solo con i prodotti Pay What You Want e viene ignorato se è inferiore al prezzo minimo del prodotto.
boolean
predefinito:"true"
Mostra o nasconde la sezione degli sconti.
string
Qualsiasi query parameter che inizia con metadata_ viene passato al checkout come metadata, ad esempio metadata_orderId=123.
Un flag di disabilitazione ha effetto solo quando è true e il campo corrispondente ha un valore, ad esempio email con disableEmail. L’handler passa questi parametri a un payment link statico.
Se productId manca, l’handler restituisce una risposta 400. Anche query parameter non validi o un prodotto che non esiste nel tuo account producono una risposta 400.

Formato della risposta

Il checkout static restituisce una risposta JSON con l’URL di checkout:
  • Invia i parametri come body JSON in una richiesta POST.
  • Supporta pagamenti una tantum e ricorrenti. L’handler recupera il prodotto, quindi crea un abbonamento se il prodotto è ricorrente e un pagamento una tantum altrimenti.
  • Il body richiede billing (con street, city, state, country e zipcode) e customer, oltre a product_id (con un quantity facoltativo) o product_cart. Gli abbonamenti richiedono product_id.
  • L’handler inoltra anche metadata, allowed_payment_method_types, billing_currency, discount_codes (o il deprecato discount_code), return_url, show_saved_payment_methods e tax_id. Per gli abbonamenti inoltra anche addons, on_demand e trial_period_days. Ignora gli altri campi.
  • Per i dettagli dei campi, consulta:
Dynamic Checkout chiama gli endpoint deprecati POST /payments e POST /subscriptions. Usa Checkout Sessions per le nuove integrazioni.

Formato della risposta

Il checkout dynamic restituisce una risposta JSON con il payment link come URL di checkout:
Invia il payload della checkout session come body JSON. L’handler crea una checkout session che gestisce l’intero flusso di pagamento per acquisti una tantum e abbonamenti, quindi restituisce il relativo checkout_url. product_cart è obbligatorio e deve contenere almeno un prodotto.Ogni checkout_url funziona una sola volta e scade dopo 24 ore, o dopo 15 minuti quando passi confirm: true. Una sessione creata con payment_method_id non restituisce checkout_url, quindi l’handler risponde con 400.Per ulteriori dettagli e per l’elenco completo dei campi supportati, consulta la Checkout Sessions Integration Guide.

Formato della risposta

Le checkout session restituiscono una risposta JSON con l’URL di checkout:

Customer Portal Route Handler

Il Customer Portal Route Handler crea una sessione Customer Portal per il cliente in customer_id e reindirizza la richiesta al link del portale. CustomerPortal accetta le opzioni bearerToken e environment, come Checkout. Se Dodo Payments non riesce a creare la sessione, l’handler restituisce 500.

Query parameter

string
obbligatorio
L’ID cliente per la sessione del portale, ad esempio ?customer_id=cus_123.
boolean
Se impostato su true, invia al cliente un’email con il link del portale.
Restituisce 400 se customer_id manca. L’handler non autentica la richiesta e apre il portale per qualsiasi customer_id ricevuto, quindi proteggi la route con la tua autenticazione e passa solo l’ID cliente dell’utente autenticato.

Webhook Route Handler

Il webhook handler verifica ogni richiesta con il webhook secret, passato come webhookKey, quindi chiama i tuoi event handler.
Il webhook handler richiede il body raw della richiesta come stringa, quindi aggiungi un content type parser per application/json con parseAs: 'string'. Fastify applica un parser a ogni route nell’ambito in cui lo aggiungi. Inseriscilo in un plugin che registra solo la route webhook, come nell’esempio. Nell’istanza root, passerebbe una stringa anche agli handler POST di checkout, che risponderebbero con 400.
  • Metodo: sono supportate solo le richieste POST. Gli altri metodi restituiscono 405.
  • Verifica della firma: verifica gli header webhook-id, webhook-timestamp e webhook-signature con webhookKey, secondo la specifica Standard Webhooks. Restituisce 401 se la verifica fallisce.
  • Validazione del payload: validato con Zod. Restituisce 400 per payload non validi.
  • Gestione degli errori:
    • 401: firma non valida
    • 400: payload non valido
    • 500: errore interno durante la verifica
  • Routing degli eventi: chiama onPayload per ogni evento, quindi l’handler per il tipo di evento, e restituisce 200 al loro completamento. L’handler non intercetta gli errori generati dai tuoi event handler.

Event handler webhook supportati

Ogni handler è facoltativo e asincrono. Per il payload di ogni evento, consulta la Webhook Event Guide.

Prompt per LLM

Ultima modifica il 28 settembre 2026