Skip to main content

Prerequisiti

Prima di iniziare, ti occorrono:
  • Un account merchant Dodo Payments
  • Una chiave API disponibile in Developer → API Keys nella dashboard, salvata in DODO_PAYMENTS_API_KEY
  • Un webhook secret disponibile in Developer → Webhooks, salvato in DODO_PAYMENTS_WEBHOOK_KEY
  • Almeno un prodotto in abbonamento creato in Products
Per ulteriori dettagli, consulta Prerequisiti della guida all’integrazione.

Integrazione API

Sessioni di checkout

Crea un abbonamento creando una sessione di checkout con il tuo prodotto in abbonamento. Il cliente autorizza un metodo di pagamento e l’abbonamento si attiva al completamento del checkout.
Puoi combinare un prodotto in abbonamento con prodotti una tantum nella stessa sessione di checkout. Questo consente di gestire costi di configurazione, bundle hardware con SaaS e casi d’uso simili. Consulta Checkout Sessions per alcuni esempi.Puoi anche vendere due o più prodotti in abbonamento in un unico checkout. Il cliente paga una volta e ottiene un abbonamento indipendente per ogni prodotto, ciascuno con il proprio ciclo di fatturazione. Un carrello di questo tipo non può contenere prodotti una tantum. Consulta Multi-Subscription Cart.

Risposta API

La risposta include un checkout_url:
Reindirizza il cliente a questo URL. Il cliente autorizza il metodo di pagamento e l’abbonamento si attiva.

Webhook

I webhook notificano al tuo server quando si verificano eventi relativi all’abbonamento. Configura il tuo endpoint nella sezione Developer → Webhooks della dashboard. Per configurare il tuo endpoint webhook, consulta Webhooks.

Tipi di eventi dell’abbonamento

Monitora questi eventi per gestire il ciclo di vita dell’abbonamento:
  1. subscription.active — L’abbonamento è attivato
  2. subscription.updated — Un campo dell’abbonamento è cambiato
  3. subscription.on_hold — Un addebito di rinnovo o di modifica del piano non è riuscito
  4. subscription.failed — La creazione dell’abbonamento non è riuscita (stato terminale; il cliente deve sottoscrivere nuovamente l’abbonamento)
  5. subscription.renewed — Un addebito ricorrente è riuscito
  6. subscription.past_due — Un rinnovo non è riuscito ed è iniziato il periodo di tolleranza; il cliente mantiene l’accesso fino a past_due_ends_at
  7. subscription.plan_changed — Il piano è stato aggiornato, declassato o modificato
  8. subscription.cancelled — L’abbonamento è stato annullato
  9. subscription.expired — L’abbonamento ha raggiunto la fine del proprio periodo
Questi sono gli eventi principali. Per l’elenco completo, inclusi paused, unpaused e update_payment_method, consulta Subscription Webhooks.
Usa subscription.updated per ricevere notifiche in tempo reale su qualsiasi modifica dell’abbonamento e mantenere sincronizzato lo stato della tua applicazione senza eseguire il polling dell’API.

Scenari di pagamento

Flusso di pagamento riuscito La sequenza dei webhook dipende dal fatto che l’abbonamento preveda o meno un periodo di prova. Fatturazione immediata (0 giorni di prova):
  1. subscription.active: il mandato viene autorizzato e l’abbonamento viene attivato.
  2. payment.succeeded: conferma il primo addebito. Dovresti riceverlo entro 2–10 minuti dal checkout.
Con un periodo di prova:
  1. All’inizio della prova (checkout): subscription.active viene inviato quando il metodo di pagamento è autorizzato. Non viene ancora effettuato alcun addebito ricorrente. Il primo addebito effettivo viene posticipato fino alla fine del periodo di prova.
  2. Alla fine della prova: viene addebitato l’importo ricorrente e ricevi payment.succeeded insieme a subscription.renewed.
Ogni rinnovo successivo:
  • subscription.renewed: viene inviato a ogni ciclo di fatturazione quando il pagamento del rinnovo viene detratto, sempre insieme a payment.succeeded. Contiene anche il valore aggiornato di next_billing_date.
Ogni volta che viene effettivamente detratto denaro per un prodotto in abbonamento, ricevi subscription.renewed e payment.succeeded. Usa subscription.renewed, anziché il solo payment.succeeded, come segnale per estendere l’accesso al ciclo successivo.
Scenari di pagamento non riuscito
  1. Errore dell’abbonamento
  • subscription.failed - La creazione dell’abbonamento non è riuscita perché non è stato possibile creare un mandato.
  • payment.failed - Indica un pagamento non riuscito.
  1. Abbonamento sospeso
  • subscription.on_hold - L’abbonamento viene sospeso a causa di un pagamento di rinnovo non riuscito o di un addebito per la modifica del piano non riuscito. Se la tua attività prevede un periodo di tolleranza, un rinnovo non riuscito sposta prima l’abbonamento in past_due (subscription.past_due), quindi lo sposta in on_hold (o cancelled, a seconda delle impostazioni del periodo di tolleranza) solo al termine del periodo di tolleranza. Consulta Subscription States.
  • Quando un abbonamento viene sospeso, non si rinnoverà automaticamente finché il metodo di pagamento non viene aggiornato.
Buona pratica: per semplificare l’implementazione, ti consigliamo di monitorare principalmente gli eventi dell’abbonamento per gestirne il ciclo di vita.
Per una guida completa alla lettura di error_code/error_message, alla decisione su quando riprovare e alla segnalazione degli errori ai clienti, consulta Handle Payment Failures.

subscription.failed vs. subscription.on_hold

Questi due eventi possono essere facilmente confusi, ma richiedono una gestione molto diversa:
subscription.failed è terminale. L’abbonamento non può essere riattivato. Il cliente deve creare un nuovo abbonamento. Non concedere mai i diritti quando viene inviato questo evento.

Gestione degli abbonamenti sospesi

Quando un abbonamento entra nello stato on_hold, devi aggiornare il metodo di pagamento per riattivarlo. Questa sezione spiega quando gli abbonamenti vengono sospesi e come gestirli.

Quando gli abbonamenti vengono sospesi

Un abbonamento viene sospeso quando:
  • Il pagamento del rinnovo non riesce: l’addebito automatico del rinnovo non riesce a causa di fondi insufficienti, carta scaduta o rifiuto della banca
  • L’addebito per la modifica del piano non riesce: un addebito immediato durante l’upgrade o il downgrade del piano non riesce
  • L’autorizzazione del metodo di pagamento non riesce: il metodo di pagamento non può essere autorizzato per addebiti ricorrenti
Gli abbonamenti nello stato on_hold non si rinnoveranno automaticamente. Devi aggiornare il metodo di pagamento per riattivare l’abbonamento.

Riattivazione degli abbonamenti sospesi

Per riattivare un abbonamento nello stato on_hold, usa l’API Update Payment Method. Questa operazione automaticamente:
  1. Crea un addebito per gli importi ancora dovuti
  2. Genera una fattura per l’addebito
  3. Elabora il pagamento usando il nuovo metodo di pagamento
  4. Riattiva l’abbonamento nello stato active dopo il pagamento riuscito
1

Handle subscription.on_hold webhook

Quando ricevi un webhook subscription.on_hold, aggiorna lo stato della tua applicazione e informa il cliente:
2

Update payment method

Quando il cliente è pronto ad aggiornare il metodo di pagamento, chiama l’API Update Payment Method:
Puoi anche usare un ID del metodo di pagamento esistente se il cliente ha salvato dei metodi di pagamento:
3

Monitor webhook events

Dopo aver aggiornato il metodo di pagamento, monitora questi eventi webhook:
  1. payment.succeeded - L’addebito per gli importi ancora dovuti è riuscito
  2. subscription.active - L’abbonamento è stato riattivato

Payload di esempio di un evento dell’abbonamento


Modifica dei piani di abbonamento

Puoi effettuare l’upgrade o il downgrade di un piano di abbonamento usando l’endpoint API per la modifica del piano. Questo ti consente di modificare il prodotto, la quantità e gestire la proroga dell’abbonamento.

Change Plan API Reference

Per informazioni dettagliate sulla modifica dei piani di abbonamento, consulta la documentazione della Change Plan API.

Opzioni di proroga

Quando modifichi i piani di abbonamento, hai quattro opzioni per gestire l’addebito immediato:

1. prorated_immediately

  • Accredita la parte inutilizzata del ciclo di fatturazione corrente, calcolata proporzionalmente in base al tempo rimanente. Il credito copre il piano base, la quantità e tutti gli add-on
  • Quindi addebita un ciclo completo con il nuovo piano, la nuova quantità e i nuovi add-on. L’addebito non viene mai calcolato proporzionalmente
  • Addebito immediato netto = (nuovo ciclo completo) meno (frazione rimanente × vecchio ciclo completo). Se il credito è maggiore, la differenza viene conservata come credito associato all’abbonamento per i rinnovi futuri
  • Durante un periodo di prova, l’utente passa immediatamente al nuovo piano e al cliente viene addebitato subito l’importo

2. full_immediately

  • Addebita al cliente l’intero importo dell’abbonamento per il nuovo piano, senza alcun credito per il ciclo precedente
  • Sia in caso di upgrade che di downgrade, il cliente paga da zero l’intero prezzo del nuovo piano
  • Utile quando vuoi addebitare l’intero importo indipendentemente dal tempo rimasto sul vecchio piano

3. difference_immediately

  • Il cliente paga solo la differenza tra il prezzo del vecchio piano e quello del nuovo piano
  • L’importo non dipende dal momento del ciclo in cui viene effettuata la modifica. Lo stesso upgrade costa uguale il giorno 1 e il giorno 29
  • In caso di upgrade, al cliente viene addebitata immediatamente la differenza. Ad esempio, $30/mese → $80/mese = $50 addebitati immediatamente
  • In caso di downgrade, la differenza di prezzo viene conservata come credito associato all’abbonamento e applicata automaticamente ai rinnovi futuri. Ad esempio, $50/mese → $20/mese = $30 conservati come credito

4. do_not_bill

  • Applica immediatamente la modifica del piano, ma non addebita alcun importo al momento della modifica. Il nuovo piano, la nuova quantità e i nuovi add-on sono utilizzabili immediatamente
  • Poiché non viene addebitato nulla subito, un upgrade offre al cliente il piano superiore gratuitamente per il resto del ciclo corrente. Un downgrade ha effetto immediato senza alcun credito per la parte inutilizzata del ciclo già pagato
  • Gli add-on concessi tramite do_not_bill non vengono accreditati in una modifica successiva del piano, perché non sono mai stati fatturati. Una modifica successiva addebita per intero la nuova quantità di add-on
  • Il piano aggiornato (e la quantità/gli add-on) viene fatturato al rinnovo programmato successivo e la data di fatturazione originale viene mantenuta
Tutte e tre le modalità “addebita ora” reimpostano il ciclo di fatturazione. prorated_immediately, difference_immediately e full_immediately spostano next_billing_date dell’abbonamento alla data della modifica. Solo do_not_bill mantiene la data di rinnovo originale, ma non applica alcun addebito immediato.

Comportamento

  • Quando invochi questa API, Dodo Payments avvia immediatamente un addebito in base all’opzione di proroga selezionata
  • Con prorated_immediately, a ogni modifica viene calcolato un credito per la parte inutilizzata del ciclo corrente, sia in caso di upgrade che di downgrade. Se tale credito supera l’addebito per il nuovo ciclo, il residuo viene aggiunto al saldo crediti dell’abbonamento. Questi crediti sono specifici dell’abbonamento e verranno utilizzati solo per compensare i pagamenti ricorrenti futuri dello stesso abbonamento
  • Con difference_immediately, il netto corrisponde sempre all’esatta differenza di prezzo. In caso di downgrade, l’eccedenza viene conservata come credito associato all’abbonamento, come con prorated_immediately
  • L’opzione full_immediately ignora i calcoli dei crediti e addebita l’intero importo del nuovo piano
  • L’opzione do_not_bill applica immediatamente la modifica, ma rimanda la fatturazione alla data del rinnovo successivo, che viene mantenuta
Scelta della modalità di proroga:
  • difference_immediately — il cliente paga la differenza di prezzo. È l’opzione più prevedibile: l’addebito è uguale indipendentemente dal momento del ciclo in cui viene effettuata la modifica.
  • prorated_immediately — al cliente viene accreditato solo il tempo inutilizzato del ciclo corrente. L’addebito varia in base al momento del ciclo in cui viene effettuata la modifica.
  • full_immediately — il cliente paga l’intero importo del nuovo piano. Nessun credito per il ciclo precedente.
  • do_not_bill — nessun addebito immediato. Il nuovo piano viene fatturato al rinnovo successivo. È l’unica modalità che mantiene la data di fatturazione originale.

Elaborazione degli addebiti

  • L’addebito immediato avviato dopo la modifica del piano di solito completa l’elaborazione in meno di 2 minuti
  • Se questo addebito immediato non riesce per qualsiasi motivo, l’abbonamento viene automaticamente sospeso finché il problema non viene risolto

Abbonamenti on-demand

Gli abbonamenti on-demand ti consentono di addebitare i clienti in modo flessibile, non solo secondo una pianificazione fissa. Questa funzionalità è disponibile per tutti gli account.
Per creare un abbonamento on-demand: Per creare un abbonamento on-demand, usa l’endpoint API POST /checkouts e includi il campo subscription_data.on_demand nel corpo della richiesta. Questo ti consente di autorizzare un metodo di pagamento senza un addebito immediato oppure di impostare un prezzo iniziale personalizzato.
POST /subscriptions è deprecato. Continua a funzionare per le integrazioni esistenti, ma le nuove integrazioni devono creare abbonamenti on-demand tramite una Checkout Session (POST /checkouts) con subscription_data.on_demand. Consulta la On-Demand Subscriptions Guide per il flusso attuale.
Per addebitare un abbonamento on-demand: Per gli addebiti successivi, usa l’endpoint POST /subscriptions//charge e specifica l’importo da addebitare al cliente per quella transazione.
Per una guida completa e dettagliata (inclusi esempi di richieste/risposte, criteri di retry sicuri e gestione dei webhook), consulta la On-Demand Subscriptions Guide.

Aspetti fondamentali della fatturazione degli abbonamenti

Imposta il periodo dell’abbonamento su una durata maggiore rispetto alla frequenza dei pagamenti. Se il periodo dell’abbonamento coincide con la frequenza dei pagamenti (ad esempio, periodo = 1 mese, frequenza = 1 mese), l’abbonamento è valido per un singolo ciclo e passa quindi a expired invece di rinnovarsi. Per un piano mensile continuativo, imposta un periodo di abbonamento lungo (ad esempio, 20 anni) con una frequenza di pagamento mensile.
La valuta viene bloccata al primo addebito riuscito. Passa sempre esplicitamente billing_currency e billing_address.country durante la creazione del checkout. Se omessi, vengono rilevati dall’IP del cliente (Adaptive Currency) e, una volta effettuato il primo addebito dell’abbonamento, la valuta viene fissata per tutta la sua durata. Un cliente che viaggia successivamente non può cambiarla.
I periodi di prova eseguono un’autorizzazione di $0, non un addebito. Quando un abbonamento prevede un periodo di prova, all’inizio della prova viene creata un’autorizzazione del mandato di $0 per salvare la carta; il primo addebito effettivo avviene al termine della prova. Nell’elenco dei pagamenti, un abbonamento in periodo di prova gratuito mostra esattamente un pagamento con total_amount pari a 0. Un periodo di prova a pagamento addebita invece anticipatamente il relativo trial_amount.
Ciclo di vita dell’abbonamento: past_due = un rinnovo non è riuscito e il periodo di tolleranza è in corso (il cliente mantiene l’accesso). on_hold = un rinnovo non è riuscito (recuperabile: chiedi al cliente di aggiornare il metodo di pagamento; si applicano i retry di dunning). expired = il periodo è terminato senza rinnovo e non può essere riattivato. Il cliente deve sottoscrivere nuovamente l’abbonamento. cancelled = terminato dal cliente o dal merchant. La maggior parte dei rinnovi non riusciti è dovuta a rifiuti lato issuer (fondi insufficienti, carta rifiutata), non a un errore di Dodo.
Le carte indiane funzionano tramite un e-mandate RBI. Gli addebiti off-session (rinnovi e addebiti per la modifica del piano) possono richiedere fino a circa 48 ore per essere regolati e gli addebiti automatici ricorrenti superiori a ₹15,000 richiedono una nuova autenticazione del cliente (quindi un upgrade che supera tale limite non può utilizzare il mandato esistente). Mentre un addebito è ancora processing, un secondo addebito sullo stesso abbonamento non riesce con “Cannot create new charge as previous payment is not successful yet.” Le carte non indiane vengono confermate quasi istantaneamente.
Gli abbonamenti hanno un minimo di $1,00 in USD. Il checkout rifiuta un totale inferiore con TOTAL_PAYMENT_AMOUNT_BELOW_MINIMUM_AMOUNT. Anche le valute diverse da USD, EUR e GBP devono avere un valore di almeno $1,00; consulta Minimum Amounts. Un addebito on-demand product_price inferiore a 100 nell’unità minima della valuta viene rifiutato con product_price: value out of range. È consentito un prodotto in abbonamento con prezzo esattamente pari a $0; consulta Card-Optional at Zero Price. Per autorizzare una carta senza addebitarla, usa una configurazione on-demand mandate_only.

Riferimenti API correlati

Create Subscription (Deprecated)

API legacy per creare direttamente un abbonamento. Usa Checkout Sessions per le nuove integrazioni

Change Subscription Plan

Riferimento API per effettuare l’upgrade, il downgrade o la modifica dei piani di abbonamento con opzioni di proroga

Update Payment Method

Riferimento API per aggiornare i metodi di pagamento e riattivare gli abbonamenti sospesi

Patch Subscription

Riferimento API per aggiornare i dettagli e la configurazione dell’abbonamento
Ultima modifica il 8 ottobre 2026