Skip to main content
Il pacchetto @dodopayments/bun fornisce al tuo server Bun tre gestori di richieste. Checkout restituisce URL di checkout, CustomerPortal invia un cliente al Customer Portal e Webhooks verifica gli eventi webhook e li instrada al tuo codice. Ogni gestore accetta un Request standard e restituisce un Response, quindi lo richiami dal gestore fetch di Bun.serve().

Checkout Handler

Crea URL di checkout con flussi statici, dinamici e di sessione di checkout.

Customer Portal

Consenti ai clienti di gestire abbonamenti e dati personali.

Webhooks

Ricevi ed elabora gli eventi webhook di Dodo Payments.

Installazione

1

Install the Package

Esegui questo comando nella directory principale del progetto:
Il pacchetto richiede anche zod 3.25 o versione successiva, indicata come peer dependency.
2

Set Up Environment Variables

Crea un file .env nella directory principale del progetto. Crea la API key in Developer → API Keys. Aggiungi il tuo endpoint webhook in Developer → Webhooks e copia il suo Signing secret in DODO_PAYMENTS_WEBHOOK_KEY:
Bun legge automaticamente i file .env, quindi gli esempi leggono questi valori da process.env. DODO_PAYMENTS_RETURN_URL è la pagina in cui arrivano i clienti dopo il checkout. Se non passi un ambiente, i gestori usano live_mode. Una API key in modalità test funziona solo con test_mode.
Non eseguire mai il commit del file .env o dei secrets nel controllo versione.

Esempi di gestori di route

Tutti gli esempi usano il server nativo di Bun, Bun.serve(), e instradano le richieste in base al percorso e al metodo nel relativo gestore fetch.
Usa questo gestore per aggiungere il checkout Dodo Payments al tuo server Bun. Il gestore statico serve le richieste GET. I gestori di sessione e dinamici servono le richieste POST. L’esempio di checkout dinamico presuppone che il server restituisca dynamicCheckoutHandler(request) per le richieste POST.

Gestore di route per il checkout

Il gestore di checkout supporta tutti e tre i modi per accettare pagamenti con Dodo Payments:
  • Link di pagamento statici: URL condivisibili che raccolgono pagamenti senza codice.
  • Link di pagamento dinamici: link di pagamento generati con dettagli personalizzati. Usano endpoint deprecati.
  • Sessioni di checkout: checkout ospitato con carrello dei prodotti, dati del cliente e opzioni di personalizzazione. Questo è il flusso consigliato.
Checkout accetta queste opzioni: Il gestore serve il checkout statico per le richieste GET. Per le richieste POST, crea un link di pagamento dinamico quando type è dynamic e, negli altri casi, una sessione di checkout.

Parametri di query supportati

string
obbligatorio
Identificatore del prodotto, ad esempio ?productId=pdt_xxx.
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
CAP o codice postale 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 CAP.
string
Valuta del pagamento, ad esempio USD.
boolean
predefinito:"true"
Mostra o nascondi il selettore della valuta.
number
Fissa l’importo addebitato, in unità principali della valuta, ad esempio 12.5 per $12.50. Funziona solo con prodotti Pay What You Want e viene ignorato se è inferiore al prezzo minimo del prodotto.
boolean
predefinito:"true"
Mostra o nascondi 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 il campo corrispondente contiene un valore, ad esempio email con disableEmail=true. Il gestore aggiunge returnUrl dalla propria configurazione al link come redirect_url.
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 restituiscono 400.

Formato della risposta

Il checkout statico restituisce una risposta JSON con l’URL di checkout. In modalità test, l’URL usa test.checkout.dodopayments.com:
Il checkout dinamico fa da proxy per gli endpoint deprecati POST /payments e POST /subscriptions. Continua a funzionare per le integrazioni esistenti, ma per le nuove integrazioni è consigliabile usare le sessioni di checkout.

Formato della risposta

Il checkout dinamico restituisce una risposta JSON con il link di pagamento come URL di checkout:
Le sessioni di checkout creano un checkout ospitato per acquisti una tantum e abbonamenti, con pieno controllo sulla personalizzazione. product_cart è l’unico campo obbligatorio e richiede almeno un prodotto. Se il body non contiene return_url, il gestore usa returnUrl dalla propria configurazione.Ogni checkout_url funziona una sola volta e scade dopo 24 ore, oppure dopo 15 minuti quando passi confirm: true. Una sessione creata con payment_method_id non restituisce checkout_url, quindi il gestore risponde con 400.Per ulteriori dettagli e per tutti i campi supportati, consulta la Guida all’integrazione delle sessioni di checkout.

Formato della risposta

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

Gestore di route del Customer Portal

Il gestore di route del Customer Portal crea una sessione Customer Portal per il cliente specificato e reindirizza il browser a essa. CustomerPortal accetta le stesse opzioni bearerToken e environment di Checkout.
Il gestore non verifica chi lo sta chiamando. Chiunque lo richiami con un ID cliente ottiene il portale di quel cliente. Proteggi la route con la tua autenticazione e passa solo l’ID cliente dell’utente autenticato.

Parametri di query

string
obbligatorio
L’ID cliente per la sessione del portale, ad esempio ?customer_id=cus_123.
boolean
Se impostato su true, Dodo Payments invia anche il link del portale al cliente tramite email.
Il gestore restituisce 400 se customer_id è assente e 500 se non è possibile creare la sessione del portale.

Gestore di route webhook

Il gestore di route webhook verifica ogni richiesta con il tuo secret webhook, passato come webhookKey, prima di eseguire il tuo codice:
  • 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, seguendo la specifica Standard Webhooks. Restituisce 401 se la verifica non riesce.
  • Convalida del payload: analizza il body come JSON e lo convalida con Zod. Restituisce 400 per JSON non valido o payload non valido.
  • 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.
L’adapter non intercetta gli errori generati nei tuoi gestori. Questi si propagano a Bun.serve() e la richiesta non va a buon fine.

Gestori degli eventi webhook supportati

Ogni gestore è facoltativo e asincrono e riceve il payload verificato per il proprio tipo di evento:
Per conoscere il significato di ogni evento, consulta la Guida agli eventi webhook.

Prompt per LLM

Copia questo prompt nel tuo assistente di coding AI per aggiungere l’adapter al tuo progetto. Per fornire al tuo agente anche la documentazione e le competenze di Dodo Payments, installa il Plugin Agent.
Ultima modifica il 26 settembre 2026