Skip to main content
Il pacchetto @dodopayments/nextjs fornisce al tuo progetto Next.js App Router tre gestori di route. Checkout restituisce gli URL di checkout, CustomerPortal invia il cliente al Customer Portal e Webhooks verifica gli eventi webhook e li inoltra al tuo codice. Il pacchetto supporta Next.js 14, 15 e 16.

Checkout Handler

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

Customer Portal

Consenti ai clienti di gestire i propri abbonamenti e dettagli.

Webhooks

Ricevi ed elabora gli eventi webhook di Dodo Payments.

Installazione

1

Install the Package

Esegui questo comando nella root del progetto:
Il pacchetto richiede inoltre Zod 3.25 o Zod 4 come peer dependency.
2

Set Up Environment Variables

Crea un file .env nella root del progetto. Crea la API key in Developer → API Keys e il webhook secret in Developer → Webhooks nella dashboard:
DODO_PAYMENTS_RETURN_URL è la pagina sulla quale arrivano i clienti dopo il checkout. Se non passi un ambiente, i gestori usano live_mode.
Non eseguire mai il commit del file .env o dei secret nel controllo versione.

Esempi di gestori di route

Tutti gli esempi presuppongono l’utilizzo di Next.js App Router.
Usa questo gestore per aggiungere il checkout Dodo Payments alla tua app. Un gestore GET gestisce il checkout statico. Un gestore POST gestisce le checkout session oppure il checkout dinamico quando imposti type: "dynamic".

Gestore della route di checkout

Il gestore di checkout supporta tutti e tre i modi per accettare pagamenti con Dodo Payments:
  • Payment Links statici: URL condivisibili che raccolgono pagamenti senza codice.
  • Payment Links dinamici: payment link generati con dettagli personalizzati. Utilizzano endpoint deprecati.
  • Checkout Sessions: checkout ospitato con carrello dei prodotti, dettagli del cliente e opzioni di personalizzazione. Questo è il flusso consigliato.

Query Parameters supportati

string
obbligatorio
Identificatore del prodotto, ad esempio ?productId=pdt_123.
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
Riga dell’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 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 CAP.
string
Valuta del pagamento, ad esempio USD.
boolean
predefinito:"true"
Mostra o nascondi il selettore della valuta.
number
Fissa 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 nascondi la sezione degli sconti.
string
Qualsiasi query parameter che inizia con metadata_ viene passato come metadata.
Il gestore aggiunge returnUrl dalla propria configurazione al link come redirect_url.
Se productId manca, il gestore restituisce una risposta 400. Anche i query parameters non validi e gli ID prodotto inesistenti restituiscono 400.

Formato della risposta

Il checkout statico restituisce una risposta JSON con l’URL di checkout. In modalità test, l’URL utilizza 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 checkout session.

Formato della risposta

Il checkout dinamico restituisce una risposta JSON con l’URL di checkout:
Le checkout session creano un checkout ospitato per acquisti una tantum e abbonamenti, con pieno controllo sulla personalizzazione. product_cart è l’unico campo obbligatorio. Se il body non contiene return_url, il gestore usa returnUrl dalla propria configurazione.Per maggiori dettagli e per tutti i field supportati, consulta la Checkout Sessions Integration Guide.Una session creata con payment_method_id non restituisce alcun URL di checkout, quindi il gestore risponde con 400. Per addebitare un metodo di pagamento salvato, crea la session con l’SDK.

Formato della risposta

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

Gestore della route Customer Portal

Il gestore della route Customer Portal crea una session Customer Portal per il cliente specificato e reindirizza il browser a essa.
Il gestore non verifica chi lo sta chiamando. Chiunque lo richieda con un customer ID ottiene il portale di quel cliente. Proteggi la route con il tuo sistema di autenticazione e passa solo il customer ID dell’utente autenticato.

Query Parameters

string
obbligatorio
Il customer ID per la session 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 manca e 500 se non è possibile creare la session del portale.

Gestore della route webhook

Il gestore della route webhook verifica ogni richiesta prima di eseguire il tuo codice:
  • Metodo: Sono supportate solo le richieste POST. Gli altri metodi restituiscono 405.
  • Verifica della firma: Verifica il body raw della richiesta rispetto agli header webhook-id, webhook-timestamp e webhook-signature con webhookKey. Restituisce 401 se la verifica fallisce.
  • Validazione del payload: Analizza il body verificato come JSON e lo valida con Zod. Restituisce 400 quando un payload analizzato non corrisponde allo schema webhook.
  • Gestione degli errori:
    • 401: Firma non valida
    • 400: Payload non valido
    • 500: Errori imprevisti di verifica, JSON malformato o errori generati dai tuoi callback
  • Routing degli eventi: Chiama onPayload per ogni evento, quindi il gestore relativo al tipo di evento e restituisce 200.
L’adattatore non intercetta gli errori generati dai tuoi gestori. Gli errori vengono propagati a Next.js e la richiesta fallisce.

Gestori degli eventi webhook supportati

Ogni gestore riceve il payload verificato per il relativo tipo di evento:
Per informazioni sul significato di ogni evento, consulta la Webhook Event Guide.

Prompt per LLM

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