# Come automatizzare le email del ciclo di vita con Stripe

URL canonico: https://brew.new/it/blog/how-to-automate-lifecycle-emails-from-stripe-subscription-events
Autore: Philip Sørensen
Pubblicato: 2026-09-18
Aggiornato: 2026-09-29

Stripe emette eventi quando cambiano abbonamenti, fatture e pagamenti. Questi eventi possono far partire email utili, ma ogni messaggio ha comunque bisogno di un destinatario definito, di una finalità e di una regola per decidere se è ancora il momento giusto per inviarlo.

L’[integrazione di Brew con Stripe](/it/browse/integrations/stripe) gestisce il collegamento OAuth e la configurazione del webhook. Questa guida spiega come progettare il programma di email che ne deriva. Per i flussi che partono da eventi di prodotto anziché dalla fatturazione, leggi [email automation con l’IA](/it/blog/ai-email-automation).

## Associa un evento a un messaggio

| Obiettivo | Evento candidato | Da verificare prima dell’invio |
| --- | --- | --- |
| Dare il benvenuto a un abbonato | `customer.subscription.created` | Evitare un benvenuto doppio dal checkout |
| Spiegare la fine di una prova | `customer.subscription.trial_will_end` | Scadenza effettiva e se ci sarà un addebito |
| Segnalare un pagamento della fattura non riuscito | `invoice.payment_failed` | Fattura attuale, link alla fatturazione, avvisi di Stripe già attivi |
| Spiegare un cambio di piano | `customer.subscription.updated` | Quali campi sono cambiati e se la modifica è rilevante |
| Confermare una disdetta | `customer.subscription.deleted` | Quando termina l’accesso e cosa ha chiesto il cliente |
| Spiegare un rimborso | `refund.created` | Campi specifici del rimborso disponibili nell’evento |

Usa il [riferimento degli eventi Stripe](https://docs.stripe.com/api/events/types) e lo schema del trigger di Brew selezionato. Un aggiornamento dell’abbonamento può rappresentare diversi tipi di modifica: non inviare un’email di cambio piano a ogni aggiornamento senza controllarne i dati.

## Collega e pubblica con criterio

Autorizza Stripe dalla pagina Integrazioni di Brew. Brew registra il webhook e configura i trigger supportati. Non esiste un interruttore per attivare o disattivare gli eventi. Vengono eseguite solo le automazioni attive associate all’evento.

Usa Sincronizza i clienti da Stripe se devi importare i contatti esistenti. Importare un contatto della fatturazione non costituisce un consenso all’email di marketing. L’impostazione Sincronizza il nome completo, per ogni evento, controlla gli aggiornamenti del nome, non se le email partono.

Crea la prima automazione come bozza, esamina l’email generata e, prima di pubblicare, testala con destinatari sotto il tuo controllo. Per i dettagli sul collegamento, segui la [guida alla configurazione di Stripe](https://docs.brew.new/integrations/import/stripe); Brew collega account Stripe in modalità live, e gli eventi in modalità test non avviano automazioni.

## Gestisci un pagamento non riuscito senza inviare promemoria superati

Un avviso immediato di mancato pagamento può partire da `invoice.payment_failed`. Spiega cosa è successo e inserisci un link alla tua pagina di fatturazione. Non promettere che Brew ritenterà l’addebito: le operazioni di pagamento sono di competenza di Stripe.

Per un promemoria tre giorni dopo, fai programmare alla tua applicazione una verifica dello stato della fattura. Se la fattura risulta ancora non pagata e il cliente è ancora idoneo, invia a Brew un evento separato per il promemoria. Se nel frattempo il pagamento è andato a buon fine, termina senza inviarlo.

Dopo un nodo Attesa, i campi dell’evento contengono ancora il payload originale. Una condizione su `contact.stripe_subscription_status` legge il valore attuale del campo sul contatto di Brew nel momento in cui quel nodo viene eseguito. Non interroga Stripe e non dimostra che proprio quella fattura sia stata pagata. Un evento `invoice.paid` successivo non annulla automaticamente l’esecuzione precedente. Anche l’aggiornamento di un metodo di pagamento non è una prova di pagamento.

Testa tre casi: il pagamento recuperato prima della verifica per il promemoria, una fattura che resta non pagata e un processo ripetuto. Riusa la stessa chiave di idempotenza per lo stesso evento logico entro la [finestra per i nuovi tentativi indicata nella documentazione](https://docs.brew.new/api-reference/api/idempotency).

## Personalizza partendo dai campi dichiarati

Brew può sincronizzare sui contatti i campi della fatturazione, tra cui lo stato e il piano dell’abbonamento. I payload degli eventi e i campi del contatto sono fonti diverse. Leggi lo schema del trigger prima di usare `amount`, `currency`, `invoiceNumber`, `previousPlan`, `newPlan` o `failureMessage`: non tutti gli eventi forniscono ogni campo.

Gli ID degli oggetti Stripe vengono rimossi dal payload delle automazioni. Non costruire l’URL di un portale clienti partendo da un presunto ID di fattura o di abbonamento. Usa la pagina di fatturazione della tua applicazione, protetta da autenticazione, o un link fornito apposta in un evento personalizzato. Segui la [guida ai merge tag](https://docs.brew.new/create-emails/merge-tags).

## Dai a ogni sistema una sola responsabilità

Controlla le [impostazioni delle email ai clienti di Stripe](https://docs.stripe.com/billing/revenue-recovery/customer-emails). Decidi quale sistema invia ricevute, avvisi di mancato pagamento e promemoria. Attivare un’automazione in Brew non disattiva le email di Stripe.

Non inserire contenuti promozionali in un avviso relativo all’account senza aver verificato la finalità del messaggio e i permessi. I promemoria di marketing richiedono il relativo consenso e la gestione delle disiscrizioni.

## Controlla l’intero percorso

Verifica che l’evento compaia in Brew, che l’automazione associata sia attiva e che la sua cronologia delle esecuzioni mostri il destinatario e l’esito previsti. Poi esamina l’email ricevuta e il link alla fatturazione. Se un evento è arrivato ma non è partito nessun messaggio, controlla filtri, esclusioni e che il dominio di invio sia pronto, prima di dare per scontato che il webhook non abbia funzionato.

Inizia con un solo evento e una sola email testata. Aggiungi i promemoria successivi solo quando le verifiche dello stato attuale e il comportamento dei nuovi tentativi sono coperti dai test della tua applicazione.