Skip to main content
In Conduit/Mattone esistono due cose diverse che si chiamano entrambe “Stripe” o “pagamenti”, ed è facile confonderle. Questa pagina esiste per separarle in modo esplicito, perché la confusione è già successa in team.

​
Le due cose

Sono indipendenti: uno studente può avere lo Stripe (A) collegato e vendere extra in chat senza che questo cambi in nulla quanto gli viene fatturato per il canone (B). E il canone (B) decorre anche se lo studente non ha mai collegato la sua chiave Stripe (A) — gli servono solo carta a file e contratto firmato.

​
B · Come funziona il canone

Il canone del Servizio AI Ospiti è un abbonamento ricorrente per struttura fatturabile (Listing), addebitato mensilmente sulla carta che lo studente aggiunge in piattaforma. Le condizioni esatte (importo, sconti, stato “Sospeso”) sono quelle dell’Addendum “Servizio AI Ospiti” firmato dallo studente — non le riscriviamo qui, si leggono nel contratto.

​
Cosa conta come “struttura fatturabile”

Una unità fatturabile = un Listing Conduit attivo (isActive: true), incluse le singole stanze listate separatamente su un OTA. Non conta:
  • un listing importato ma disattivato (isActive: false) — non pesa sul conteggio, si veda Right-sizing per come si disattiva;
  • i token/crediti di consumo (messaggi, chiamate) — quelli sono una voce separata, a parte dal canone (vedi sotto).
Due oggetti diversi contano come “unità” in punti diversi del sistema, e non sempre coincidono: le unità attive in questo momento (contate al volo su Conduit) e le unità con cui è stato effettivamente fatturato un mese già chiuso. Per i mesi passati conta la seconda, non la prima — altrimenti un listing tolto oggi sgonfierebbe anche l’arretrato di mesi in cui era ancora attivo.

​
Da quando parte il conteggio

Non c’è un “periodo di prova” a tempo. Il conteggio parte dalla data di attivazione, che è il giorno in cui il workspace dello studente viene visto per la prima volta con almeno un listing attivo. Per i workspace nuovi questa data si registra da sola al primo giro utile del sync automatico. Per i workspace già esistenti al momento in cui il billing è stato introdotto, la data di attivazione non viene indovinata: va confermata a mano da chi fa l’onboarding, proprio per non retrodatare un cliente attivo da mesi e cancellargli per errore l’arretrato dovuto.
Senza una data di attivazione registrata, il sistema non calcola nessun arretrato: preferisce non mostrare un numero piuttosto che inventarlo.

​
Il gate: senza contratto firmato, niente billing

Prima ancora della data di attivazione, c’è un blocco a monte: senza il contratto (Addendum) caricato e firmato, nessuna subscription si attiva e nessuna fattura si genera, qualunque sia il numero di listing attivi. È un controllo esplicito, non un effetto collaterale: il canone non “parte da solo” per un cliente che non ha ancora firmato.

​
Token e chiamate: fatturati a parte

Il canone copre l’assistente che risponde agli ospiti. I consumi (messaggi WhatsApp/SMS/email scritti dall’AI, chiamate vocali) sono una voce separata, fatturata a parte con scadenza propria — non entrano nel calcolo dell’abbonamento a listing. Chi guarda solo la subscription Stripe non vede questa parte: sta in un’altra riga, con logica di prezzo diversa (costo pass-through, non un multiplo del canone).

​
Cosa succede se disattivi un listing

Disattivare un listing (isActive: false) non è immediato sul conteggio: si fa a monte in KrossBooking (o nel PMS collegato), da dove si propaga a Conduit, e il conteggio che alimenta la fatturazione lo recepisce al giro successivo del sync automatico — non c’è proration nel ciclo in corso, la variazione vale dal ciclo successivo. Per la procedura completa di riduzione/ripristino (usata per la morosità, il right-sizing), vedi Conduit right-sizing.
Non risulta, ad oggi, un problema noto specifico di “toggle” che disallinei l’attivazione/disattivazione di un listing dal conteggio fatturabile. Se lo incontri, verificalo con Conduit ops prima di dare per scontato che il conteggio sia sbagliato: il ritardo di un ciclo (sopra) è comportamento atteso, non un bug.

​
Cosa succede quando arriva un workspace nuovo

Il registro interno che tiene traccia “quale workspace Conduit appartiene a quale studente” non si popola da solo per ogni caso. Il sync automatico prova a riconoscere ogni workspace che vede e a segnalarlo; ma se un workspace è stato aperto dallo studente su un proprio account Conduit — invece che nel percorso di onboarding standard di Mattone — può restare fuori dal raggio di quello che il sync riesce a vedere, e quindi non finire tracciato finché nessuno se ne accorge.
Un workspace non tracciato non significa “cliente non fatturabile per sempre”: significa solo che nessuno lo sta ancora seguendo. È già successo — un workspace con listing attivi e assistente in autopilot è rimasto fuori dal registro per settimane, scoperto solo da un dubbio manuale su un pagamento.
Come si verifica un gap del genere: si confronta l’elenco live dei workspace Conduit (via l’API/MCP Conduit) con le righe del registro interno. Ogni workspace live senza una riga corrispondente è un gap. Questo confronto può essere fatto a mano, oppure — quando il codice lo prevede — un giro periodico segnala via email al team i workspace mai visti prima, così il controllo non dipende da qualcuno che se ne accorge per caso. Cosa fare quando se ne trova uno: si crea la riga di tracciamento con solo i dati misurati (workspace, e — se si riesce a identificarlo — lo studente collegato tramite le sue altre integrazioni, non tramite il nome del workspace da solo: due clienti diversi possono avere nomi molto simili). contract_signed, la data di attivazione e le unità fatturate restano vuoti finché non sono confermati per davvero — vedi “Il gate: senza contratto firmato, niente billing” sopra: si applica anche qui. Non si fattura un cliente sulla fiducia di un nome che sembra corrispondere.

​
Chi fattura chi (il quadro completo)

Ci sono due rapporti di fatturazione in serie, non uno:
  1. Conduit → Mattone: Conduit fattura Mattone (tramite il proprio provider di billing) per il consumo aggregato di tutta la flotta degli studenti Mattone su un unico ordine condiviso, più gli ordini separati di Cosmica Italia e Cosmica Dubai.
  2. Mattone → studente: Mattone rifattura ogni singolo studente per il proprio canone (unità attive) più i propri consumi, su un abbonamento Stripe intestato a Mattone (non allo studente).
Lo studente non vede né si collega mai direttamente al primo rapporto: paga solo Mattone.

​
Crediti e consumi: cosa rispondere se uno studente chiede “quanto consumo e quanti crediti ho”

⚠️ Corretto il 29/09/2026 — la prima versione di questa sezione era sbagliata su un punto chiave. Diceva “ogni studente paga solo il suo consumo reale, slegato dagli altri”. Non è così: misurato sui dati reali, è un fondo di crediti condiviso da tutta la flotta studenti Mattone, non un’allocazione individuale. Il dettaglio sotto. Misurato (conduit_usage_snapshots, e confermato da un commento già nel codice, verificato il 21/08/2026 contro l’API Conduit): gli 8 workspace studenti Mattone condividono un solo ordine Salesbricks con un pool di 1.000 crediti comuni. remaining_credits è calcolato sul totale dell’ordine (non sul consumo del singolo workspace) ed è identico per tutti quelli sullo stesso ordine — oggi il pool risulta già negativo per più di un workspace. Cosmica Italia e Cosmica Dubai hanno invece ciascuna il proprio ordine separato, non mescolato con gli studenti. Quello che è tracciato per singolo workspace è credits_used (il consumo proprio di quel mese) — ma non esiste ancora un prezzo per convertirlo in una fattura: price_per_credit e monthly_price sono null nel sistema. La parte “Mattone rifattura ogni studente sui suoi consumi reali” descritta più sopra in questa pagina è quindi tracciata ma non ancora operativa lato prezzo.
Decisione di Francesco (29/09/2026): il pool condiviso è un problema reale da risolvere con Conduit, non da nascondere — l’obiettivo è passare da un pool unico di flotta a un’allocazione di default per sub-workspace (ordine di grandezza 1.000-10.000 crediti a testa), così un cliente pesante non intacca gli altri. Discorso da aprire con Conduit, non ancora chiuso.
Come rispondere a uno studente oggi, prima che il discorso con Conduit sia chiuso: non dire “paghi solo tu quello che consumi” (non è vero oggi). Meglio: “Il tuo consumo personale è tracciato regolarmente. Il pacchetto di crediti Conduit è oggi condiviso a livello di flotta Mattone — stiamo lavorando con il fornitore per garantire un’allocazione dedicata e sufficiente per tutti, ti aggiorniamo appena definito.” Non serve menzionare il saldo negativo o i dettagli interni dell’ordine condiviso: è materiale per il team, non per lo studente.

​
Come si misura il consumo, in pratica (già in produzione)

Per leggere i numeri senza confondere ordine e workspace: Come leggere i consumi Conduit.
  • Cron sync-conduit-usage (src/app/api/cron/sync-conduit-usage/route.ts, ogni 6 ore): per ogni workspace Conduit somma costo e token dei run del mese via API pubblica Conduit, più i dati piano/crediti da Salesbricks (credits_used, max_credits, remaining_credits, plan_tier). Scrive uno snapshot per workspace/mese in conduit_usage_snapshots. Se il consumo di un workspace supera alert_threshold_pct (default 90%) del suo plan_limit_usd, parte una mail al team.
  • Endpoint self-service già scritto: GET /api/conduit-billing/consumption/me (src/app/api/conduit-billing/consumption/me/route.ts) restituisce allo studente autenticato i crediti usati nel mese corrente e il costo stimato in EUR, con il testo esplicativo già pronto in CONSUMPTION_EXPLAINER (src/lib/conduit/billing-copy.ts): “Il canone di €9/appartamento copre l’assistente base, i Costi a Consumo sono a parte e pesano solo con tante chiamate vocali o volumi alti”. Questo testo va rivisto quando il discorso con Conduit sull’allocazione sarà chiuso, perché oggi non riflette il pool condiviso.
Gap noto (29/09/2026): l’endpoint /api/conduit-billing/consumption/me e il testo esplicativo esistono e funzionano, ma non sono agganciati a nessuna pagina della piattaforma — verificato cercando in tutta la UI (src/app). Oggi uno studente non ha un posto dove vedere il proprio consumo da solo: va fatto a mano da chi risponde al ticket, leggendo conduit_usage_snapshots o chiamando l’endpoint. Collegarlo a una pagina reale (es. dentro Documenti/Amministrazione) risolverebbe la domanda alla radice — ma solo dopo aver chiuso il discorso sull’allocazione con Conduit, altrimenti mostrerebbe un saldo condiviso che confonderebbe ancora di più.

​
Dove si vede lo stato, in pratica

  • Lo studente: sezione Documenti/Amministrazione → stato fattura, eventuale banner di sollecito (vedi Mancato pagamento), metodo di pagamento.
  • Il team: card admin “Conduit Billing” → modalità (Attivo/Esenzione/Sconto/Sospeso/Omaggio), unità attive, arretrato calcolato, contratto firmato o meno.
Fonti: repo mattone-platform (src/lib/conduit/billing.ts, src/lib/conduit/dunning.ts, src/lib/conduit/billing-copy.ts, src/app/api/cron/sync-conduit-usage, src/app/api/admin/conduit-billing/prepare, src/app/api/conduit-billing/consumption/me), Addendum “Servizio AI Ospiti” (contratto, non riprodotto qui). Gli importi esatti del canone sono nel contratto firmato dallo studente, non in questa pagina.

Stripe dello studente (extra in chat + sito)

Punto A: cosa incassa lo studente

Mancato pagamento

La scala di solleciti e sospensione del canone

Right-sizing

Come si riduce l’operatività per morosità