For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/modules/billing.md (or send Accept: text/markdown).
Fatturazione e accesso
Separa gli eventi di pagamento dalle decisioni di autorizzazione.
Scegli e testa il tuo servizio di pagamento
La fatturazione gestisce i pagamenti. Le autorizzazioni di accesso vengono archiviate separatamente come diritti. Completa la configurazione dell'account persistente, quindi apri /billing nell'app Web in esecuzione per visualizzare l'interfaccia del piano. Con BILLING_PROVIDER=local esplori il comportamento locale anziché raccogliere denaro reale.
Scegli un fornitore di servizi di pagamento supportato, segui la relativa guida di configurazione, crea il tuo prodotto e prezzo di prova e copia le impostazioni del server denominato in apps/web/.env.local. Salva e riavvia il server Web. Completa un checkout utilizzando le istruzioni sandbox del provider, quindi controlla lo stato di accesso dell'area di lavoro dopo l'arrivo del webhook del provider. Un webhook è il messaggio firmato dal fornitore al tuo server relativo a un evento di pagamento.
Una pagina di successo da sola non sblocca funzionalità. Se il pagamento viene completato ma l'accesso rimane inattivo, controlla la consegna del webhook del provider e l'elaborazione degli eventi del tuo server prima di ripetere il pagamento. Testare anche la cancellazione e l'accesso scaduto. Gli acquisti tramite telefono utilizzano la configurazione separata RevenueCat/negozio, non questo pagamento Web.
Fatturazione web
L'applicazione Web supporta il fornitore di fatturazione selezionato con BILLING_PROVIDER; La striscia è un'opzione. Apertura/fatturazione per piani Web e gestione abbonamenti. Segui la guida del fornitore selezionato per impostare le credenziali solo del server, gli ID prodotto o prezzo e le impostazioni di verifica del webhook nell'ambiente di test o live corrispondente.
Autorizza tramite i permessi
Un redirect di checkout non è prova di accesso attivo. Il permesso lato server decide se un workspace può usare una capacità a pagamento. Controlla quel permesso alla frontiera dell'azione anche quando l'interfaccia nasconde già l'azione.
Verifica il ciclo di vita
Usa gli eventi sandbox per verificare attivazione, aggiornamenti, cancellazione ed elaborazione dei webhook. Mantieni gli eventi ripetuti sicuri e assicurati che un permesso inattivo blocchi le operazioni a pagamento. Gli acquisti nativi mobile restano una frontiera di integrazione RevenueCat separata.
Per continuare la configurazione, leggi Configura l'email.