Vai al contenuto principale

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 desideri che il cliente approvi il mandato tramite checkout ospitato, imposta payment_link: true e fornisci un return_url.

Come funziona l’on-demand

  1. Crei una sottoscrizione con l’oggetto on_demand per autorizzare un metodo di pagamento e, facoltativamente, raccogliere un addebito iniziale.
  2. In seguito, crei addebiti contro quella sottoscrizione con importi personalizzati utilizzando l’endpoint di addebito dedicato.
  3. Ascolti i webhook (ad 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 della valuta opzionale per l’addebito.
product_description
string
Sovrascrittura della descrizione opzionale per questo addebito.
adaptive_currency_fees_inclusive
boolean
Se vero, include le spese per la valuta adattiva all’interno di product_price. Se falso, le spese vengono aggiunte sopra.
metadata
object
Metadati aggiuntivi per il pagamento. Se omesso, vengono utilizzati i metadati della sottoscrizione.
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 una sottoscrizione che non è on-demand potrebbe fallire. Assicurati che la sottoscrizione abbia on_demand: true nei suoi dettagli prima di addebitare.

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.
Schemi di ripetizione a raffica possono essere contrassegnati 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 qui sotto.

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 (sottoscrizioni)

  • 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)
Passaggio finale: se ancora non pagato, contrassegna la sottoscrizione come non pagata o annullala, in base alla tua politica. Notifica il cliente durante il periodo per aggiornare il proprio metodo di pagamento.

Evita ripetizioni a raffica; allineati all’orario di autorizzazione

  • Ancorare le ripetizioni all’ora 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, programma 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, programma il prossimo tentativo a T + X days per preservare l’allineamento dell’ora del giorno.
Fuso orario e DST: usa uno standard temporale coerente per la programmazione e converti solo per la visualizzazione per mantenere gli intervalli.

Codici di rifiuto che non dovresti ripetere

  • STOLEN_CARD
  • DO_NOT_HONOR
  • FRAUDULENT
  • PICKUP_CARD
  • AUTHENTICATION_FAILURE
  • LOST_CARD
Per un elenco completo delle motivazioni di rifiuto e se sono correggibili dall’utente, consulta la Documentazione sui fallimenti delle transazioni.
Ripeti solo in caso di problemi soft/temporanei (ad es., insufficient_funds, issuer_unavailable, processing_error, timeout di rete). Se lo stesso rifiuto si ripete, interrompi ulteriori ripetizioni.

Linee guida per l’implementazione (senza codice)

  • Usa un pianificatore/coda che persiste timestamp precisi; calcola il prossimo tentativo all’orario esatto (ad es., T + 3 days alla stessa HH:MM).
  • Mantieni e fai riferimento all’ora dell’ultimo pagamento riuscito T per calcolare il prossimo tentativo; non raggruppare più sottoscrizioni 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 in modo proattivo: 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 irrilevanti.

Monitora i risultati con i webhook

Implementa la gestione dei webhook per monitorare il percorso del cliente. Consulta Implementazione dei webhook.
  • subscription.active: Mandato autorizzato e sottoscrizione attivata
  • subscription.failed: Creazione fallita (ad es., fallimento del mandato)
  • subscription.on_hold: Sottoscrizione messa in attesa (ad es., stato non pagato)
  • payment.succeeded: Addebito riuscito
  • payment.failed: Addebito fallito
Per i flussi on-demand, concentrati su payment.succeeded e payment.failed per riconciliare gli addebiti basati sull’uso.

Test e prossimi passi

1

Crea in modalità test

Usa la tua chiave API di test per creare la sottoscrizione 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_only sia fornito alla 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 l’URL del tuo webhook e la configurazione del segreto della firma.