Stripe Checkout vs Billing Portal: chi fa cosa nel 2026

Stripe Checkout e il customer portal di Stripe Billing sono due pagine ospitate da Stripe che dividono a metà uno stesso lavoro. Checkout incassa il primo pagamento e avvia l'abbonamento. Il customer portal permette a un cliente già acquisito di gestire quell'abbonamento in seguito. Non sono in concorrenza. Sono la porta d'ingresso e la sala di controllo dello stesso sistema di fatturazione, e la decisione che manda davvero in confusione i team è dove tracciare il confine tra le due.

Se vendi un abbonamento SaaS, ti servono entrambe. Checkout è dove uno sconosciuto diventa cliente pagante. Il portal è dove quel cliente aggiorna la carta, scarica una fattura, cambia piano o disdice, senza scrivere alla tua casella di assistenza. Collegali bene e la fatturazione si gestisce da sola nei casi comuni. Collegali male e finisci per ricostruire pezzi che Stripe ti dà già gratis.

In breve: quale usare

Usa Checkout all'inizio del rapporto: dalla pagina prezzi al pagamento, una tantum o ricorrente. Usa il customer portal per tutto ciò che viene dopo il primo addebito: aggiornamento carta, cambi piano, fatture, disdette. La maggior parte dei prodotti SaaS chiama Checkout una volta per iscrizione e rimanda al portal da un solo pulsante "Gestisci fatturazione" nelle impostazioni account.

Stripe Checkout e customer portal a colpo d'occhio

Dove sta Stripe Checkout

Checkout è una pagina di pagamento pronta a cui mandi chi compra, oppure la incorpori sul tuo dominio, per incassare il primo pagamento. Copre carta, wallet, imposte, codici promozionali e prove, e può creare un addebito una tantum o aprire un abbonamento. Crei una Checkout Session a breve durata lato server, reindirizzi il cliente al suo URL e Stripe gestisce la parte sensibile ai fini PCI.

Contano due varianti. La versione ospitata reindirizza a una pagina su stripe.com. La versione incorporata tiene chi compra sul tuo dominio. Entrambe fatturano allo standard 2,9% più 30 centesimi senza costi aggiuntivi, e i Payment Links, il fratello no-code, seguono lo stesso listino. Se i prezzi sono fissi e vuoi zero codice, i Payment Links arrivano allo stesso risultato. Se ti servono righe d'ordine dinamiche, le Checkout Session ti danno il controllo. Abbiamo confrontato i livelli di billing in Stripe Billing vs RevenueCat.

Dove sta il customer portal

Il customer portal è una pagina ospitata da Stripe dove un cliente esistente gestisce la propria fatturazione: aggiorna il metodo di pagamento, vede e scarica le fatture, cambia piano, mette in pausa e disdice. La disdetta è attiva di default, e puoi raccogliere un motivo di disdetta o provare a trattenere il cliente con un coupon di retention.

Il dettaglio decisivo: il portal non autentica nessuno al posto tuo. La guida di Stripe è autenticare prima il cliente dalla tua parte, poi creare una sessione del portal per il suo customer ID con un return_url. Quella sessione è un URL a breve durata. Scade se non viene usato, e questo impedisce a un cliente di condividere un link che espone i controlli di fatturazione. Metti un pulsante "Gestisci fatturazione" dietro il tuo login, crei la sessione al clic e reindirizzi.

Puoi anche saltare il menu. Un flow è un deep link diretto a una sola azione, per esempio la pagina di disdetta o l'aggiornamento del metodo di pagamento, con la navigazione nascosta, così il cliente atterra esattamente sul compito per cui l'hai mandato.

Cosa il portal, di proposito, non può fare

È qui che la maggior parte degli articoli "usa entrambe" si ferma, ed è la parte che decide la tua architettura. Il portal è configurazione, non codice. Hai il brand e una serie di interruttori nella Dashboard, e quello è il tetto.

• Nessuna UI su misura. Non puoi ristrutturare le pagine né inserire componenti tuoi. Se il tuo flusso di disdetta richiede un sondaggio dedicato o un'offerta di salvataggio che il portal non esprime, lo costruisci via API.
• Il cambio piano si ferma a 10 prodotti. Quando lasci cambiare piano nel portal, puoi esporre al massimo 10 prodotti. Un catalogo grande lo supera.
• Non acquisisce clienti. Nel portal non c'è iscrizione. I nuovi clienti passano sempre prima da Checkout.
• Presuppone abbonamenti standard. Anteprime di proration complesse, preventivi, add-on o modifiche di consumo a metrica oltre le basi di solito richiedono schermate su misura basate sull'API Subscriptions.

La regola che usiamo: lascia al portal lo standard 80% del self-service di fatturazione, e costruisci UI su misura solo per i casi che non riesce a esprimere. Ricostruire a mano l'aggiornamento carta o lo storico fatture è lavoro sprecato.

Come colleghiamo le due

Lo schema è lo stesso su ogni SaaS che spediamo. All'iscrizione crei una Checkout Session, e ti assicuri che crei o riusi un customer Stripe, così l'abbonamento si aggancia a un ID stabile. Salvi quel customer ID sul record dell'utente. Da lì in poi, un solo pulsante "Gestisci fatturazione" nelle impostazioni account crea una sessione del portal per quell'ID e reindirizza.

Tratta i webhook di Stripe come fonte di verità, non il redirect. Quando un cliente cambia piano o disdice nel portal, lo scopri da customer.subscription.updated e customer.subscription.deleted, non dal browser che torna sul tuo return_url. Il return URL è un dettaglio di UX. Il webhook è il cambio di stato, e scatta anche se il cliente chiude la scheda. Per costi e tempi completi di questa integrazione, vedi Costi e tempi dell'integrazione Stripe.

Come funziona nella pratica

Un cliente sul piano da 29 dollari vuole quello da 99 a metà ciclo. Apre il portal dalle impostazioni account, sceglie il piano più alto e conferma. Stripe calcola il rateo della differenza, la addebita e scatena customer.subscription.updated. Il tuo gestore di webhook legge il nuovo price ID, aggiorna il piano nel database e sblocca le funzioni da 99 dollari. Di quella schermata di fatturazione non hai scritto nulla. Hai scritto un ramo di webhook.

La disdetta funziona allo stesso modo. Il cliente disdice nel portal, Stripe può mostrargli prima un coupon di retention e, alla conferma, ricevi customer.subscription.deleted, oppure un update con cancel_at_period_end impostato. Riduci l'accesso su quell'evento, non quando il browser torna indietro. Se il cliente non atterra mai di nuovo sul tuo return_url, lo stato resta comunque corretto.

Fatta così, Checkout e il portal coprono l'intero ciclo di vita dell'abbonamento con due pagine ospitate e un gestore di webhook. Scrivi quasi zero UI di fatturazione, e le parti che scrivi sono quelle che Stripe ha lasciato aperte apposta.