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 prodotti in abbonamento e 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 Sessioni di checkout per alcuni esempi.

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 agli abbonamenti. Configura il tuo endpoint in Developer → Webhooks nella dashboard. Per configurare il tuo endpoint webhook, consulta Webhook.

Tipi di eventi degli abbonamenti

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 (terminale; il cliente deve sottoscrivere nuovamente l’abbonamento)
  5. subscription.renewed — Un addebito ricorrente è riuscito
  6. subscription.past_due — Un rinnovo non è riuscito e il periodo di tolleranza è iniziato; il cliente mantiene l’accesso fino a past_due_ends_at
  7. subscription.plan_changed — Il piano è stato migliorato, ridotto 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 Webhook degli abbonamenti.
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 includa 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. Attendi questo evento entro 2–10 minuti dal checkout.
Con un periodo di prova:
  1. All’inizio della prova (checkout): subscription.active viene generato quando il metodo di pagamento è autorizzato. Non viene ancora effettuato alcun addebito ricorrente. Il primo addebito effettivo viene posticipato fino alla fine della 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 generato 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 del 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 di modifica del piano non riuscito. Se la tua attività dispone di un periodo di tolleranza, un rinnovo non riuscito sposta inizialmente 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. Consulta Stati degli abbonamenti.
  • Quando un abbonamento viene sospeso, non si rinnoverà automaticamente finché il metodo di pagamento non verrà aggiornato.
Best practice: per semplificare l’implementazione, ti consigliamo di monitorare principalmente gli eventi degli abbonamenti per gestirne il ciclo di vita.
Per una guida completa alla lettura di error_code/error_message, alla decisione su quando riprovare e alla presentazione degli errori ai clienti, consulta Gestire i pagamenti non riusciti.

subscription.failed vs. subscription.on_hold

È facile confondere questi due eventi, 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 generato questo evento.

Gestire un abbonamento sospeso

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 il miglioramento o la riduzione del piano non riesce
  • L’autorizzazione del metodo di pagamento non riesce: non è possibile autorizzare il metodo di pagamento per gli addebiti ricorrenti
Gli abbonamenti nello stato on_hold non si rinnoveranno automaticamente. Devi aggiornare il metodo di pagamento per riattivare l’abbonamento.

Riattivare gli abbonamenti sospesi

Per riattivare un abbonamento dallo stato on_hold, usa l’API Update Payment Method. In questo modo vengono automaticamente:
  1. Creato un addebito per gli importi ancora dovuti
  2. Generata una fattura per l’addebito
  3. Elaborato il pagamento usando il nuovo metodo di pagamento
  4. Riattivato l’abbonamento allo 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 avvisa 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 di 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 degli importi ancora dovuti è riuscito
  2. subscription.active - L’abbonamento è stato riattivato

Payload di esempio di un evento dell’abbonamento


Modificare i piani degli abbonamenti

Puoi migliorare o ridurre il piano di un abbonamento usando l’endpoint API per la modifica del piano. Questo consente di modificare il prodotto, la quantità e di gestire il prorating dell’abbonamento.

Change Plan API Reference

Per informazioni dettagliate sulla modifica dei piani degli abbonamenti, consulta la documentazione della nostra API Change Plan.

Opzioni di prorating

Quando modifichi i piani degli abbonamenti, 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 gli eventuali componenti aggiuntivi
  • Quindi addebita un ciclo completo con il nuovo piano, la nuova quantità e i nuovi componenti aggiuntivi. 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 il cliente viene addebitato subito

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 miglioramento sia di riduzione, il cliente paga da zero l’intero prezzo del nuovo piano
  • Utile quando vuoi addebitare l’intero importo indipendentemente dal tempo rimasto nel 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 miglioramento costa uguale al giorno 1 e al giorno 29
  • Quando si effettua un miglioramento, al cliente viene addebitata immediatamente la differenza. Ad esempio, $30/mese → $80/mese = $50 addebitati subito
  • Quando si effettua una riduzione, 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 quantità e i componenti aggiuntivi sono utilizzabili subito
  • Poiché non viene addebitato nulla subito, un miglioramento offre al cliente il piano superiore gratuitamente per il resto del ciclo corrente. Una riduzione entra in vigore immediatamente senza credito per la parte inutilizzata del ciclo già pagata
  • I componenti aggiuntivi concessi tramite do_not_bill non vengono accreditati in una modifica successiva del piano, perché non sono mai stati fatturati. Una modifica successiva fattura interamente la nuova quantità dei componenti aggiuntivi
  • Il piano aggiornato (e la quantità/i componenti aggiuntivi) viene fatturato al prossimo rinnovo programmato e la data di fatturazione originale viene mantenuta
Tutte e tre le modalità di “addebito immediato” 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 richiami questa API, Dodo Payments avvia immediatamente un addebito in base all’opzione di prorating selezionata
  • Con prorated_immediately, a ogni modifica, sia miglioramento sia riduzione, viene calcolato un credito per la parte inutilizzata del ciclo corrente. Se il credito supera l’addebito del nuovo ciclo, il residuo viene aggiunto al saldo dei crediti dell’abbonamento. Questi crediti sono specifici dell’abbonamento e verranno utilizzati solo per compensare i futuri pagamenti ricorrenti dello stesso abbonamento
  • Con difference_immediately, il netto corrisponde sempre esattamente alla differenza di prezzo. Per le riduzioni, 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
Scegliere una modalità di prorating:
  • 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 — il cliente riceve un credito solo per il tempo inutilizzato del ciclo corrente. L’addebito varia in base al momento del ciclo in cui avviene 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 dell’addebito

  • L’elaborazione dell’addebito immediato avviato dopo la modifica del piano generalmente si completa 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 consente di autorizzare un metodo di pagamento senza un addebito immediato o 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 Sessione di checkout (POST /checkouts) con subscription_data.on_demand. Consulta la Guida agli abbonamenti on-demand 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 la transazione.
Per una guida completa e dettagliata (inclusi esempi di richieste/risposte, criteri di retry sicuri e gestione dei webhook), consulta la Guida agli abbonamenti on-demand.

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 è uguale alla frequenza dei pagamenti (ad esempio periodo = 1 mese, frequenza = 1 mese), l’abbonamento è valido per un solo ciclo e passa quindi a expired invece di rinnovarsi. Per un piano mensile continuativo, imposta un periodo dell’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 quando crei il 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. Se in seguito il cliente viaggia, non può cambiarla.
I periodi di prova eseguono un’autorizzazione di $0, non un addebito. Quando un abbonamento include 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 prova gratuita mostra esattamente un pagamento con total_amount pari a 0. Una 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 da parte dell’emittente (fondi insufficienti, carta rifiutata), non a un errore di Dodo.
Le carte indiane utilizzano 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 (pertanto un miglioramento 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 addebiti degli abbonamenti hanno un minimo di $1 (o l’equivalente nella valuta). Gli importi pari a $0.01–$0.99 vengono rifiutati con product_price: value out of range. È consentito un prodotto in abbonamento con prezzo esattamente pari a $0; consulta Carta facoltativa al prezzo zero. 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 le sessioni di checkout per le nuove integrazioni

Change Subscription Plan

Riferimento API per migliorare, ridurre o modificare i piani degli abbonamenti con opzioni di prorating

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 degli abbonamenti
Ultima modifica il 26 settembre 2026