Per accettare pagamenti in criptovaluta in WHMCS devi installare un modulo gateway, incollare una chiave API, puntarlo a un URL webhook sul tuo server e contrassegnare la fattura come pagata quando arriva un webhook firmato. Quella parte è meccanica. La parte che vale la pena leggere è tutto ciò che è specifico per l'hosting: i tuoi acquirenti sono insolitamente nativi delle criptovalute, la tua fatturazione si ripete ogni ciclo e i chargeback sono un reale rischio commerciale. Le criptovalute cambiano tutte e tre le cose — due a tuo favore e una che ti costa un processo manuale su cui dovresti decidere prima di attivarlo.
L'hosting non è un negozio normale
La maggior parte dei consigli su "accettare criptovalute" è scritta per qualcuno che vende t-shirt, dove le criptovalute sono un extra che forse il 1% degli acquirenti considera. L'hosting è diverso. Le persone che acquistano un VPS, un server dedicato o un dominio sono sviluppatori, sysadmin, aziende con mentalità offshore e acquirenti in paesi dove un pagamento con carta a una società di hosting straniera viene rifiutato dall'emittente senza alcun motivo dichiarato. Per una fetta significativa di loro, le criptovalute non sono una comodità — è la differenza tra una vendita e nessuna vendita.
Puoi vederlo nella coda di supporto. Nessuno invia un'email a un negozio di abbigliamento chiedendo se accettano USDT; le aziende di hosting ricevono costantemente quell'email, e ogni mittente ha già deciso di acquistare.
La parte onesta: non ci sono carte memorizzate
Qui è dove hai bisogno di precisione invece di marketing. L'hosting è fatturazione ricorrente: WHMCS esiste per emettere una fattura ogni mese o anno e riscuotere senza che il cliente ci pensi. Un gateway per carte fa questo memorizzando un token e prelevando fondi alla scadenza.
Un gateway crypto non custodiale non può. Non c'è un token da memorizzare e nessuna autorizzazione permanente per prelevare dal portafoglio di qualcuno — i fondi si muovono solo quando il titolare del portafoglio firma una transazione. Quindi "fatturazione ricorrente in criptovaluta" è onestamente descritta come una fattura più una richiesta di pagamento che il cliente paga ogni ciclo, non un addebito automatico silenzioso. Il modello completo, comprese le approcci dei contratti intelligenti e perché non si adattano alla maggior parte della fatturazione, è in abbonamenti crypto e pagamenti ricorrenti spiegati.
Rendere i rinnovi indolori comunque
Il divario tra "addebito automatico" e "il cliente paga ogni ciclo" è un problema di UX, ed è risolvibile. Cosa funziona:
- Fattura con largo anticipo rispetto alla data di scadenza. WHMCS genera già fatture in anticipo. Dai ai pagatori in criptovaluta una corsia di atterraggio più lunga rispetto a un cliente con carta — qualcuno che sposta fondi da un exchange ha bisogno di giorni, non di minuti.
- Usa una finestra di fatturazione generosa. Una fattura in criptovaluta è quotata a un tasso che vale per una breve finestra, quindi genera la richiesta di pagamento quando il cliente è pronto a pagare, non settimane prima.
- Lascia che le persone paghino in anticipo. I clienti nativi delle criptovalute prepagheranno felicemente un anno per smettere di pensarci, e ogni anno prepagato è un rinnovo che non insegui mai.
- I promemoria sono il tuo addebito automatico. Avvisi di scadenza, un chiaro link di pagamento, una data di sospensione visibile — lo stesso muscolo che usi per i clienti di bonifico bancario.
- Non sospendere il primo giorno di mancato pagamento. Un ritardo di conferma o un prelievo in attesa non è un moroso. Costruisci un periodo di grazia.
Chargeback: il problema più costoso dell'hosting
L'hosting è un magnete per chargeback e tutti nell'industria sanno perché. Una carta rubata acquista un server, il server viene utilizzato per qualsiasi cosa sia stato acquistato — spam, scansione, mining, peggio — e poi il vero titolare della carta annulla l'addebito. Perdi i soldi, le risorse che ha consumato e la commissione, e il tuo rapporto di chargeback si avvicina alla soglia in cui il tuo conto merchant riceve una conversazione che non vuoi. La frode non è incidentale al prodotto; il prodotto è lo strumento di frode.
I pagamenti in criptovaluta sono definitivi. Una volta che una transazione ha le conferme richieste non c'è emittente, nessuna finestra di contestazione e nessun annullamento. Nessuno richiede un chargeback per un server dopo averlo utilizzato per tre settimane. Per un'azienda di hosting, questo è spesso il singolo argomento più forte nella colonna, e l'economia è coperta in accettare pagamenti senza un conto merchant o chargeback.
La frode non svanisce, per essere chiari. I clienti abusivi si registrano ancora — pagano solo con i propri soldi e non possono recuperarli. La tua gestione degli abusi rimane dov'era.
Il compromesso, dichiarato chiaramente
La finalità taglia in entrambi i sensi. Poiché nessuno può annullare un pagamento a te, tu sei l'unico che può restituire denaro — come pagamento in uscita, a mano. Non c'è un pulsante "rimborso" che annulla una transazione conclusa. Ciò significa due decisioni prima del lancio:
- Cancellazioni pro-rata. Decidi prima la politica e scrivila nei tuoi ToS. Molti host emettono credito per l'account invece di un rimborso on-chain, che è più pulito e mantiene il cliente. Se rimborsi on-chain, la commissione di rete viene detratta e il prezzo sarà cambiato — rimborsa il valore fiat concordato o l'importo esatto ricevuto, ma specifica quale per iscritto.
- Chi firma il pagamento in uscita. In un'impostazione non custodiale, gli indirizzi di ricezione derivano solo da materiale di chiave pubblica e le chiavi private non toccano mai il server, quindi i rimborsi e i pagamenti sono firmati offline da un umano. Questa è una caratteristica — una cassa di fatturazione compromessa non può prosciugare i tuoi guadagni — ma i rimborsi sono un atto deliberato, non una chiamata API. Il tuo saldo interno è dove vedi cosa hai raccolto e lo sposti; la tariffazione è 0% per accettare, con commissioni solo quando il denaro esce: 1,5% su pagamenti, trasferimenti e prelievi sul piano gratuito, più la commissione di rete della moneta’ su un pagamento o un prelievo (prelievo minimo $50).
Provisioning: fidati del webhook, mai del reindirizzamento
Questo è il dettaglio che separa un'impostazione funzionante da una sfruttabile. Quando un cliente termina di pagare, il suo browser viene reindirizzato al tuo installazione di WHMCS. Quel reindirizzamento non è prova di pagamento. È solo un URL, e chiunque può colpire il tuo URL di ritorno.
Provisiona sul webhook firmato e nient'altro. Payora firma ogni callback con HMAC-SHA256 sul payload, con una finestra di timestamp e una chiave di idempotenza. Il tuo endpoint verifica la firma, controlla che il timestamp sia recente, verifica che non abbia già elaborato quella chiave, e solo allora contrassegna la fattura come pagata e lascia che l'automazione si attivi. La documentazione copre lo schema di firma e il PHP SDK in un file che lo gestisce.
L'idempotenza è più importante qui che in un negozio: un webhook elaborato due volte su un ordine di hosting non solo accredita doppio una fattura, può attivare un secondo ciclo di provisioning. Focalizzati sulla chiave di idempotenza, non su "ho già visto questo id ordine".
Quali reti abilitare per il provisioning istantaneo
Se il tuo prodotto viene fornito istantaneamente, il tempo di conferma è l'esperienza di checkout. Un cliente che clicca su "ordina VPS" alle 2 del mattino si aspetta una password di root in pochi minuti, e il tempo di blocco di Bitcoin è una cattiva scelta — aspettare conferme per un VPS da $6 è un ticket di supporto in fase di creazione. Preferisci reti veloci e economiche per impostazione predefinita e lascia che Bitcoin sia un'opzione piuttosto che il titolo:
| Rete | Adatta | Nota |
|---|---|---|
| TON (Gram) | Provisioning istantaneo | Secondi fino alla finalità, commissioni minime |
| Tron | Pubblico pesante in USDT | Il binario USDT predefinito per gran parte del mondo |
| Solana | Provisioning istantaneo | Veloce ed economico |
| Bitcoin | Ordini più grandi e non urgenti | Piani annuali, server dedicati, depositi |
Le stablecoin meritano una menzione speciale qui: USDT e USDC valutano il tuo piano da $6/mese a $6, senza discussioni su quale tasso si applica. Quante conferme ogni rete ha realmente bisogno, e perché la risposta dipende dal valore dell'ordine, è trattato in quante conferme rendono un pagamento in criptovaluta sicuro.
Imposta il modulo Payora per accettare pagamenti in criptovaluta in WHMCS
Il modulo gateway di WHMCS è una delle integrazioni gratuite che pubblichiamo su moduli, insieme ad altre 21. È il modo più veloce per accettare pagamenti in criptovaluta in WHMCS senza scrivere codice. A un livello alto:
- Installa il modulo gateway nella tua installazione di WHMCS e attivalo tra i tuoi gateway di pagamento.
- Crea un account gratuito su registrati e incolla la chiave API nelle impostazioni del modulo.
- Imposta l'URL del webhook sull'endpoint di callback del modulo in modo che le notifiche firmate lo raggiungano.
- Abilita le monete e le reti che desideri offrire e configura il tuo materiale di chiave di ricezione.
- Effettua un piccolo ordine reale su una rete economica e conferma che la fattura venga contrassegnata come Pagata dal webhook.
Da lì il flusso è quello standard descritto in accettare pagamenti: la fattura riporta il tuo id ordine e l'importo, il cliente sceglie una moneta nel checkout ospitato, Payora osserva la catena fino alla finalità di quella moneta, e il tuo server riceve il callback firmato. Se preferisci saltare il modulo — molti host eseguono un WHMCS pesantemente personalizzato — l'API REST in JSON semplice fa lo stesso lavoro.
Inizia con una rete veloce e una stablecoin, osserva cosa scelgono effettivamente i clienti e aggiungi da lì. Crea un account, prendi una chiave API e fai un vero ordine da $5 attraverso il tuo checkout prima di annunciarlo.
Comments