Skip to main content
Il pacchetto @dodopayments/remix fornisce alla tua app Remix tre gestori delle richieste. Checkout restituisce gli URL di checkout, CustomerPortal invia un cliente al Customer Portal e Webhooks verifica gli eventi webhook e li indirizza al tuo codice. Ogni gestore accetta un Request e restituisce un Response, quindi lo richiami dal loader o dal action di una route.

Checkout Handler

Crea URL di checkout dalla tua app Remix.

Customer Portal

Permetti ai clienti di gestire i propri abbonamenti e dati.

Webhooks

Ricevi e verifica gli eventi webhook di Dodo Payments.

Installazione

1

Install the Package

Esegui questo comando nella root del progetto:
Il pacchetto elenca Remix 2 (remix 2.16.8 o versioni successive) e zod 3.25 o versioni successive come peer dependencies.
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. DODO_PAYMENTS_RETURN_URL è la pagina su cui arrivano i clienti dopo il checkout. Se non passi un environment, i gestori usano live_mode.
Non eseguire mai il commit del file .env o dei secrets nel controllo versione.

Esempi di route handler

Gli esempi sono resource route di Remix, che esportano un loader per le richieste GET o un action per le richieste POST e nessun componente. Con le flat file route, app/routes/api.checkout.tsx gestisce /api/checkout.
Usa questo gestore per aggiungere il checkout di Dodo Payments alla tua app Remix. loader gestisce il checkout statico. action gestisce qui il checkout dinamico. Per gestire le sessioni di checkout, il flusso consigliato, restituisci invece checkoutSessionHandler(request) da action.
La richiesta della sessione di checkout funziona quando action restituisce checkoutSessionHandler(request).

Checkout Route Handler

Il checkout handler supporta tutti e tre i modi per accettare pagamenti con Dodo Payments:
  • Static Payment Links: URL condivisibili che raccolgono i pagamenti senza codice.
  • Dynamic Payment Links: link di pagamento generati con dettagli personalizzati. Usano endpoint deprecati.
  • Checkout Sessions: checkout ospitato con un carrello di prodotti, i dati del cliente e opzioni di personalizzazione. Questo è il flusso consigliato.
Checkout accetta queste opzioni:

Parametri di query supportati

string
obbligatorio
Identificativo 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
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 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 come metadata.
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 e gli ID prodotto inesistenti restituiscono 400.

Formato della risposta

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

Formato della risposta

Il checkout dinamico restituisce una risposta JSON con l’URL di checkout:
Le checkout sessions 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 ulteriori dettagli e per l’elenco completo dei campi supportati, consulta la Guida all’integrazione delle Checkout Sessions.Una sessione 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 sessione con l’SDK.

Formato della risposta

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

Customer Portal Route Handler

Il route handler del Customer Portal crea una sessione del Customer Portal per il cliente specificato e reindirizza il browser verso di essa con una risposta 307.
Il gestore non verifica chi lo sta richiamando. Chiunque lo richiami 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.

Parametri di query

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

Webhook Route Handler

Il route handler dei 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 e gli header webhook-id, webhook-timestamp e webhook-signature con webhookKey, secondo la specifica Standard Webhooks. Restituisce 401 se la verifica non riesce.
  • Validazione del payload: valida il payload con Zod. Restituisce 400 per un payload non valido.
  • Gestione degli errori:
    • 401: firma non valida
    • 400: payload non valido
    • 500: errore interno durante la verifica
  • Routing degli eventi: richiama onPayload per ogni evento, quindi il gestore corrispondente al tipo di evento, e restituisce 200.
L’adapter non intercetta gli errori generati dai tuoi gestori. Gli errori si propagano a Remix e la richiesta non va a buon fine.

Gestori degli eventi webhook supportati

Ogni gestore riceve il payload verificato relativo al proprio tipo di evento:
Per informazioni sul significato di ogni evento, consulta la Guida agli eventi webhook.

Prompt per LLM

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