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

Checkout Handler

Crea link di pagamento e sessioni di checkout dalla tua app Express.

Customer Portal

Consenti ai clienti di gestire abbonamenti e dati personali.

Webhooks

Verifica ed elabora gli eventi webhook di Dodo Payments.

Installazione

1

Install the Package

Esegui il comando seguente nella root del progetto:
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 modalità test con DODO_PAYMENTS_ENVIRONMENT=test_mode, perché una chiave in modalità test funziona solo con la modalità test. DODO_PAYMENTS_RETURN_URL è facoltativo.
Non eseguire mai il commit del file .env o dei secrets nel controllo versione.

Esempi di gestori di route

Gli esempi registrano route su un’app Express creata con express(). I gestori POST del checkout e il gestore webhook leggono req.body, quindi ogni esempio registra express.json() prima delle proprie route.
Usa questo gestore per integrare il checkout Dodo Payments nella tua app Express. Supporta i flussi di pagamento statico (GET), dinamico (POST) e tramite sessione (POST). Registra ogni flusso POST su un percorso distinto, perché il primo gestore registrato per un percorso risponde a tutte le richieste indirizzate a quel percorso.

Gestore della route di checkout

L’adapter supporta tutti e tre i flussi di checkout di Dodo Payments. Imposta type nella configurazione del gestore per scegliere il flusso servito da una route. Ogni flusso risponde con JSON contenente un checkout_url che il cliente può aprire.
  • Link di pagamento statici: type: "static", GET. Crea un link di pagamento per un prodotto a partire dai parametri della query, dopo aver verificato che il prodotto esista.
  • Link di pagamento dinamici: type: "dynamic", POST. Crea un pagamento una tantum o un abbonamento con un link di pagamento, in base al fatto che il prodotto sia ricorrente.
  • Sessioni di checkout: type: "session", POST. Crea una sessione di checkout da un carrello di prodotti e dai dati del cliente. Usa questo flusso per le nuove integrazioni.
checkoutHandler accetta queste opzioni: Registra il gestore per GET quando type è static, e per POST quando type è dynamic o session. Il gestore restituisce 405 per gli altri metodi.

Parametri di query supportati

string
obbligatorio
Identificatore del prodotto, ad esempio ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
predefinito:"1"
Quantità del prodotto.
string
Nome completo del cliente. Ignorato se viene fornito 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 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, in 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 parametro di query 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 contiene un valore, ad esempio email con disableEmail. Il gestore passa questi parametri a un link di pagamento statico.
Se productId è assente, il gestore restituisce una risposta 400. Anche i parametri di query non validi o un prodotto che non esiste nel tuo account producono una risposta 400.

Formato della risposta

Il checkout statico 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. Il gestore recupera il prodotto, quindi crea un abbonamento se il prodotto è ricorrente e un pagamento una tantum in caso contrario.
  • Il body richiede billing (con street, city, state, country e zipcode) e customer, oltre a product_id (con un quantity facoltativo) oppure product_cart. Gli abbonamenti richiedono product_id.
  • Il gestore 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:
Il checkout dinamico chiama gli endpoint deprecati POST /payments e POST /subscriptions. Usa Checkout Sessions per le nuove integrazioni.

Formato della risposta

Il checkout dinamico restituisce una risposta JSON con il link di pagamento come URL di checkout:
Invia il payload della sessione di checkout come body JSON. Il gestore crea una sessione di checkout, che gestisce il flusso completo di pagamento per acquisti una tantum e abbonamenti, e 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 alcun checkout_url, quindi il gestore risponde con 400.Consulta la Guida all’integrazione di Checkout Sessions per ulteriori dettagli e per l’elenco completo dei campi supportati.

Formato della risposta

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

Gestore della route Customer Portal

Il gestore della route Customer Portal 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 checkoutHandler. Se Dodo Payments non riesce a creare la sessione, il gestore restituisce 500.

Parametri di query

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 è assente. Il gestore non autentica la richiesta e apre il portale per qualsiasi customer_id ricevuto, quindi proteggi la route con il tuo sistema di autenticazione e passa solo l’ID cliente dell’utente autenticato.

Gestore della route webhook

Il gestore webhook verifica ogni richiesta con il tuo webhook secret, passato come webhookKey, quindi chiama i tuoi gestori di eventi.
Registra express.json() prima della route webhook. Il gestore verifica la firma rispetto a req.body, quindi rifiuta ogni richiesta a meno che il body non sia JSON analizzato. Non usare express.raw() per questa route.
  • Metodo: sono supportate solo richieste POST. Gli altri metodi restituiscono 405.
  • Verifica della firma: verifica gli header webhook-id, webhook-timestamp e webhook-signature con webhookKey, seguendo la specifica Standard Webhooks. Restituisce 401 se la verifica non riesce.
  • Validazione del payload: viene eseguita 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
  • Instradamento degli eventi: chiama onPayload per ogni evento, quindi il gestore corrispondente al tipo di evento, e restituisce 200 al termine. Il gestore non intercetta gli errori generati dai tuoi gestori di eventi.

Gestori di eventi webhook supportati

Ogni gestore è facoltativo e asincrono. Per il payload di ciascun evento, consulta la Guida agli eventi webhook.

Prompt per LLM

Ultima modifica il 26 settembre 2026