Vai al contenuto principale

Documentation Index

Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt

Use this file to discover all available pages before exploring further.

Panoramica

Le sottoscrizioni on-demand ti consentono di autorizzare un metodo di pagamento di un cliente una sola volta e poi addebitare importi variabili ogni volta che ne hai bisogno, invece di seguire un programma fisso. Questa funzionalità è disponibile per tutti gli account—non è necessaria alcuna approvazione. Usa questa guida per:
  • Creare una sottoscrizione on-demand (autorizzare un mandato con un prezzo iniziale opzionale)
  • Attivare addebiti successivi con importi personalizzati
  • Monitorare i risultati utilizzando i webhook
Per una configurazione generale della sottoscrizione, consulta la Guida all’integrazione delle sottoscrizioni.

Requisiti

  • Account commerciante Dodo Payments e chiave API
  • Segreto del webhook configurato e un endpoint per ricevere eventi
  • Un prodotto in abbonamento nel tuo catalogo
Se vuoi che il cliente approvi il mandato tramite il checkout ospitato, imposta payment_link: true e fornisci un return_url.

Come funziona l’on-demand

  1. Crei un abbonamento con l’oggetto on_demand per autorizzare un metodo di pagamento e, facoltativamente, addebitare una somma iniziale.
  2. Successivamente, crei addebiti contro tale abbonamento con importi personalizzati usando l’endpoint dedicato agli addebiti.
  3. Ascolti i webhook (es. payment.succeeded, payment.failed) per aggiornare il tuo sistema.

Crea una sottoscrizione on-demand

Endpoint: POST /checkouts Campi chiave della richiesta (corpo):
Trovali in Crea sessione di checkout

Crea una sottoscrizione on-demand

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // defaults to 'live_mode'
});

async function main() {
  const subscription = await client.checkoutSessions.create({
    product_cart: [{ product_id: 'pdt_123', quantity: 1 }],
    billing_address:  { city: 'SF', country: 'US', state: 'CA', street: '1 Market St', zipcode: '94105' },
    customer: { customer_id: 'cus_123' },
    return_url: 'https://example.com/billing/success',
    subscription_data: {
        on_demand: {
            mandate_only: true // set false to collect an initial charge
            // product_price: 1000, // optional: charge $10.00 now if mandate_only is false
            // product_currency: 'USD',
            // product_description: 'Custom initial charge',
            // adaptive_currency_fees_inclusive: false,
        }
    }
  });

  console.log(subscription.checkout_url);
}

main().catch(console.error);
Success
{
  "session_id": "cks_123",
  "checkout_url": "https://test.checkout.dodopayments.com/session/cks123"
}

Addebita una sottoscrizione on-demand

Dopo che il mandato è stato autorizzato, crea addebiti secondo necessità. Endpoint: POST /subscriptions/{subscription_id}/charge Campi chiave della richiesta (corpo):
product_price
integer
obbligatorio
Importo da addebitare (nell’unità monetaria più piccola). Esempio: per addebitare $25,00, passa 2500.
product_currency
string
Sovrascrittura facoltativa della valuta per l’addebito.
product_description
string
Sovrascrittura facoltativa della descrizione per questo addebito.
adaptive_currency_fees_inclusive
boolean
Se true, include le commissioni in valuta adattiva all’interno di product_price. Se false, le commissioni vengono aggiunte sopra.
metadata
object
Metadata aggiuntivi per il pagamento. Se omessi, vengono usati i metadata dell’abbonamento.
import DodoPayments from 'dodopayments';

const client = new DodoPayments({ bearerToken: process.env.DODO_PAYMENTS_API_KEY });

async function chargeNow(subscriptionId) {
  const res = await client.subscriptions.charge(subscriptionId, { product_price: 2500 });
  console.log(res.payment_id);
}

chargeNow('sub_123').catch(console.error);
Success
{ "payment_id": "pay_abc123" }
Addebitare un abbonamento che non è on-demand potrebbe fallire. Assicurati che l’abbonamento abbia on_demand: true nei suoi dettagli prima dell’addebito.

Gestione delle transazioni fallite

Quando un addebito per un abbonamento su richiesta fallisce, decidi tu cosa succede dopo. A differenza degli abbonamenti programmati — dove un rinnovo fallito interrompe ulteriori addebiti automatici — gli abbonamenti su richiesta rimangono addebitabili dopo un fallimento. Puoi richiamare l’endpoint di addebito come parte della tua logica di ripetizione.

Cosa succede in caso di fallimento

1

Charge attempt fails

La richiesta POST /subscriptions/{subscription_id}/charge restituisce una risposta di errore oppure si completa in modo asincrono ed emette un webhook payment.failed con il motivo del rifiuto.
2

Subscription may transition to on_hold

L’abbonamento può passare allo stato on_hold ed emettere un webhook subscription.on_hold (vedi Statuti degli abbonamenti → In sospeso). Questo è un segnale — non un blocco. Per gli abbonamenti su richiesta, on_hold non impedisce di effettuare nuovamente l’addebito.
3

Retry the charge (your call)

Per i flussi su richiesta, Dodo non riprova automaticamente. Puoi richiamare POST /subscriptions/{subscription_id}/charge in qualsiasi momento per riprovare. Applica la politica di ripetizione sicura qui sotto — utilizza esponenziale backoff, salta i rifiuti rigidi e evita schemi di burst — in modo che le ripetizioni non vengano segnalate dai nostri sistemi di frode e rischio.
4

Optionally, ask the customer for a new payment method

Se le ripetizioni continuano a fallire perché il metodo di pagamento stesso è danneggiato (carta scaduta, conto chiuso, ecc.), usa POST /subscriptions/{id}/payment-method per raccoglierne uno nuovo dal cliente. In caso di successo, l’abbonamento torna a active e payment.succeeded seguito da webhook subscription.active sono emessi.
Su richiesta vs programmato: Per gli abbonamenti programmati, Dodo esegue i propri rinnovi e dunning. Per gli abbonamenti su richiesta, tu possiedi la politica di ripetizione perché solo tu sai quando dovrebbe avvenire il prossimo addebito (è guidato dai tuoi eventi di utilizzo, non da un calendario).

Sequenza di webhook su un addebito su richiesta fallito

OrdineEventoSignificato
1payment.failedIl tentativo di addebito su richiesta non è riuscito (include il motivo del rifiuto)
2subscription.on_holdL’abbonamento è stato sospeso (informativo; non blocca ulteriori addebiti)
3*payment.succeededUn addebito successivo — sia la tua ripetizione che dopo un aggiornamento del metodo di pagamento — è riuscito
4*subscription.activeL’abbonamento è tornato a active dopo un addebito riuscito
Gli eventi 3 e 4 si verificano solo dopo che un addebito di follow-up ha successo.

Responsabilità della ripetizione

Dodo Payments non ripete automaticamente gli addebiti su richiesta falliti. Tu possiedi la politica di ripetizione. Segui le linee guida di ripetizione sicura qui sotto per evitare di essere segnalato dai nostri sistemi di rilevamento delle frodi come test di carte.
Gestione delle insolvenze degli abbonamenti — la sequenza di recupero tramite email incorporata — è limitata ai pagamenti di rinnovo falliti su abbonamenti programmati e cancellazioni avviate dal cliente. Non è progettata per fallimenti di addebiti su richiesta. Comunica direttamente con il cliente (ad esempio, email transazionale o prompt in-app) quando decidi che il metodo di pagamento deve essere aggiornato.

Ripetizione dei pagamenti

Il nostro sistema di rilevamento delle frodi può bloccare schemi di ripetizione aggressivi (e può segnalarli come potenziale test di carte). Segui una politica di ripetizione sicura.
Gli schemi di ripetizione a raffica possono essere segnalati come fraudolenti o sospetti test di carte dai nostri sistemi di rischio e dai processori. Evita ripetizioni raggruppate; segui il programma di backoff e le linee guida di allineamento temporale di seguito.

Principi per politiche di ripetizione sicure

  • Meccanismo di backoff: Usa un backoff esponenziale tra le ripetizioni.
  • Limiti di ripetizione: Limita le ripetizioni totali (max 3–4 tentativi).
  • Filtraggio intelligente: Ripeti solo su fallimenti ripetibili (ad esempio, errori di rete/emittente, fondi insufficienti); non riprovare mai per rifiuti rigidi.
  • Prevenzione del test di carte: Non riprovare fallimenti come DO_NOT_HONOR, STOLEN_CARD, LOST_CARD, PICKUP_CARD, FRAUDULENT, AUTHENTICATION_FAILURE.
  • Varietà di metadata (opzionale): Se mantieni il tuo sistema di ripetizione, differenzia le ripetizioni tramite metadata (ad esempio, retry_attempt).

Programma di ripetizione suggerito (abbonamenti)

  • 1º tentativo: Immediato quando crei l’addebito
  • 2º tentativo: Dopo 3 giorni
  • 3º tentativo: Dopo altri 7 giorni (10 giorni totali)
  • 4º tentativo (finale): Dopo altri 7 giorni (17 giorni totali)
Passo finale: se ancora non pagato, segna l’abbonamento come non pagato o annullalo, in base alla tua politica. Notifica il cliente durante la finestra per aggiornare il metodo di pagamento.

Evitare ripetizioni a raffica; allinea al tempo di autorizzazione

  • Ancora le ripetizioni al timestamp di autorizzazione originale per evitare comportamenti a “raffica” su tutto il portafoglio.
  • Esempio: Se il cliente avvia una prova o un mandato alle 13:10 di oggi, programma le ripetizioni successive alle 13:10 nei giorni successivi secondo il tuo backoff (ad esempio, +3 giorni → 13:10, +7 giorni → 13:10).
  • In alternativa, se memorizzi l’ora dell’ultimo pagamento riuscito T, programma il tentativo successivo a T + X days per preservare l’allineamento dell’orario.
Fuso orario e DST: usa un standard di tempo coerente per la pianificazione e converti per la visualizzazione solo per mantenere gli intervalli.

Codici di declino che non dovresti riprovare

  • STOLEN_CARD
  • DO_NOT_HONOR
  • FRAUDULENT
  • PICKUP_CARD
  • AUTHENTICATION_FAILURE
  • LOST_CARD
Per un elenco completo delle motivazioni di declino e se sono correggibili dall’utente, vedi la documentazione su Fallimenti delle transazioni.
Ripeti solo su problemi soft/temporanei (ad esempio, insufficient_funds, issuer_unavailable, processing_error, timeout di rete). Se lo stesso declino si ripete, sospendi ulteriori ripetizioni.

Linee guida per l’implementazione (senza codice)

  • Utilizza un gestore di code che mantiene timestamp precisi; calcola il tentativo successivo all’esatto offset orario (ad esempio, T + 3 days alla stessa HH:MM).
  • Mantieni e riferisci il timestamp dell’ultimo pagamento riuscito T per calcolare il tentativo successivo; non raggruppare più abbonamenti allo stesso istante.
  • Valuta sempre il motivo dell’ultimo declino; interrompi le ripetizioni per declini rigidi nella lista di skip sopra.
  • Limita le ripetizioni concorrenti per cliente e per account per prevenire picchi accidentali.
  • Comunica proattivamente: invia email/SMS al cliente per aggiornare il metodo di pagamento prima del prossimo tentativo programmato.
  • Usa metadata solo per osservabilità (ad esempio, retry_attempt); non cercare mai di “evadere” i sistemi di frode/rischio ruotando campi irrilevanti.

Tracciare i risultati con i webhook

Implementa la gestione webhook per tracciare il percorso del cliente. Vedi Implementazione Webhook.
  • subscription.active: Mandato autorizzato e abbonamento attivato
  • subscription.failed: Creazione fallita (ad esempio, fallimento del mandato)
  • subscription.on_hold: Abbonamento sospeso (ad esempio, stato non pagato)
  • payment.succeeded: Addebito riuscito
  • payment.failed: Addebito fallito
Per i flussi su richiesta, concentrati su payment.succeeded e payment.failed per riconciliare gli addebiti basati sull’uso. Quando payment.failed è seguito da subscription.on_hold, vedi Gestione delle transazioni fallite per recuperare l’abbonamento.

Test e passaggi successivi

1

Create in test mode

Usa la tua chiave API di test per creare l’abbonamento con payment_link: true, quindi apri il link e completa il mandato.
2

Trigger a charge

Chiama l’endpoint di addebito con un piccolo product_price (ad esempio, 100) e verifica di ricevere payment.succeeded.
3

Go live

Passa alla tua chiave API live una volta che hai convalidato gli eventi e gli aggiornamenti di stato interno.

Risoluzione dei problemi

  • 422 Richiesta non valida: Assicurati che on_demand.mandate_only sia fornito in fase di creazione e product_price sia fornito per gli addebiti.
  • Errori di valuta: Se sovrascrivi product_currency, conferma che sia supportato per il tuo account e cliente.
  • Nessun webhook ricevuto: Verifica la configurazione del tuo URL webhook e del segreto di firma.
Last modified on May 14, 2026