@dodopayments/hono fornisce alla tua app Hono 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 Hono.
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 directory principale del progetto:Il pacchetto richiede Hono 4.8.9 o versione successiva.
2
Set Up Environment Variables
Crea un file Crea la API key in Developer → API Keys. Aggiungi l’endpoint webhook in Developer → Webhooks e copia il relativo signing secret in
.env nella directory principale del progetto: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.Esempi di handler delle route
Gli esempi registrano le route su un’app Hono creata con
new Hono(). Gli handler leggono autonomamente il body della richiesta, quindi non richiedono middleware per il parsing del body.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Usa questo handler per integrare il checkout di Dodo Payments nella tua app Hono. Supporta i flussi static (GET), dinamici (POST) e di sessione (POST). Registra ogni flusso POST su un percorso distinto, perché Hono si ferma al primo handler eseguito per una richiesta.
Handler della route di checkout
L’adattatore supporta tutti e tre i flussi di checkout di Dodo Payments. Imposta
type nella configurazione dell’handler per scegliere il flusso servito dalla route. Ogni flusso risponde con JSON contenente un checkout_url che il cliente può aprire.- Payment Link statici:
type: "static", GET. Crea un payment link per un prodotto a partire dai query parameters, dopo aver verificato che il prodotto esista. - Payment Link dinamici:
type: "dynamic", POST. Crea un pagamento una tantum o un abbonamento con un payment link, a seconda che il prodotto sia ricorrente. - Checkout session:
type: "session", POST. Crea una checkout session a partire da un carrello di prodotti e dai dati del cliente. Usa questo flusso per le nuove integrazioni.
Checkout accetta queste opzioni:
Registra l’handler per GET quando
type è static e per POST quando type è dynamic o session. L’handler tratta ogni richiesta che non è POST come una richiesta di checkout statico.
Static Checkout (GET)
Static Checkout (GET)
Query Parameters 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 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 nascondi il selettore della valuta.
number
Imposta l’importo addebitato, espresso 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 query parameter che inizia con
metadata_ viene passato al checkout come metadata, ad esempio metadata_orderId=123.true e il campo corrispondente ha un valore, ad esempio email con disableEmail. L’handler passa questi parametri a un payment link statico.Formato della risposta
Il checkout statico restituisce una risposta JSON con l’URL di checkout:Dynamic Checkout (POST)
Dynamic Checkout (POST)
- 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 in caso contrario.
- Il body richiede
billing(constreet,city,state,countryezipcode) ecustomer, oltre aproduct_id(con unquantityfacoltativo) oproduct_cart. Gli abbonamenti richiedonoproduct_id. - L’handler inoltra anche
metadata,allowed_payment_method_types,billing_currency,discount_codes(oppure il deprecatodiscount_code),return_url,show_saved_payment_methodsetax_id. Per gli abbonamenti inoltra ancheaddons,on_demandetrial_period_days. Ignora gli altri campi. - Per i dettagli dei campi, consulta:
Formato della risposta
Il checkout dinamico restituisce una risposta JSON con il payment link come URL di checkout:Checkout Sessions (POST)
Checkout Sessions (POST)
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, 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 l’handler risponde con 400.Per ulteriori dettagli e per l’elenco completo dei campi supportati, consulta la Guida all’integrazione di Checkout Sessions.Formato della risposta
Le checkout session restituiscono una risposta JSON con l’URL di checkout:Handler della route Customer Portal
L’handler della route Customer Portal crea una sessione Customer Portal per il cliente incustomer_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 Parameters
string
obbligatorio
L’ID del 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.Handler della route webhook
L’handler webhook verifica ogni richiesta con il secret webhook, passato comewebhookKey, quindi chiama i tuoi event handler. Legge autonomamente il body grezzo della richiesta, quindi la route non richiede middleware per il parsing del body.
- Metodo: sono supportate solo le richieste POST. Gli altri metodi restituiscono 405.
- Verifica della firma: verifica gli header
webhook-id,webhook-timestampewebhook-signatureconwebhookKey, 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
- Routing degli eventi: chiama
onPayloadper ogni evento, quindi l’handler relativo al tipo di evento, e restituisce 200 al termine. L’handler non intercetta gli errori generati dai tuoi event handler.