Le sottoscrizioni crypto non funzionano come le sottoscrizioni con carta, e fingere il contrario è dove la maggior parte delle integrazioni sbaglia.Una carta di credito può essere addebitata di nuovo il mese prossimo perché possiedi un token che ti consente di prelevare fondi. La crypto non ha un equivalente: nessuno può accedere al portafoglio di un utente e addebitare. Quindi i veri pagamenti ricorrenti in crypto sono periodi di accesso prepagati — il cliente paga, tu concedi accesso fino a una data, e quando pagano di nuovo aggiungi un altro periodo. Ottieni quel modello mentale giusto e tutto il resto — promemoria, finestre di grazia, controllo accessi — si sistema. Questo post spiega come funzionano realmente le sottoscrizioni crypto, quando superano la fatturazione con carta, quando non lo fanno, e come implementare logicamente l'accesso in modo pulito.
Perché la crypto non ha addebiti automatici (e perché va bene così)
Le reti di carte sono basate sul prelievo. Quando salvi una carta, il commerciante memorizza un token e la rete consente loro di avviare addebiti secondo un programma. Il cliente non è coinvolto ogni mese. Le blockchain sono basate sul push. Un pagamento avviene solo quando il titolare del portafoglio firma e trasmette una transazione. Non c'è un'autorizzazione permanente che un gateway può ripetere. Con Payora questo è doppiamente vero: nulla viene inviato automaticamente e nulla viene addebitato automaticamente: un pagamento avviene solo quando il pagatore lo firma, e i soldi lasciano il tuo saldo solo quando lo chiedi.
A volte le persone fanno riferimento a primitive di "sottoscrizione" on-chain — ERC-20 approve()indennità, chiavi di sessione per l'astrazione dell'account o protocolli di streaming come Sablier. Questi esistono, ma sono di nicchia, specifici per la catena, richiedono che l'utente approvi in anticipo un limite di spesa e aggiungono una reale superficie di UX e sicurezza. Per il 99% delle aziende che fatturano ai clienti in USDT o BTC, il modello pragmatico è il rinnovo prepagato. È più semplice, più sicuro e funziona in modo identico su ogni moneta e rete che supporti.
Il modello prepagato: addebita, poi accumula +30 giorni
Ecco l'intero schema. Un abbonamento è semplicemente un access_untiltimestamp sull'account del cliente. Ogni pagamento riuscito lo estende.
- Nuova registrazione: il cliente paga per un piano di 30 giorni. Sul tuo webhook confermato, imposta
access_until = now() + 30 days. - Rinnovo: il cliente paga di nuovo. Estendi da quello che è più recente — il corrente
access_untilse hanno pagato in anticipo, onow()se lo hanno lasciato scadere. Questa è la regola "accumula +30 giorni":access_until = max(access_until, now()) + 30 days. - Scadenza: un lavoro programmato (o un semplice controllo su richiesta) confronta
access_untilcon adesso. Superato, l'accesso viene revocato fino al prossimo pagamento.
Usare max() è importante. Se qualcuno rinnova tre giorni prima, non vuoi bruciare quei tre giorni — estendi dalla loro data di fine esistente. Se rinnovano con una settimana di ritardo, estendi da oggi. Quella singola linea previene le due lamentele di fatturazione più comuni.
Un esempio concreto
Diciamo che vendi un abbonamento da $15/mese e accetti USDT su TRC-20 perché le commissioni sono irrisorie. Il flusso appare così:
// on confirmed payment webhook (HMAC-verified)
$sub = getSubscription($userId);
$base = max($sub->access_until, now());
$sub->access_until = $base->addDays(30);
$sub->last_paid_at = now();
save($sub);
grantAccess($userId);Questo è il cuore della fatturazione degli abbonamenti in criptovaluta. Nessuna carta memorizzata, nessun vault, nessun chargeback. Il cliente riceve una fattura o un link di pagamento alcuni giorni prima della scadenza, lo paga e il webhook fa il resto. Se non paga, l'accesso termina semplicemente — niente tentativi di addebito falliti, nessuna email di sollecito a una carta scaduta.
Fatturazione ricorrente con carta vs. pagamenti ricorrenti in criptovaluta
Nessun modello è strettamente migliore; ottimizzano per cose diverse. Le carte vincono sulla retention senza attriti. La criptovaluta vince sulla finalità, portata e costo. Ecco il confronto onesto:
| Dimensione | Fatturazione ricorrente della carta | Pagamenti ricorrenti in criptovaluta |
|---|---|---|
| Modello di addebito | Il commerciante preleva automaticamente | Il cliente effettua un pagamento ogni periodo (prepagato) |
| Azione dell'utente per ciclo | Nessuno | Un pagamento |
| Rimborsi | Sì — reversibile | No — finale alla conferma |
| Pagamenti non riusciti | Comuni (carte scadute, rifiuti) | N/A — nessun pagamento, nessun accesso |
| Portata globale | Dipendente dalla rete di carte | Chiunque abbia un portafoglio |
| Commissioni | 2,9% + fisso, per addebito | Solo gas di rete; 0% da accettare su Payora |
Il compromesso è netto: le carte si rinnovano silenziosamente ma perdono entrate a causa di rifiuti e chargeback; le criptovalute non ti sorprendono mai con un'inversione ma si basano sull'azione del cliente in ogni ciclo. Ecco perché l'email di promemoria non è facoltativa: è l'intero tuo funnel di rinnovo.
Quando ogni modello si adatta realmente
Le sottoscrizioni crypto prepagate brillano quando:
- Il tuo pubblico è globale o nativo delle criptovalute e detiene già stablecoin.
- La frode da chargeback è un costo reale: beni digitali, SaaS, adult, giochi, verticali ad alto rischio.
- Vuoi un regolamento in asset che controlli piuttosto che un processore che detiene il tuo saldo.
- Piani annuali o trimestrali sono fattibili: meno rinnovi significano meno possibilità di abbandono per inattività.
Le carte si adattano ancora meglio per sottoscrizioni consumer a basso prezzo e alto volume dove qualsiasi attrito per ciclo riduce la retention. Molte aziende gestiscono entrambe le opzioni e lasciano scegliere al cliente. Se accetti già criptovalute una tantum, aggiungere sottoscrizioni è principalmente uno strato di programmazione e messaggistica sopra il checkout che hai - vedi l'accettazione di criptovalute senza un processore di pagamento per la configurazione di base.
Implementare il controllo degli accessi in modo pulito
Mantieni la decisione di accesso estremamente semplice e centralizzala. Ogni richiesta protetta dovrebbe porre una domanda: è now() < access_until? Non disperdere la logica di abbonamento nel tuo codice.
- Memorizza lo stato, non gli eventi. La fonte della verità è
access_until, non un mucchio di righe di pagamento. I pagamenti mutano quel campo; la tua app legge it. - Aggiungi una finestra di grazia.Un pagamento confermato on-chain può richiedere minuti. Dai un piccolo margine (diciamo, 2-3 giorni dopo la scadenza) in modo che un cliente che paga nell'ultimo giorno non venga bloccato mentre la transazione viene confermata.
- Gestisci tutto tramite il webhook firmato.Estendi l'accesso solo quando Payora invia un evento di pagamento confermato e verifica la
HMAC-SHA256firma prima di fidarti. Dettagli in verifica della firma del webhook. - Invia le fatture di rinnovo prima della scadenza.Genera un link di pagamento alcuni giorni prima e invialo via email. Questo è lo stesso flusso di fatturazione utilizzato dai liberi professionisti — vedi fatturazione ai clienti in crypto.
- Rendi il rinnovo un clic.Riutilizza la moneta e la rete preferite dal cliente in modo che un membro di ritorno non debba scegliere nuovamente tra le catene ogni mese.
Per i rinnovi, i fondi confermati vengono accreditati secondo il tuo metodo di regolamento configurato: per impostazione predefinita puoi visualizzare interno saldo e spostarlo secondo il tuo programma, pagando una commissione del tuo piano (1,5% su Free) più la commissione di rete della moneta solo quando prelevi (minimo $50), non quando accetti. Il regolamento diretto approvato è specifico per l'account dove supportato. Mantenere basse le commissioni sui rinnovi merita una lettura anche: ridurre le commissioni sui pagamenti in crypto.
Errori comuni da evitare
- Estendendo da
now()su rinnovi anticipati — rubi giorni per cui i clienti hanno pagato. Sempremax(access_until, now()). - Revocando l'accesso nel momento in cui il tempo scade — una transazione di conferma sembra un mancato pagamento. Usa la finestra di grazia.
- Fidandosi di un webhook non firmato — chiunque può POSTare al tuo endpoint. Verifica la firma o distribuirai abbonamenti gratuiti.
- Promettendo "auto-rinnovo" nell'interfaccia — è prepagato. Dì "si rinnova quando paghi"; l'onestà qui previene ticket di supporto.
Inizia
Le sottoscrizioni crypto sono meno magia e più disciplina: periodi prepagati, un singolo access_until campo e un webhook firmato che accumula tempo. È un modello che puoi spedire in un pomeriggio e ragionare per sempre. Crea un account Payora gratuito per ottenere le chiavi API, collegare i tuoi rinnovi contro il SDK e la documentazione del webhook, o prova il demo di checkout dal vivo prima per vedere il flusso di pagamento che i tuoi membri utilizzeranno. Quando sei pronto, configura il checkout ospitato, le fatture e i link di pagamento e inizia a fatturare nelle oltre 20 monete che i tuoi clienti già detengono.

Comments