Metodo · Ricorrenti
Abbonamenti che non si rompono in silenzio.
I ricavi ricorrenti falliscono in due modi banali: una carta viene riemessa e l'addebito smette di funzionare, oppure un rinnovo va in soft decline e nessuno se ne accorge finché il cliente non se n'è andato. I network token risolvono il primo problema, i retry programmati il secondo, e tutto avviene senza che il tuo team debba costruire un motore di billing.
Tuo
Calendario e importo
Auto
Ritentato dopo un soft decline
Token
Resiste alle riemissioni della carta
1
Un ordine per ciclo
Come funziona
Dall'iscrizione al rinnovo, in quattro passaggi.
- 01
AUTHORIZE
Il cliente paga una sola volta al checkout; la carta viene salvata come network token.
- 02
SCHEDULE
Sei tu a definire importo, intervallo, inizio e fine — oppure puoi lasciarlo senza scadenza.
- 03
CHARGE
Ogni ciclo genera un proprio ordine, una propria ricevuta e un proprio webhook.
- 04
RECOVER
Un soft decline viene ritentato secondo un calendario, invece di essere archiviato come churn.
Ogni ciclo è un ordine vero
Un abbonamento non è un oggetto speciale con un proprio reporting: ogni addebito genera un ordine, una ricevuta e un webhook esattamente come un pagamento singolo. Questo significa che un abbonamento si riconcilia riga per riga, un singolo mese può essere rimborsato senza smontare l'intero rapporto, e il tuo team finance non ha bisogno di un secondo modello mentale per i ricavi ricorrenti.
- 01Un ordine, una ricevuta e un webhook per ciclo
- 02Rimborsa un singolo ciclo senza toccare gli altri
- 03Si riconcilia nella stessa lista dei pagamenti singoli
I due errori che costano davvero
Il churn involontario dipende soprattutto da due cause: carte scadute o riemesse e soft decline che nessuno ha ritentato. I network token seguono il titolare della carta attraverso una riemissione, così l'addebito continua a funzionare quando arriva una carta nuova. I retry programmati tentano di nuovo dopo un rifiuto temporaneo, in momenti scelti per avere più probabilità di successo rispetto al primo tentativo.
- 01I network token resistono a riemissioni e scadenze
- 02Soft decline ritentati su calendario, non abbandonati
- 03Il cliente viene avvisato solo quando serve davvero
Cosa serve per attivarlo
Un flag sul primo pagamento per salvare la carta, e un calendario. Nessun prodotto di billing separato da integrare: gli addebiti dell'abbonamento finiscono nello stesso back office e nello stesso payout di tutto il resto.
FAQ
Pagamenti ricorrenti — le domande dei merchant.
No. Calendario, retry e gestione dei token fanno parte del metodo. Da parte tua servono il primo pagamento e una decisione su importo e intervallo.
La carta salvata è un network token, che segue il titolare attraverso riemissioni e scadenze: l'abbonamento che prima si sarebbe interrotto continua ad addebitare.
Sì. La carta dietro Apple Pay o Google Pay può essere tokenizzata per gli addebiti ricorrenti, quindi un abbonamento avviato con un tap continua senza che il cliente debba tornare al checkout.
Ogni ciclo è un ordine a sé, quindi rimborsi quell'ordine, per intero o in parte, senza toccare gli altri cicli né annullare l'abbonamento.
Altri metodi
Spesso attivati insieme.
Carte salvate
Vault · Un clicI clienti abituali pagano con un tap; la carta resta nel nostro vault e nei tuoi sistemi c'è solo un riferimento.
02Pagamenti con carta
Visa · MastercardIl canale predefinito, con 3-D Secure 2.0 e autenticazione forte del cliente gestiti dentro il flusso.
03Pay by link
Nessuna integrazione necessariaUn link creato nel back office e inviato: tutti i metodi dietro di sé, nessun sito necessario.
Incassa un pagamento con ognuno.
Un merchant sandbox, chiavi API e un checkout con tutti questi metodi attivi, così puoi provare ogni metodo end to end prima di impegnarti in qualsiasi cosa.