Skip to main content

Prerequisites

To integrate the Dodo Payments API, you’ll need:
  • A Dodo Payments merchant account
  • API credentials (API key and webhook secret key) from the dashboard
For a more detailed guide on the prerequisites, check this section.

API Integration

Checkout Sessions

Use Checkout Sessions to sell subscription products with a secure, hosted checkout. Pass your subscription product in product_cart and redirect customers to the returned checkout_url.
Mixed Checkout: You can combine subscription products with one-time products in the same checkout session. This enables use cases like setup fees with subscriptions, hardware bundles with SaaS, and more. See the Checkout Sessions guide for examples.

API Response

The following is an example of the response:
Reindirizza il cliente a checkout_url.

Webhook

Quando integri gli abbonamenti, riceverai webhook per monitorare il ciclo di vita degli abbonamenti. Questi webhook ti aiutano a gestire efficacemente gli stati degli abbonamenti e gli scenari di pagamento. Per configurare il tuo endpoint webhook, segui la nostra Guida dettagliata all’integrazione.

Tipi di eventi di abbonamento

I seguenti eventi webhook monitorano i cambiamenti di stato dell’abbonamento:
  1. subscription.active - L’abbonamento è stato attivato con successo.
  2. subscription.updated - L’oggetto dell’abbonamento è stato aggiornato (si attiva su qualsiasi modifica del campo).
  3. subscription.on_hold - L’abbonamento è messo in attesa a causa di un rinnovo fallito.
  4. subscription.failed - La creazione dell’abbonamento è fallita durante la creazione del mandato.
  5. subscription.renewed - L’abbonamento è rinnovato per il prossimo periodo di fatturazione.
Per una gestione affidabile del ciclo di vita degli abbonamenti, consigliamo di monitorare questi eventi di abbonamento.
Usa subscription.updated per ottenere notifiche in tempo reale su qualsiasi modifica dell’abbonamento, mantenendo lo stato dell’applicazione sincronizzato senza interpellare l’API.

Scenari di pagamento

Flusso di pagamento riuscito I webhook che ricevi e la loro tempistica dipendono dal fatto che il prodotto includa o meno un periodo di prova. Fatturazione immediata (0 giorni di prova):
  1. subscription.active: il mandato viene autorizzato e la sottoscrizione viene attivata.
  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 emesso quando il metodo di pagamento è autorizzato. Non viene ancora effettuato alcun addebito ricorrente. Il primo addebito effettivo viene posticipato fino al termine della prova.
  2. Al termine della prova: viene addebitato l’importo ricorrente e ricevi payment.succeeded insieme a subscription.renewed.
Ogni rinnovo successivo:
  • subscription.renewed: viene emesso 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 sottoscrizione, 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 della sottoscrizione
  • subscription.failed - La creazione della sottoscrizione non è riuscita perché non è stato possibile creare un mandato.
  • payment.failed - Indica un pagamento non riuscito.
  1. Sottoscrizione sospesa
  • subscription.on_hold - La sottoscrizione viene sospesa a causa di un pagamento di rinnovo non riuscito o di un addebito per la modifica del piano non riuscito.
  • Quando una sottoscrizione viene sospesa, 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 della sottoscrizione per gestirne il ciclo di vita.
Per una guida completa alla lettura di error_code/error_message, alla scelta del momento in cui ritentare e alla comunicazione degli errori ai clienti, consulta Gestione dei pagamenti non riusciti.

subscription.failed vs. subscription.on_hold

È facile confondere questi due eventi, ma richiedono una gestione molto diversa:
subscription.failed è terminale. La sottoscrizione non può essere riattivata. Il cliente deve creare una nuova sottoscrizione. Non concedere mai entitlement quando viene emesso questo evento.

Gestione delle sottoscrizioni sospese

Quando una sottoscrizione entra nello stato on_hold, devi aggiornare il metodo di pagamento per riattivarla. Questa sezione spiega quando le sottoscrizioni vengono sospese e come gestirle.

Quando le sottoscrizioni vengono sospese

Una sottoscrizione viene sospesa quando:
  • Il pagamento del rinnovo non riesce: l’addebito automatico del rinnovo non riesce a causa di fondi insufficienti, carta scaduta o rifiuto da parte 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: non è possibile autorizzare il metodo di pagamento per gli addebiti ricorrenti
Le sottoscrizioni nello stato on_hold non si rinnoveranno automaticamente. Devi aggiornare il metodo di pagamento per riattivare la sottoscrizione.

Riattivazione delle sottoscrizioni sospese

Per riattivare una sottoscrizione 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 utilizzando il nuovo metodo di pagamento
  4. Riattiva la sottoscrizione nello stato active dopo il pagamento effettuato correttamente
1

Handle subscription.on_hold webhook

Quando ricevi un webhook subscription.on_hold, aggiorna lo stato dell’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 l’ID di un 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 - La sottoscrizione è stata riattivata

Esempio di payload di un evento Subscription


Modifica dei piani di sottoscrizione

Puoi effettuare l’upgrade o il downgrade di un piano di sottoscrizione utilizzando l’endpoint API change plan. Questo consente di modificare il prodotto, la quantità e di gestire la proroga della sottoscrizione.

Change Plan API Reference

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

Opzioni di proroga

Quando modifichi i piani di sottoscrizione, hai due opzioni per gestire l’addebito immediato:

1. prorated_immediately

  • Calcola l’importo pro rata in base al tempo rimanente nel ciclo di fatturazione corrente
  • Addebita al cliente solo la differenza tra il piano precedente e quello nuovo
  • Durante un periodo di prova, passa immediatamente l’utente al nuovo piano, addebitando subito il cliente

2. full_immediately

  • Addebita al cliente l’intero importo della sottoscrizione per il nuovo piano
  • Ignora il tempo rimanente o i crediti del piano precedente
  • È utile quando vuoi reimpostare il ciclo di fatturazione o addebitare l’intero importo indipendentemente dalla proroga

3. difference_immediately

  • In caso di upgrade, al cliente viene immediatamente addebitata la differenza tra gli importi dei due piani.
  • Ad esempio, se il piano corrente costa 30 Dollari e il cliente passa a un piano da 80 Dollari, gli vengono addebitati istantaneamente $50.
  • In caso di downgrade, l’importo inutilizzato del piano corrente viene aggiunto come credito interno e applicato automaticamente ai rinnovi futuri della sottoscrizione.
  • Ad esempio, se il piano corrente costa 50 Dollari e il cliente passa a un piano da 20 Dollari, i $30 rimanenti vengono accreditati e utilizzati per il ciclo di fatturazione successivo.

4. do_not_bill

  • Applica immediatamente la modifica del piano, ma non effettua alcun addebito al momento della modifica.
  • Il piano aggiornato (e la quantità/gli extra) viene fatturato al rinnovo programmato successivo 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 della sottoscrizione 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 proroga selezionata
  • Se la modifica del piano è un downgrade e utilizzi prorated_immediately, i crediti vengono calcolati automaticamente e aggiunti al saldo crediti della sottoscrizione. Questi crediti sono specifici di quella sottoscrizione e verranno utilizzati solo per compensare i futuri pagamenti ricorrenti della stessa sottoscrizione
  • L’opzione full_immediately ignora i calcoli dei crediti e addebita l’intero importo del nuovo piano
Scegli attentamente l’opzione di proroga: usa prorated_immediately per una fatturazione equa che tenga conto del tempo inutilizzato, oppure full_immediately quando vuoi addebitare l’intero importo del nuovo piano indipendentemente dal ciclo di fatturazione corrente.

Elaborazione degli addebiti

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

Sottoscrizioni on-demand

Le sottoscrizioni 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 una sottoscrizione on-demand: Per creare una sottoscrizione on-demand, usa l’endpoint API POST /subscriptions e includi il campo on_demand nel corpo della richiesta. Questo consente di autorizzare un metodo di pagamento senza un addebito immediato oppure di impostare un prezzo iniziale personalizzato. Per addebitare una sottoscrizione 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 Guida alle sottoscrizioni on-demand.

Aspetti fondamentali della fatturazione delle sottoscrizioni

Imposta un periodo di sottoscrizione più lungo della frequenza di pagamento. Se il periodo di sottoscrizione è uguale alla frequenza di pagamento (ad esempio, periodo = 1 mese, frequenza = 1 mese), la sottoscrizione è valida per un singolo ciclo e passa quindi a expired invece di rinnovarsi. Per un piano mensile continuativo, imposta un periodo di sottoscrizione lungo (ad esempio, 20 anni) con una frequenza di pagamento mensile.
La valuta viene bloccata al primo addebito riuscito. Passa sempre billing_currency e billing_address.country in modo esplicito durante la creazione del checkout. Se omessi, vengono rilevati dall’IP del cliente (Adaptive Currency) e, una volta effettuato il primo addebito della sottoscrizione, la valuta viene fissata per tutta la sua durata. Se in seguito il cliente viaggia, non può cambiarla.
I periodi di prova effettuano un’autorizzazione di $0, non un addebito. Quando una sottoscrizione 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, una sottoscrizione in prova mostra esattamente un pagamento con amount: 0.
Ciclo di vita della sottoscrizione: 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 effettuare nuovamente la sottoscrizione. cancelled = terminata 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 upgrade che superi tale limite non può utilizzare il mandato esistente). Mentre un addebito è ancora processing, un secondo addebito sulla stessa sottoscrizione non riesce con “Cannot create new charge as previous payment is not successful yet.” Le carte non indiane vengono confermate quasi istantaneamente.
Gli addebiti delle sottoscrizioni hanno un minimo di $1 (o l’equivalente nella valuta locale). Gli importi di $0.01–$0.99 vengono rifiutati con product_price: value out of range; è consentito solo $0, tramite una configurazione on-demand mandate_only.

Riferimenti API correlati

Create Subscription

Riferimento API per la creazione dei prodotti in sottoscrizione e la gestione del ciclo di vita delle sottoscrizioni

Change Subscription Plan

Riferimento API per effettuare l’upgrade, il downgrade o modificare i piani di sottoscrizione con opzioni di proroga

Update Payment Method

Riferimento API per l’aggiornamento dei metodi di pagamento e la riattivazione delle sottoscrizioni sospese

Patch Subscription

Riferimento API per l’aggiornamento dei dettagli e della configurazione delle sottoscrizioni
Ultima modifica il 31 luglio 2026