@dodopayments/sveltekit fornisce alla tua app SvelteKit tre gestori di route. Checkout restituisce gli URL di checkout, CustomerPortal invia un cliente al Customer Portal e Webhooks verifica gli eventi webhook e li inoltra al tuo codice.
Checkout Handler
Crea URL di checkout dalla tua app SvelteKit.
Customer Portal
Consenti ai clienti di gestire abbonamenti e dati personali.
Webhooks
Ricevi e verifica gli eventi webhook di Dodo Payments.
Installazione
1
Install the Package
Esegui questo comando nella directory principale del progetto:Il pacchetto elenca SvelteKit 2 (
@sveltejs/kit 2.20.3 o versione successiva) e zod 3.25 o versione successiva come peer dependencies.2
Set Up Environment Variables
Crea un file Crea la API key in Developer → API Keys. Aggiungi il tuo endpoint webhook in Developer → Webhooks e copia il relativo signing secret in
.env nella directory principale del progetto:DODO_PAYMENTS_WEBHOOK_KEY. DODO_PAYMENTS_RETURN_URL è la pagina in cui arrivano i clienti dopo il checkout. Se non passi un ambiente, i gestori utilizzano live_mode.Esempi di gestori di route
Gli esempi sono endpoint
+server.ts di SvelteKit in src/routes/api/. Importano le tue credenziali da $env/static/private, che SvelteKit mantiene al di fuori del codice lato client.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
Usa questo gestore per aggiungere il checkout di Dodo Payments alla tua app SvelteKit.
Checkout restituisce un gestore GET per il checkout statico e un gestore POST per le checkout session o per il checkout dinamico quando imposti type: "dynamic". Esporta GET da un gestore creato con type: "static" o senza type, perché il gestore GET di un gestore session o dynamic restituisce 400.POST proviene da un gestore creato con type: "dynamic". Con type: "session", come nell’esempio della route, invia la richiesta della checkout session.Gestore della route di 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. Utilizzano endpoint deprecati.
- Checkout session: checkout ospitato con carrello prodotti, dati del cliente e opzioni di personalizzazione. È il flusso consigliato.
Checkout accetta queste opzioni:
Static Checkout (GET)
Static Checkout (GET)
Parametri di query supportati
string
obbligatorio
Identificatore del prodotto, ad esempio
?productId=pdt_nZuwz45WAs64n3l07zpQR.integer
predefinito:"1"
Quantità del prodotto.
string
Nome completo del cliente. Ignorato se vengono forniti
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 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
Imposta l’importo addebitato, in unità maggiori 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 come metadata.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 modalità test, l’URL utilizzatest.checkout.dodopayments.com.Dynamic Checkout (POST)
Dynamic Checkout (POST)
- Invia i parametri come body JSON in una richiesta POST.
- Supporta sia i pagamenti una tantum sia quelli ricorrenti.
billingecustomersono obbligatori.- Per tutti i campi body supportati, consulta:
Formato della risposta
Il checkout dinamico restituisce una risposta JSON con l’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. Se il body non contiene return_url, il gestore utilizza 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 session restituiscono una risposta JSON con l’URL di checkout:Gestore della route Customer Portal
Il gestore della route Customer Portal crea una sessione Customer Portal per il cliente specificato e reindirizza il browser a tale sessione con una risposta 302.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 via email il link del portale al cliente.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 e gli header
webhook-id,webhook-timestampewebhook-signatureconwebhookKey, seguendo la specifica Standard Webhooks. Restituisce 401 se la verifica non riesce. - Convalida del payload: convalida 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: chiama
onPayloadper ogni evento, quindi il gestore relativo al tipo di evento, e restituisce 200.