Come tracciare e scalare crediti AI in un’app o sito web

Se stai costruendo un’applicazione AI, probabilmente prima o poi ti troverai davanti a questa situazione.

Un utente acquista un pacchetto di crediti.

Utilizza il prodotto per qualche giorno.

Poi apre un ticket di supporto e chiede:

“Dove sono finiti i miei crediti?”

A quel punto inizia il problema.

Molte startup AI implementano inizialmente un sistema molto semplice: un saldo associato all’utente che aumenta quando vengono acquistati crediti e diminuisce quando vengono utilizzate funzionalità come chatbot, generazione immagini o video AI.

Finché il prodotto è piccolo, questa soluzione sembra funzionare.

Quando però arrivano più utenti, richieste simultanee, retry automatici e processi asincroni, il semplice contatore dei crediti inizia a mostrare i suoi limiti.

I crediti non tornano più.

Gli utenti segnalano anomalie.

Diventa difficile capire chi ha consumato cosa e quando.

Ed è proprio in questo momento che si scopre una realtà importante:

tracciare correttamente i crediti AI è un problema di infrastruttura, non di interfaccia utente.

In questa guida vedremo come progettare un sistema di crediti AI affidabile, come gestire il consumo, i top-up, i pagamenti e l’accesso alle funzionalità, e quali sono gli errori più comuni che emergono quando un’applicazione inizia a crescere.

Cos’è un sistema di crediti AI 💳

Un sistema di crediti AI è un modello di monetizzazione che consente agli utenti di acquistare una quantità di utilizzo prima di consumare il servizio.

In pratica, invece di pagare ogni singola operazione o avere accesso illimitato tramite un abbonamento, l’utente acquista un saldo di crediti che verrà utilizzato nel tempo.

È il modello adottato da molte applicazioni moderne basate sull’intelligenza artificiale.

Pensiamo ad esempio a:

• generatori di immagini AI
• generatori video AI
• chatbot basati su modelli linguistici
• agenti AI
• piattaforme che espongono API AI

In tutti questi casi, ogni operazione ha un costo reale per l’azienda che eroga il servizio.

Ogni richiesta inviata a OpenAI, Anthropic o Gemini genera infatti un consumo di risorse e quindi un costo infrastrutturale.

Per questo motivo molte startup AI preferiscono vendere crediti anziché offrire utilizzo illimitato.

Un esempio molto semplice potrebbe essere il seguente:

L’utente acquista un pacchetto di 1.000 crediti e li consuma progressivamente in base all’utilizzo.

Questo approccio offre un vantaggio importante: collega direttamente il consumo ai costi.

Più un utente utilizza il prodotto, più crediti consumerà.

Dal punto di vista del business, il sistema è spesso più sostenibile rispetto a una subscription illimitata.

Dal punto di vista tecnico, però, introduce nuove complessità che molti team sottovalutano.

Perché un semplice contatore non basta 📉

Quando si sviluppa la prima versione di un prodotto, la tentazione è quella di implementare il sistema di crediti nel modo più semplice possibile.

Molto spesso la struttura è questa:

users
------
id
credit_balance

Ogni volta che un utente esegue un’operazione, il saldo diminuisce. Ogni volta che acquista nuovi crediti, il saldo aumenta.

Sembra una soluzione perfettamente ragionevole. E per qualche settimana lo è davvero.

Il problema emerge quando il numero di utenti cresce.

Immaginiamo un’applicazione che genera immagini AI. Un utente avvia una generazione che costa 10 crediti. La richiesta viene inviata al server. Il server scala il saldo. Pochi istanti dopo la connessione si interrompe.

Il client non riceve la risposta e decide di ritentare automaticamente la stessa operazione.

Il risultato?

La stessa immagine potrebbe consumare 20 crediti invece di 10.

Questo è solo uno dei problemi più comuni.

Un altro scenario molto frequente riguarda le richieste concorrenti.

Immaginiamo che un utente abbia 100 crediti disponibili. Apre contemporaneamente più schede del browser e avvia diverse operazioni.

Se il sistema non gestisce correttamente la concorrenza, più richieste potrebbero leggere contemporaneamente lo stesso saldo disponibile e autorizzare consumi che non dovrebbero essere consentiti.

In questi casi il saldo finale può diventare incoerente.

Ma il problema più grande arriva quando l’utente apre un ticket di supporto.

La domanda è quasi sempre la stessa:

“Perché mi sono stati scalati questi crediti?”

Se nel sistema esiste soltanto un numero che rappresenta il saldo corrente, rispondere diventa praticamente impossibile.

Si sa quanti crediti possiede l’utente in questo momento.

Non si sa però:

• quando sono stati consumati
• da quale operazione
• da quale dispositivo
• se è avvenuto un retry
• se è stato applicato un bonus
• se c’è stato un rimborso

Ed è qui che molte startup AI capiscono che il saldo non è la vera fonte di verità.

Il saldo è soltanto una conseguenza.

La vera fonte di verità è lo storico completo dei movimenti.

Come tracciare correttamente il consumo dei crediti 📊

Per costruire un sistema affidabile bisogna cambiare prospettiva.

Invece di chiedersi:

“Quanti crediti ha l’utente?”

bisogna chiedersi:

“Quali eventi hanno modificato il saldo dell’utente?”

Questa differenza sembra sottile, ma cambia completamente l’architettura del sistema.

Le piattaforme moderne utilizzano generalmente un usage ledger, cioè uno storico dettagliato di tutti i movimenti.

Ogni variazione del saldo genera una registrazione.

Ad esempio:

In questo modo il saldo diventa semplicemente la somma di tutti gli eventi.

Se un cliente contesta un consumo, è possibile risalire esattamente a cosa è successo.

Se si verifica un bug, il ledger permette di ricostruire la situazione.

Se occorre eseguire un audit, tutte le informazioni sono disponibili.

Questo approccio è molto più robusto rispetto alla semplice memorizzazione del saldo.

L’importanza dell’idempotenza 🔄

Quando si parla di tracking dei crediti AI, esiste una parola che compare continuamente: idempotenza.

In termini semplici, significa che la stessa operazione non deve essere elaborata due volte.

Immaginiamo che una generazione immagine abbia l’identificativo:

{
  "usage_id": "img_12345",
  "credits": 10
}

Se per qualsiasi motivo il sistema riceve nuovamente quell’evento, deve riconoscere che è già stato elaborato e ignorarlo.

In assenza di idempotenza, retry automatici e problemi di rete possono facilmente causare consumi duplicati.

Ed è proprio questo uno dei motivi più frequenti per cui i saldi dei crediti iniziano a non tornare.

Come gestire l’accesso dopo il pagamento 🔐

Quando un utente acquista crediti o sottoscrive un piano, molte applicazioni commettono un errore concettuale molto comune.

Considerano il pagamento come sinonimo di accesso.

In altre parole:

L’utente ha pagato, quindi può utilizzare la funzionalità.

Finché il prodotto è semplice, questo approccio può sembrare sufficiente.

Con il tempo però emergono numerosi casi particolari.

Ad esempio:

• l’utente ha pagato ma il pagamento viene rimborsato
• l’abbonamento viene annullato
• il piano viene modificato
• viene concesso un accesso promozionale
• un cliente enterprise ottiene funzionalità personalizzate
• alcuni utenti hanno accesso a modelli AI premium e altri no

A questo punto il pagamento non è più sufficiente per determinare cosa un utente può fare.

Serve un livello intermedio.

È qui che entrano in gioco gli entitlements.

Cosa sono gli entitlements 🎟️

Gli entitlements rappresentano i diritti di utilizzo assegnati a un utente.

Definiscono concretamente quali funzionalità possono essere utilizzate.

Ad esempio:

In questo caso il pagamento non abilita direttamente le funzionalità.

Il pagamento genera gli entitlements.

Sono poi gli entitlements a determinare cosa l’utente può utilizzare.

Questa separazione diventa fondamentale quando il prodotto cresce.

Consente di modificare regole, piani e funzionalità senza dover riscrivere continuamente la logica applicativa.

Crediti ed entitlements non sono la stessa cosa ⚖️

Molti team confondono questi due concetti.

In realtà risolvono problemi differenti.

I crediti rispondono alla domanda:

Quanto può consumare l’utente?

Gli entitlements rispondono alla domanda:

Cosa può utilizzare l’utente?

Immaginiamo un utente che possiede:

• 5.000 crediti disponibili
• accesso alla generazione immagini
• nessun accesso alla generazione video

Anche se dispone di crediti sufficienti, non può utilizzare la funzionalità video.

L’entitlement lo impedisce.

Allo stesso modo un utente potrebbe avere accesso a una funzione ma non avere crediti disponibili per utilizzarla.

Per questo motivo crediti ed entitlements vengono quasi sempre gestiti come componenti separati.

Come sincronizzare pagamenti e crediti 💸

Una delle domande più frequenti riguarda la sincronizzazione tra Stripe e il sistema di crediti.

Molti sviluppatori, nelle prime versioni del prodotto, interrogano direttamente Stripe ogni volta che devono verificare qualcosa.

Questo approccio funziona inizialmente ma tende a diventare fragile nel tempo.

Le piattaforme moderne adottano normalmente un modello diverso.

Il pagamento viene considerato un evento.

Quando Stripe conferma una transazione, invia una notifica al sistema.

Questa notifica viene elaborata e produce gli aggiornamenti necessari.

Il flusso tipico è il seguente:

Pagamento effettuato
        ↓
Stripe conferma il pagamento
        ↓
Webhook ricevuto
        ↓
Crediti assegnati
        ↓
Entitlements aggiornati
        ↓
Accesso disponibile

In questo modo il sistema mantiene una propria fonte di verità senza dipendere continuamente dal provider di pagamento.

Perché i webhook sono fondamentali 📡

I webhook sono spesso sottovalutati.

In realtà rappresentano il punto di collegamento tra il mondo dei pagamenti e il mondo dell’applicazione.

Quando un evento importante avviene su Stripe, il sistema viene notificato automaticamente.

Ad esempio:

• pagamento completato
• abbonamento creato
• abbonamento cancellato
• rimborso effettuato
• contestazione aperta

Ogni evento può generare una modifica nello stato del cliente.

Senza webhook, il sistema sarebbe costretto a interrogare continuamente Stripe, aumentando complessità e punti di errore.

Un esempio pratico 🧾

Immaginiamo di vendere un pacchetto da 10.000 crediti AI.

Quando il pagamento viene completato:

1. Stripe conferma la transazione.
2. Il webhook viene ricevuto.
3. Il ledger registra un nuovo movimento da +10.000 crediti.
4. Il saldo viene aggiornato.
5. Gli entitlements vengono verificati o aggiornati.
6. L’utente può iniziare a utilizzare il servizio.

L’intero processo avviene automaticamente.

Dal punto di vista dell’utente sembra semplice.

Dal punto di vista dell’infrastruttura coinvolge diversi componenti che devono restare sincronizzati.

Come scalare il sistema 🚀

Finché si hanno pochi utenti, quasi qualsiasi implementazione sembra funzionare.

Le vere sfide emergono quando il prodotto inizia a crescere.

Ed è proprio qui che molti sistemi di crediti mostrano i loro limiti.

Il problema delle richieste concorrenti ⚡

Immaginiamo un utente con 100 crediti disponibili.

Da più schede del browser avvia contemporaneamente diverse operazioni.

Se il sistema non gestisce correttamente la concorrenza, più richieste potrebbero leggere lo stesso saldo e autorizzare consumi che non dovrebbero essere consentiti.

Per evitare questo problema è necessario utilizzare operazioni atomiche e transazioni affidabili.

Processi asincroni e AI 🤖

Molte operazioni AI non terminano immediatamente.

Una generazione video può richiedere minuti.

Un agente AI può eseguire attività in background.

Una pipeline di elaborazione può coinvolgere più servizi.

In questi casi il sistema deve essere in grado di tracciare l’intero ciclo di vita dell’operazione.

Non basta sapere che un credito è stato consumato.

Bisogna sapere:

• quando
• perché
• da quale richiesta
• con quale risultato

Più il prodotto cresce, più questi dettagli diventano importanti.

Audit e supporto clienti 🕵️

Esiste un momento che arriva in qualsiasi prodotto di successo.

Un cliente apre un ticket e scrive:

“Mi mancano 2.000 crediti. Potete verificare?”

Se non esiste uno storico dettagliato degli eventi, rispondere diventa estremamente difficile.

Se invece esistono ledger, usage tracking ed eventi registrati, è possibile ricostruire l’intera cronologia in pochi minuti.

Ed è proprio questo il motivo per cui le piattaforme moderne trattano i crediti come un sistema finanziario e non come una semplice variabile numerica.

Errori comuni ❌

Dopo aver lavorato con diversi modelli di monetizzazione AI, emerge sempre lo stesso schema.

I problemi raramente nascono dal pricing.

Nascono dall’architettura.

Molti team riescono a costruire rapidamente una prima versione del sistema di crediti, ma incontrano difficoltà quando il prodotto inizia a ricevere traffico reale.

Vediamo gli errori più frequenti.

Salvare soltanto il saldo disponibile 📉

È probabilmente l’errore più comune.

All’inizio sembra sufficiente memorizzare un numero che rappresenta i crediti disponibili.

Il problema è che il saldo non spiega cosa è successo.

Quando un cliente contesta un consumo o quando si verifica un’anomalia, il sistema deve poter rispondere a domande molto precise:

• Quando sono stati consumati i crediti?
• Da quale operazione?
• È stato eseguito un retry?
• È stato applicato un rimborso?

Senza uno storico dettagliato, il saldo da solo non è sufficiente.

Non utilizzare un usage ledger 📚

Molti sistemi memorizzano soltanto il risultato finale.

Le piattaforme moderne, invece, registrano ogni movimento.

Acquisti, consumi, bonus, rimborsi e top-up vengono salvati come eventi.

Questo approccio consente di ricostruire la cronologia completa del cliente e riduce enormemente i problemi di supporto.

Gestire i crediti senza idempotenza 🔁

Le applicazioni moderne sono piene di retry automatici.

Le connessioni possono interrompersi.

I processi possono essere eseguiti più volte.

I webhook possono essere ricevuti nuovamente.

Senza idempotenza lo stesso evento rischia di essere elaborato due volte.

Nel contesto dei crediti AI questo significa spesso consumi errati e saldi incoerenti.

Controllare Stripe ad ogni richiesta 💳

Un altro errore frequente consiste nell’utilizzare Stripe come sistema di autorizzazione.

In pratica, ogni volta che un utente richiede una funzionalità, l’applicazione controlla direttamente lo stato dell’abbonamento sul provider di pagamento.

Questa soluzione può sembrare semplice, ma crea un forte accoppiamento tra il sistema di billing e l’applicazione.

Le piattaforme più mature utilizzano invece una separazione chiara:

• Stripe gestisce i pagamenti
• Gli entitlements gestiscono i permessi
• L’access control gestisce le autorizzazioni

Confondere crediti e accesso 🚫

Molti team trattano i crediti come se fossero l’unico criterio per utilizzare una funzionalità.

In realtà i crediti misurano il consumo.

L’accesso è un problema diverso.

Un utente potrebbe avere migliaia di crediti disponibili ma non avere il diritto di utilizzare una funzione premium.

Per questo motivo crediti ed entitlements devono essere gestiti separatamente.

Come viene implementato nelle piattaforme moderne 🏗️

Le applicazioni AI moderne tendono ad adottare un’architettura composta da diversi livelli specializzati.

Ogni componente ha una responsabilità precisa.

Il flusso tipico assomiglia a questo:

Pagamento
     ↓
Stripe Webhook
     ↓
Aggiornamento Crediti
     ↓
Aggiornamento Entitlements
     ↓
Access Control
     ↓
Utilizzo del Prodotto
     ↓
Usage Tracking
     ↓
Credit Ledger

Osservando questo schema si nota una cosa importante.

I crediti rappresentano soltanto una parte del sistema.

Per costruire una piattaforma affidabile servono anche:

• tracking
• permessi
• sincronizzazione eventi
• controlli di accesso

È proprio questa separazione delle responsabilità che permette alle piattaforme moderne di scalare senza accumulare debito tecnico.

Come Licenzy aiuta a gestire crediti AI 🛠️

Quando un team inizia a implementare un sistema di crediti AI, spesso pensa di dover semplicemente aggiungere un saldo nel database.

Con il tempo emerge però una realtà diversa.

Per costruire un sistema affidabile servono numerosi componenti che devono lavorare insieme:

• gestione dei crediti
• tracking del consumo
• usage ledger
• entitlements
• access control
• sincronizzazione con i pagamenti
• gestione dei webhook

È proprio questa categoria di problemi che piattaforme come Licenzy cercano di risolvere.

Invece di sviluppare internamente ogni componente, i team possono utilizzare API dedicate per gestire:

• AI Credits
• Usage-Based Billing
• Usage Tracking
• Entitlements
• Access Control

L’obiettivo non è sostituire la logica applicativa del prodotto, ma fornire l’infrastruttura necessaria per monetizzare applicazioni AI in modo affidabile e scalabile.

Conclusione 🎯

Sempre più prodotti AI stanno adottando modelli basati su crediti.

La ragione è semplice.

Consentono di collegare direttamente utilizzo, costi e ricavi.

Tuttavia, quando il numero di utenti cresce, emerge rapidamente una realtà che molti team scoprono sulla propria pelle:

vendere crediti è facile. Tracciarli correttamente è difficile.

Un sistema affidabile richiede molto più di un saldo associato a un utente.

Richiede:

• credit balances
• usage tracking
• usage ledger
• top-up
• entitlements
• access control
• sincronizzazione dei pagamenti
• gestione degli eventi

Più il prodotto cresce, più questi elementi diventano importanti.

Ed è proprio per questo che le piattaforme AI moderne trattano i crediti come una parte fondamentale dell’infrastruttura del prodotto, e non come una semplice funzionalità di billing.