@dodopayments/tanstack fornisce al tuo progetto TanStack Start tre request handler. 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. Ogni handler accetta un Request standard e restituisce un Response, quindi puoi chiamarlo da una server route handler.
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 dati.
Webhooks
Ricevi ed elabora gli eventi webhook di Dodo Payments.
Installazione
1
Install the Package
Esegui questo comando nella root del progetto:Il package richiede inoltre
zod 3.25 o versioni successive, indicato come peer dependency.2
Set Up Environment Variables
Crea un file TanStack Start carica i 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 suo Signing secret in DODO_PAYMENTS_WEBHOOK_KEY:.env e le server route leggono i valori da process.env. DODO_PAYMENTS_RETURN_URL è la pagina alla quale vengono reindirizzati i clienti dopo il checkout. Se non passi un environment, gli handler usano live_mode. Una API key di test funziona solo con test_mode.Esempi di Route Handler
Gli esempi sono server route di TanStack Start in
src/routes/api/. Ognuno definisce i propri handler in server.handlers all’interno di createFileRoute. Le versioni precedenti di TanStack Start, come la 1.129, definiscono le server route con createServerFileRoute da @tanstack/react-start/server e una chiamata .methods(). Gli handler di Dodo Payments funzionano allo stesso modo con entrambe le API: passa loro il request.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Usa questo handler per aggiungere il checkout di Dodo Payments alla tua app. L’handler
GET gestisce il checkout statico. L’handler POST gestisce le checkout session o il checkout dinamico quando imposti type: "dynamic". L’esempio di checkout dinamico presuppone che type: "dynamic" sia impostato.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 pagamenti senza codice.
- Dynamic Payment Links: payment link che generi con dettagli personalizzati. Usano endpoint deprecati.
- Checkout Sessions: checkout ospitato con carrello prodotti, dati del cliente e opzioni di personalizzazione. Questo è il flusso consigliato.
Checkout accetta queste opzioni:
L’handler gestisce il checkout statico per le richieste
GET. Per le richieste POST, crea un payment link dinamico quando type è dynamic e, negli altri casi, una checkout session.
Static Checkout (GET)
Static Checkout (GET)
Query Parameter supportati
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.Qualsiasi query parameter che inizia con
metadata_ viene passato al checkout come metadata, ad esempio metadata_orderId=123.email con disableEmail=true. L’handler aggiunge returnUrl dalla propria configurazione al link come redirect_url.Formato della risposta
Il checkout statico restituisce una risposta JSON con l’URL di checkout. In test mode, l’URL usatest.checkout.dodopayments.com:Dynamic Checkout (POST)
Dynamic Checkout (POST)
- Invia i parametri come JSON body in una richiesta POST.
- Supporta sia pagamenti una tantum sia ricorrenti. L’handler recupera il prodotto, quindi crea un abbonamento se il prodotto è ricorrente e un pagamento una tantum negli altri casi.
- Il body richiede
billing(constreet,city,state,countryezipcode) ecustomer, oltre aproduct_idoproduct_cart. Gli abbonamenti richiedonoproduct_id. - Per tutti i body field supportati, 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)
Le checkout session 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, l’handler 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 session creata con payment_method_id non restituisce checkout_url, quindi l’handler risponde con 400.Per ulteriori dettagli e per tutti i field supportati, consulta la Checkout Sessions Integration Guide.Formato della risposta
Le checkout session restituiscono una risposta JSON con l’URL di checkout:Customer Portal Route Handler
Il Customer Portal route handler crea una session Customer Portal per il cliente specificato e reindirizza il browser a tale session.CustomerPortal accetta le stesse opzioni bearerToken e environment di Checkout.
Query Parameter
L’handler restituisce 400 secustomer_id è assente e 500 se non è possibile creare la session del portale.
Webhook Route Handler
Il webhook route handler verifica ogni richiesta con il webhook secret, passato comewebhookKey, prima di eseguire il tuo codice:
- Method: Sono supportate solo le richieste POST. Gli altri method restituiscono 405.
- Signature Verification: Verifica gli header
webhook-id,webhook-timestampewebhook-signatureconwebhookKey, seguendo la specifica Standard Webhooks. Restituisce 401 se la verifica non riesce. - Payload Validation: Valida il payload con Zod. Restituisce 400 per un payload non valido.
- Error Handling:
- 401: Signature non valida
- 400: Payload non valido
- 500: Errore interno durante la verifica
- Event Routing: Chiama
onPayloadper ogni evento, quindi l’handler per il tipo dell’evento e restituisce 200.