Panoramica
Gli abbonamenti on-demand ti consentono di autorizzare il 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.Gli abbonamenti on-demand sono ora disponibili per tutte le aziende. Questa funzionalità consente un controllo di fatturazione flessibile per servizi basati sull’uso e misurati.
- Creare un abbonamento on-demand (autorizzare un mandato con prezzo iniziale opzionale)
- Attivare addebiti successivi con importi personalizzati
- Monitorare i risultati utilizzando webhook
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
Come funziona l’on-demand
- Crei un abbonamento con l’oggetto
on_demandper autorizzare un metodo di pagamento e, facoltativamente, raccogliere un addebito iniziale. - In seguito, crei addebiti contro quell’abbonamento con importi personalizzati utilizzando l’endpoint di addebito dedicato.
- Ascolti i webhook (ad es.,
payment.succeeded,payment.failed) per aggiornare il tuo sistema.
Crea un abbonamento on-demand
Endpoint: POST /subscriptions Campi chiave della richiesta (corpo):Parametri del corpo della richiesta
Parametri del corpo della richiesta
ID del prodotto per l’abbonamento.
Numero di unità. Minimo 1.
Indirizzo di fatturazione per il cliente.
Allegare un cliente esistente o fornire i dettagli del cliente.
Se vero, crea un link di checkout ospitato per l’autorizzazione del mandato e il pagamento iniziale opzionale.
Dove reindirizzare il cliente dopo aver completato il checkout ospitato.
Se vero, autorizza il metodo di pagamento senza addebitare il cliente durante la creazione.
Importo dell’addebito iniziale (nell’unità monetaria più piccola). Se specificato, questo valore sovrascrive il prezzo originale del prodotto impostato durante la creazione del prodotto. Se omesso, viene utilizzato il prezzo memorizzato del prodotto. Esempio: per addebitare $1.00, passare
100.Sovrascrittura della valuta opzionale per l’addebito iniziale. Predefinito alla valuta del prodotto.
Sovrascrittura della descrizione opzionale per la fatturazione e gli articoli di linea.
Se vero, include le spese di valuta adattiva all’interno di
product_price. Se falso, le spese vengono aggiunte sopra. Ignorato quando la tariffazione adattiva è disabilitata.Crea un abbonamento on-demand
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Imposta
payment_link: true, reindirizza il cliente a payment_link per completare l’autorizzazione del mandato.Success
Addebita un abbonamento on-demand
Dopo che il mandato è stato autorizzato, crea addebiti secondo necessità. Endpoint: POST /subscriptions/{subscription_id}/charge Campi chiave della richiesta (corpo):Parametri del corpo della richiesta di addebito
Parametri del corpo della richiesta di addebito
Importo da addebitare (nell’unità monetaria più piccola). Esempio: per addebitare $25.00, passare
2500.Sovrascrittura della valuta opzionale per l’addebito.
Sovrascrittura della descrizione opzionale per questo addebito.
Se vero, include le spese di valuta adattiva all’interno di
product_price. Se falso, le spese vengono aggiunte sopra.Metadati aggiuntivi per il pagamento. Se omesso, vengono utilizzati i metadati dell’abbonamento.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Riprova ai pagamenti
Il nostro sistema di rilevamento delle frodi potrebbe bloccare schemi di ripetizione aggressivi (e può contrassegnarli come potenziale test di carte). Segui una politica di ripetizione sicura.Principi per politiche di ripetizione sicure
- Meccanismo di backoff: Usa il backoff esponenziale tra le ripetizioni.
- Limiti di ripetizione: Limita il totale delle ripetizioni (massimo 3-4 tentativi).
- Filtraggio intelligente: Ripeti solo in caso di errori ripetibili (ad es., errori di rete/emittente, fondi insufficienti); non ripetere mai i rifiuti definitivi.
- Prevenzione dei test di carte: Non ripetere i rifiuti come
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Variazione dei metadati (opzionale): Se mantieni il tuo sistema di ripetizione, differenzia le ripetizioni tramite metadati (ad es.,
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)
Evita ripetizioni a raffica; allineati all’orario di autorizzazione
- Ancorare le ripetizioni al timestamp di autorizzazione originale per evitare comportamenti a “raffica” nel tuo portafoglio.
- Esempio: Se il cliente inizia una prova o un mandato alle 13:10 di oggi, pianifica le ripetizioni successive alle 13:10 nei giorni successivi secondo il tuo backoff (ad es., +3 giorni → 13:10, +7 giorni → 13:10).
- In alternativa, se memorizzi l’ora dell’ultimo pagamento riuscito
T, pianifica il prossimo tentativo aT + X daysper preservare l’allineamento dell’ora del giorno.
Fuso orario e ora legale: utilizza uno standard di tempo coerente per la pianificazione e converti solo per la visualizzazione per mantenere gli intervalli.
Codici di rifiuto che non dovresti ripetere
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Per un elenco completo delle motivazioni di rifiuto e se sono correggibili dall’utente, vedere la
Documentazione sui fallimenti delle transazioni.
Linee guida per l’implementazione (senza codice)
- Usa un pianificatore/coda che persiste timestamp precisi; calcola il prossimo tentativo all’esatto offset dell’ora del giorno (ad es.,
T + 3 daysalla stessa HH:MM). - Mantieni e fai riferimento all’ora dell’ultimo pagamento riuscito
Tper calcolare il prossimo tentativo; non raggruppare più abbonamenti nello stesso istante. - Valuta sempre l’ultima motivazione di rifiuto; interrompi le ripetizioni per i rifiuti definitivi nell’elenco di esclusione sopra.
- Limita le ripetizioni concorrenti per cliente e per account per prevenire picchi accidentali.
- Comunica proattivamente: invia un’email/SMS al cliente per aggiornare il proprio metodo di pagamento prima del prossimo tentativo programmato.
- Usa i metadati solo per l’osservabilità (ad es.,
retry_attempt); non cercare mai di “evadere” i sistemi di frode/rischio ruotando campi insignificanti.
Monitora i risultati con i webhook
Implementa la gestione dei webhook per monitorare il percorso del cliente. Vedi Implementazione dei Webhook.- subscription.active: Mandato autorizzato e abbonamento attivato
- subscription.failed: Creazione fallita (ad es., fallimento del mandato)
- subscription.on_hold: Abbonamento messo in attesa (ad es., stato non pagato)
- payment.succeeded: Addebito riuscito
- payment.failed: Addebito fallito
Test e prossimi passi
1
Crea in modalità test
Usa la tua chiave API di test per creare l’abbonamento con
payment_link: true, quindi apri il link e completa il mandato.2
Attiva un addebito
Chiama l’endpoint di addebito con un piccolo
product_price (ad es., 100) e verifica di ricevere payment.succeeded.3
Vai in produzione
Passa alla tua chiave API live una volta che hai convalidato eventi e aggiornamenti dello stato interno.
Risoluzione dei problemi
- 422 Richiesta non valida: Assicurati che
on_demand.mandate_onlysia fornito alla creazione e cheproduct_pricesia 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 l’URL del tuo webhook e la configurazione del segreto della firma.