Stripe Billing vs RevenueCat: quando vince ciascuno nel 2026

Il billing SaaS nel 2026 impone una scelta che cinque anni fa non esisteva. Stripe Billing gestisce il livello di ricavi ricorrenti per la maggior parte dei SaaS web. RevenueCat gestisce lo stesso livello per la maggior parte degli abbonamenti iOS e Android, e ora arriva sul web tramite Web Billing. I due prodotti risolvono lo stesso problema da estremi opposti, e scegliere quello sbagliato al primo mese significa riscrivere lo stack di billing al dodicesimo.

Questo articolo confronta i due sulle dimensioni che decidono davvero la scelta: copertura di piattaforma, struttura delle commissioni, cosa scrivi e cosa colleghi, e come ciascuno scala quando vai cross-platform. Chiariamo anche la confusione di nomi tra "Stripe Subscriptions" e "Stripe Billing" che continua a confondere i team nuovi.

TL;DR: chi sceglie cosa

Scegli Stripe Billing se il prodotto vive sul web (dashboard browser, SaaS B2B, marketplace). Ottieni l'elaborazione pagamenti più solida, la più ampia copertura di metodi di pagamento, metering usage-based maturo, e una commissione di billing dello 0,7% sopra il classico 2,9% + 0,30 dollari per transazione.

Scegli RevenueCat se il prodotto vive in un'app mobile dove Apple e Google ti costringono a passare dai loro binari di In-App Purchase. RevenueCat si appoggia su Apple StoreKit e Google Play Billing, normalizza le differenze, ti dà entitlement cross-platform, e aggiunge analytics che i team mobile non possono ottenere dai soli report di Apple o Google. È gratis fino a 2.500 dollari di ricavi tracciati mensili, poi 1% sul resto.

Scegli entrambi se distribuisci lo stesso abbonamento su web e su mobile. Stripe gestisce gli acquisti web. RevenueCat gestisce gli acquisti mobile. Un singolo record utente riconcilia gli entitlement tra i due.

La confusione di nomi: Stripe Subscriptions e Stripe Billing sono lo stesso prodotto

"Stripe Subscriptions" non è più un prodotto separato. La tassonomia attuale di Stripe usa Stripe Billing come nome ombrello per tutto ciò che riguarda i ricavi ricorrenti: oggetti subscription, fatturazione, customer portal, Entitlements API, metering usage-based, gestione tasse. Il termine "Stripe Subscriptions" gira ancora nei vecchi documenti e nelle risposte StackOverflow, ma la documentazione attuale di Stripe standardizza su Billing.

L'implicazione pratica: se un vendor ti propone "Stripe Subscriptions" come se fosse un tier separato più economico, sta ripetendo terminologia obsoleta o vendendo qualcosa che Stripe non offre. Il pricing di Stripe Billing è un numero solo, applicato uniformemente a tutto lo stack subscription.

Confronto a colpo d'occhio

Stripe Billing

• Superficie principale: web, SaaS B2B, marketplace.
• Binari di pagamento: Stripe Payments (carte, ACH, SEPA, wallet, oltre 20 metodi).
• Commissione di piattaforma: 2,9% + 0,30 dollari per transazione (carte USA).
• Commissione del livello billing: 0,7% del volume di billing, piatta su tutti i tier da luglio 2024.
• Metering usage-based: nativo, con ingestione di eventi in real time e pricing tiered o graduated.
• Customer portal: hosted, già pronto, permette agli utenti di fare upgrade, downgrade, pausa, cancel.
• Entitlement cross-platform: riconciliazione manuale nel tuo backend.
• Tasse: Stripe Tax, +0,5% sulle vendite tassate.

RevenueCat

• Superficie principale: iOS, Android, di recente anche web (Paddle o RevenueCat Web Billing).
• Binari di pagamento: Apple In-App Purchase, Google Play Billing, opzionalmente web via Paddle.
• Commissione di piattaforma: dal 15% al 30% ad Apple o Google, secondo l'idoneità allo Small Business Program.
• Commissione del livello billing: gratis fino a 2.500 dollari di MTR, poi 1% sul resto.
• Metering usage-based: limitato ai consumables; non è il caso d'uso.
• Paywall: hosted, layout server-driven aggiornabili da dashboard senza una nuova build App Store.
• Entitlement cross-platform: nativi, singolo record utente, singola API.
• Tasse: Apple e Google incassano e versano, RevenueCat fa report.

Dove vince Stripe Billing

SaaS web con pricing per posto o usage-based

Se i clienti si abbonano via dashboard web e fatturi per posto, per richiesta, per gigabyte o per qualsiasi altra unità misurata, Stripe Billing è la strada con meno attrito. La API usage-based billing ingerisce eventi in real time, supporta pricing tiered e graduated, e ti dà tutto quello che serve per spedire un SaaS metered senza costruire il tuo meter. Abbiamo trattato l'implementazione in il nostro articolo sul pricing usage-based.

Copertura più ampia di metodi di pagamento

Stripe processa carte, addebiti diretti ACH, SEPA, BACS, iDEAL, Bancontact, Klarna, Apple Pay, Google Pay e altri venti metodi. Per SaaS B2B che vendono a livello internazionale, l'ampiezza dei metodi accettati è direttamente correlata alla conversione. RevenueCat tramite Apple o Google eredita i metodi che quelle vetrine accettano in ciascun paese, ed è una copertura più stretta.

Take rate più basso quando vai web-first

I conti: Stripe prende il 2,9% + 0,30 dollari di processing più lo 0,7% di billing, totale circa 3,6% su un abbonamento mensile da 50 dollari. Apple e Google prendono il 15% (Small Business Program, sotto 1 milione di dollari annui) o il 30% sopra quella soglia, e RevenueCat aggiunge l'1% in cima. Un abbonamento mobile da 50 dollari che passa dall'App Store ti costa dal 16% al 31% di commissioni. Il web è drasticamente più economico per gli stessi ricavi.

Entitlements API per il feature gating

L'Entitlements API di Stripe dice alla tua applicazione a quali feature un cliente ha attualmente diritto, in base allo stato del suo abbonamento. Smetti di scrivere a mano logica tipo "if plan == 'pro' then show feature X" nel codice. Stripe tiene la fonte di verità, l'applicazione la legge.

Fatturazione e dunning maturi

Smart Retries, promemoria di pagamento, pagine fattura hosted e customer portal coprono la parte noiosa dei ricavi ricorrenti. Tre anni di investimento composto sul flusso di dunning si traducono in 1-3 punti percentuali di churn involontaria recuperata rispetto a un'implementazione fatta in casa.

Dove vince RevenueCat

Apple e Google ti costringono a passare dai loro binari

Se il tuo prodotto è un'app iOS o Android scaricabile e vendi abbonamenti al suo interno, le App Store Review Guidelines di Apple richiedono In-App Purchase. Google Play ha regole equivalenti. Aggirarle ti fa rifiutare o rimuovere l'app. Stripe non risolve questo, perché Stripe non è il binario. RevenueCat è il livello che sta sopra StoreKit e Play Billing e li rende tollerabili da integrare.

Entitlement cross-platform out of the box

Un utente compra il tuo abbonamento su iOS, apre l'app web sul portatile, poi apre l'app Android una settimana dopo. Senza RevenueCat scrivi la riconciliazione tra tre identificatori diversi (ricevuta Apple, purchase token Google, il tuo user id), gestisci i webhook di ciascuna piattaforma, e memorizzi lo stato di entitlement risultante. RevenueCat lo fa per te ed espone un'unica API: "questo utente ha diritto alla feature X in questo momento?"

Gratis finché non hai ricavi significativi

Il tier gratuito di RevenueCat copre fino a 2.500 dollari di ricavi tracciati mensili. Per un'app mobile in fase iniziale è circa i primi 250 utenti paganti a 10 dollari al mese. Non paghi nulla finché non superi quella soglia, poi 1% di MTR dopo. Stripe applica la sua commissione dello 0,7% dal primo dollaro.

Paywall server-driven

Il paywall builder di RevenueCat ti permette di cambiare testi, layout, blocchi di pricing e CTA da una dashboard. L'app mobile legge il layout a runtime. Puoi fare A/B test sui paywall senza spedire una nuova build App Store, che è l'unico modo realistico di iterare in fretta sui paywall in iOS.

Copertura web senza ricostruire

Dal 2025 RevenueCat distribuisce un Web SDK e Web Billing, con Paddle come opzione di binari. Se parti mobile-first, puoi aggiungere un flusso di acquisto web senza tirare su Stripe Billing in parallelo. Il trade-off: l'elaborazione pagamenti web via Paddle è più stretta di quella di Stripe, e Paddle prende la sua fetta.

Dove la scelta si fa più difficile: SaaS cross-platform

Il caso più difficile è il SaaS che spedisce su web E su mobile, con un singolo abbonamento che segue l'utente attraverso le superfici. Esistono tre opzioni:

1. Stripe ovunque, scarica il billing mobile altrove. Funziona solo fuori dall'ecosistema Apple. Le linee guida di Apple bloccano la vendita in-app di abbonamenti digitali tramite qualsiasi binario non IAP. Puoi comunque spedire l'app iOS e dirottare gli utenti a un flusso d'acquisto web, ma l'esperienza in-app risulta degradata.
2. RevenueCat ovunque. Paghi 1% di MTR più le commissioni Apple o Google su mobile, più le commissioni Paddle su web. Singola API per gli entitlement. Più veloce da spedire cross-platform.
3. Stripe sul web, RevenueCat sul mobile. Migliore economia totale. Scrivi tu il livello di riconciliazione tra i due contro un singolo record utente. Lo vediamo soprattutto in SaaS maturi dove il team ha già un backend che mappa utenti a entitlement.

Per la maggior parte dei team la risposta dipende da quale piattaforma genera più ricavi. Se l'80% dei ricavi è web, Stripe ovunque con un sottile flusso mobile che rimanda al checkout web. Se l'80% è mobile, RevenueCat ovunque. Il caso 50/50 è raro e quasi sempre risolto con il dual stack.

Cosa usiamo noi e perché

La maggior parte dei SaaS che costruiamo in Studio sono web-first. Defaultiamo a Stripe Billing per il livello di ricavi ricorrenti, Stripe Tax per IVA e sales tax, e Entitlements API per il feature gating. La combinazione copre il 95% del billing SaaS B2B senza codice custom.

Per prodotti con un companion mobile che vende abbonamenti dentro l'app, mettiamo RevenueCat sul lato mobile e riconciliamo gli entitlement server-side contro un singolo record utente. Non abbiamo ancora spedito un progetto su RevenueCat Web Billing in produzione. La dipendenza da Paddle aggiunge un vendor che non avevamo bisogno di aggiungere, e la superficie di pagamenti web di Stripe resta più ampia.

L'eccezione: prodotti puramente mobile-first senza superficie di acquisto web. Lì, RevenueCat dal giorno uno rimuove il debito "poi vediamo come fare cross-platform". Il giorno uno è quando quella decisione costa poco. Il dodicesimo mese è quando costa tre settimane di refactoring.

L'albero decisionale, condensato

• SaaS solo web, B2B o B2C: Stripe Billing.
• App solo mobile con abbonamenti in-app: RevenueCat.
• Ricavi web dominanti, companion mobile: Stripe sul web, RevenueCat sul mobile, riconciliazione server-side.
• Ricavi mobile dominanti, companion web: RevenueCat ovunque, accetta la fetta Paddle sul web.
• Non sai ancora quale lato dominerà: spedisci Stripe Billing per primo se hai un'app web, RevenueCat per primo se hai un'app mobile, rimanda la decisione cross-platform finché non hai dati.