> ## Documentation Index > Fetch the complete documentation index at: https://docs.mattone.co/llms.txt > Use this file to discover all available pages before exploring further. # Stripe dello studente vs fatturazione Conduit: due cose diverse > Disambiguazione: lo Stripe che lo studente collega serve agli EXTRA in chat e al checkout del sito, non ha niente a che fare con quanto lo studente paga a Mattone per il Servizio AI Ospiti. Cosa conta come struttura fatturabile, da quando, e dove si vede. **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 | | **A · Stripe dello studente** | **B · Fatturazione Conduit (canone)** | | - | - | - | | **Cos'è** | La chiave Stripe (Restricted Key) che lo studente collega dal SUO account Stripe | L'abbonamento con cui **Mattone fattura lo studente** per il Servizio AI Ospiti | | **Chi incassa** | **Lo studente**, sul suo conto Stripe | **Mattone**, su un conto Stripe di Mattone | | **A cosa serve** | Link di pagamento per **extra/upsell in chat** (parcheggio, late checkout, danni) + checkout del sito **direct booking** | Il **canone mensile** del servizio (assistente AI che risponde agli ospiti) | | **Dove si collega** | app.mattone.co → **Connessioni → Stripe** (lo studente incolla la sua chiave) | Nessun collegamento da parte dello studente: è **Mattone** che crea il Customer/Subscription Stripe sul proprio conto, lo studente aggiunge solo il **metodo di pagamento** (carta) | | **Dove si vede lo stato** | Card "Connessioni" della piattaforma | Sezione **Amministrazione/Documenti** dello studente (fattura, stato pagamento) + card admin "Conduit Billing" | | **Riferimento in questa guida** | [Stripe: pagamenti dello studente](/integrazioni/stripe/panoramica) | Questa pagina + [Mancato pagamento](/delivery/mancato-pagamento) | 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](/integrazioni/conduit/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](/integrazioni/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"](#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](/integrazioni/conduit/consumi). * **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](/delivery/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. Punto A: cosa incassa lo studente La scala di solleciti e sospensione del canone Come si riduce l'operatività per morosità This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.