Trasforma le email in fatturato con Brew.
Confronta le integrazioni Stripe di Brew, Sequenzy, Loops e Customer.io: eventi, dati di fatturazione sincronizzati, configurazione e idoneità ai promemoria.

Questo confronto è pubblicato da Brew. Il 28 settembre 2026 abbiamo esaminato la documentazione dei prodotti indicata nei link: si tratta di un confronto basato sulla documentazione, non di un test pratico di ogni piattaforma. Controlla i limiti attuali dei piani sulla pagina dei prezzi di ciascun fornitore.
Al rinnovo, la carta di un cliente viene rifiutata e Stripe invia invoice.payment_failed (la fattura resta aperta). Il tuo strumento email avvia il flusso di promemoria per il pagamento. La mattina dopo il cliente aggiorna la carta, ma quel pomeriggio il secondo promemoria parte comunque.
Molte piattaforme email dichiarano una “integrazione con Stripe”. Dietro quell’etichetta, però, le integrazioni funzionano in modi diversi. Uno strumento ascolta i webhook grezzi di Stripe e sincronizza il piano e lo stato dell’abbonamento di un cliente. Un altro trasforma l’attività di fatturazione in nomi di evento propri. Un terzo ti dà una guida per collegare i webhook in autonomia.
Sono queste differenze a decidere se un promemoria di fine prova può verificare lo stato della prova, e se un follow-up sul pagamento non riuscito si ferma quando la carta torna a funzionare. Questa guida confronta quattro piattaforme su questi punti.
saas.purchase e saas.payment_failed.Il 28 settembre 2026 abbiamo verificato la documentazione su Stripe di ogni fornitore e abbiamo confrontato:
| Strumento | Collegamento | Eventi | Dati di fatturazione sul contatto | Interruzione di un flusso |
|---|---|---|---|---|
| Brew | OAuth; Brew registra il webhook per te | 22 eventi Stripe su checkout, clienti, abbonamenti, fatture, preventivi e pagamenti | stripe_subscription_status, stripe_subscription_plan, stripe_plan_amount_cents, stripe_trial_end, stripe_renews_at, stripe_delinquent |
Condizioni esplicite sui campi sincronizzati del contatto; verifiche lato applicazione per una specifica fattura non pagata |
| Sequenzy | OAuth | Eventi del ciclo di vita SaaS ricavati da Stripe | MRR, LTV e tag come trial, past-due, churned |
Una condizione di interruzione per sequenza, per esempio su saas.purchase |
| Loops | Connect to Stripe nelle impostazioni | Più di 20 eventi Stripe, comprese le contestazioni | Email, nome e cognome | Ramificazioni dei workflow |
| Customer.io | Una guida alle campagne attivate da webhook | Gli eventi che gli invii | Qualsiasi dato tu mappi | Condizioni delle campagne |
Brew si collega tramite un flusso OAuth di Stripe Apps, quindi non vede mai le tue chiavi API. Poi registra da solo il webhook e si iscrive a 22 tipi di evento:
checkout.session.completed, più gli eventi di pagamento asincrono riuscito e non riuscito.trial_will_end, eliminato.payment_failed, imminente.charge.refunded, refund.created, payment_intent.payment_failed.Ogni evento verificato avvia tutte le automazioni attive che lo usano. Gli eventi su clienti e abbonamenti, inoltre, creano o aggiornano il cliente Stripe nel tuo pubblico, con campi stripe_* su cui puoi filtrare. Il pulsante “Sincronizza i clienti da Stripe” importa in background i clienti Stripe esistenti; se l’importazione si interrompe, può riprendere.
Nell’email puoi usare merge tag come amount, currency, invoiceNumber, previousPlan e newPlan, failureMessage e declineCode. I payload escludono di proposito gli ID degli oggetti Stripe, quindi non puoi usarli come merge tag o filtri.
Brew riceve gli eventi: non può ritentare un addebito, emettere un rimborso o modificare un abbonamento. Dopo un nodo Attesa, una condizione su contact.stripe_subscription_status legge il valore attuale del campo sul contatto di Brew, mentre i campi dell’evento conservano il payload originale. Questa lettura del contatto non interroga Stripe e non dimostra che una certa fattura sia stata pagata. Verifica quella fattura nella tua applicazione prima di inviare l’evento di un successivo promemoria di pagamento. Gli aggiornamenti del contatto e i nuovi eventi non annullano automaticamente le esecuzioni già in corso. Consulta la guida alle automazioni.
Brew, inoltre, progetta e invia le email. Le email sui pagamenti e sulle prove usano il design system del tuo brand e partono dal tuo dominio verificato, quindi non ti serve uno strumento separato per i modelli.
L’integrazione con Stripe di Sequenzy si collega tramite OAuth. Prima di sincronizzare per la prima volta, scegli quali prodotti includere e quali metadati riportare. Poi Sequenzy traduce l’attività di fatturazione in eventi del ciclo di vita SaaS, tra cui acquisti, inizio e fine della prova, disdetta, churn, pagamento non riuscito, upgrade, downgrade e rimborso.
I contatti ricevono MRR e LTV come attributi numerici, più tag di stato come customer, trial, past-due e churned. Ogni sequenza ha una condizione di interruzione, verificata prima di ogni passaggio, quindi una sequenza per la prova può interrompersi con l’evento saas.purchase senza filtri aggiuntivi.
Sequenzy abbina i contatti solo in base all’email. Esclude dalla sincronizzazione dei ricavi le sessioni di Checkout degli ospiti, cioè quelle senza un cliente associato.
Sequenzy fa al caso dei team SaaS che vogliono stati del ciclo di vita degli abbonamenti pronti all’uso e non hanno bisogno dei nomi originali degli eventi di Stripe.
Loops si collega dalle impostazioni (Settings) con Connect to Stripe. Sincronizza email, nome e cognome. Crea un contatto se l’email è nuova, e con customer.deleted può annullare l’iscrizione dei contatti o eliminarli. Più di venti eventi possono avviare i workflow, tra cui eventi su clienti, abbonamenti, fatture, checkout e preventivi, oltre a charge.dispute.created e charge.dispute.closed. Ad aprile 2026 Loops ha aggiunto altri eventi sugli abbonamenti.
Loops elabora solo gli eventi che contengono un indirizzo email. La sua documentazione non elenca il piano o lo stato tra le proprietà sincronizzate, quindi per le condizioni sullo stato della fatturazione servono dati da un’altra fonte.
Customer.io documenta Stripe come uno schema da costruire da te. Indirizzi i webhook di Stripe verso una campagna attivata da webhook, trovi la persona in base all’email e imposti come suo ID l’ID cliente di Stripe. Da lì puoi modellare tutti i dati di fatturazione che vuoi e usarli su email, SMS e push. Richiede più configurazione rispetto alle altre tre, ma ti dà più controllo sul modello di dati.
Stripe Billing può inviare email ai clienti direttamente. Può inviare un avviso dopo ogni pagamento con carta non riuscito, un promemoria sette giorni prima della fine di una prova gratuita, promemoria di rinnovo e un avviso un mese prima che scada la carta predefinita. Queste email rimandano a una pagina in cui il cliente può aggiornare il metodo di pagamento.
Se le attivi e crei anche un flusso in Brew o in Loops su invoice.payment_failed, i clienti ricevono due email per lo stesso pagamento non riuscito. Decidi quale sistema invia ciascun messaggio. Una possibile divisione: lasci a Stripe il link per aggiornare il pagamento e usi la tua piattaforma email per la spiegazione e il follow-up. Verifica che il link che inserisci nelle tue email sia ancora valido.
| Se vuoi… | Valuta |
|---|---|
| Eventi Stripe grezzi, campi di fatturazione sincronizzati ed email progettate e inviate in un unico prodotto | Brew |
| Eventi del ciclo di vita SaaS e condizioni di interruzione integrate | Sequenzy |
| Una piattaforma email semplice per SaaS, con un’ampia copertura degli eventi Stripe | Loops |
| Il pieno controllo del modello di dati su più canali | Customer.io |
Per gli abbonamenti: customer.subscription.trial_will_end, invoice.payment_failed, invoice.paid, customer.subscription.updated e customer.subscription.deleted. Stripe invia trial_will_end tre giorni prima della fine di una prova, oppure subito se la prova viene accorciata.
Inviano le email. I nuovi tentativi di pagamento e gli aggiornamenti della carta avvengono in Stripe. La documentazione di Brew precisa che la piattaforma non può creare addebiti né modificare abbonamenti.
Per le email di marketing, sì. La documentazione di Brew su Stripe precisa che sincronizzare i dati di un contatto non dà il permesso di inviargli email. Ricevute e avvisi di pagamento relativi a un abbonamento esistente rientrano in un’altra categoria. Approfondisci le email transazionali.
Non in modalità test di Stripe: Brew collega account Stripe in modalità live, e gli eventi in modalità test non sincronizzano i contatti né avviano automazioni. Lascia l’automazione in bozza e testala con destinatari sotto il tuo controllo. La documentazione di Loops suggerisce di creare clienti di test o di inviare eventi con il comando trigger della CLI di Stripe.
Per i dettagli lato Brew, leggi la pagina dell’integrazione con Stripe, poi crea un flusso in bozza e testalo con destinatari sotto il tuo controllo prima di pubblicarlo.
