# Så automatiserar du livscykelmejl med prenumerationshändelser från Stripe

Kanonisk URL: https://brew.new/sv/blog/how-to-automate-lifecycle-emails-from-stripe-subscription-events
Författare: Philip Sørensen
Publicerad: 2026-09-18
Uppdaterad: 2026-09-29

Stripe genererar händelser när prenumerationer, fakturor och betalningar ändras. Händelserna kan starta användbara mejl, men varje meddelande behöver ändå en bestämd mottagare, ett syfte och en regel för att avgöra om det fortfarande är aktuellt.

[Stripe-integrationen](/sv/browse/integrations/stripe) i Brew sköter OAuth-anslutningen och konfigurationen av webhooken. Den här guiden handlar om hur du utformar mejlprogrammet som bygger på den. För flöden som startar från produkthändelser i stället för fakturering, läs [e-postautomatisering med AI](/sv/blog/ai-email-automation).

## Koppla en händelse till ett meddelande

| Mål | Möjlig händelse | Kontrollera före utskick |
| --- | --- | --- |
| Välkomna en prenumerant | `customer.subscription.created` | Undvik ett dubbelt välkomstmejl från kassan |
| Förklara att en provperiod tar slut | `customer.subscription.trial_will_end` | Det faktiska slutdatumet och om kunden kommer att debiteras |
| Meddela en misslyckad fakturabetalning | `invoice.payment_failed` | Aktuell faktura, faktureringslänk, aviseringar som Stripe redan skickar |
| Förklara ett planbyte | `customer.subscription.updated` | Vilka fält som ändrades och om ändringen spelar någon roll |
| Bekräfta en uppsägning | `customer.subscription.deleted` | När åtkomsten upphör och vad kunden bad om |
| Förklara en återbetalning | `refund.created` | Fält som är specifika för återbetalningen och finns i händelsen |

Använd [referensen för Stripe-händelser](https://docs.stripe.com/api/events/types) och schemat för den valda utlösaren i Brew. En uppdatering av en prenumeration kan stå för flera olika sorters ändringar; skicka inte ett mejl om planbyte vid varje uppdatering utan att kontrollera dess data.

## Anslut och publicera med eftertanke

Godkänn Stripe på sidan Integrationer i Brew. Brew registrerar webhooken och provisionerar utlösarna som stöds. Det finns inget reglage för att aktivera eller inaktivera händelser. Bara aktiva automatiseringar som är kopplade till händelsen körs.

Använd Synka kunder från Stripe om du behöver importera historiska kontakter. Att importera en faktureringskontakt innebär inte samtycke till marknadsföring. Inställningen Synka fullständigt namn, som finns för varje händelse, styr uppdateringar av namn, inte om mejl skickas.

Bygg den första automatiseringen som ett utkast, granska det genererade mejlet och testa med kontrollerade mottagare innan du publicerar. Följ [konfigurationsguiden för Stripe](https://docs.brew.new/integrations/import/stripe) för detaljer om anslutningen; Brew ansluter skarpa Stripe-konton, och händelser i testläge startar inga automatiseringar.

## Hantera en misslyckad betalning utan inaktuella påminnelser

En omedelbar avisering om misslyckandet kan starta från `invoice.payment_failed`. Förklara vad som hände och länka till din egen faktureringssida. Lova inte att Brew gör ett nytt debiteringsförsök; betalningarna sköts av Stripe.

För en påminnelse tre dagar senare låter du din applikation schemalägga en kontroll av fakturans status. Om fakturan fortfarande är obetald och kunden fortfarande uppfyller villkoren skickar du en separat påminnelsehändelse till Brew. Om betalningen har gått igenom avslutar du utan att skicka den.

Efter ett väntesteg innehåller händelsefälten fortfarande den ursprungliga nyttolasten. Ett villkor på `contact.stripe_subscription_status` läser det aktuella kontaktfältet i Brew när noden körs. Det frågar inte Stripe och bevisar inte att just den här fakturan har betalats. En senare händelse av typen `invoice.paid` avbryter inte automatiskt den äldre körningen. En uppdaterad betalningsmetod är inte heller något bevis på betalning.

Testa en betalning som går igenom före påminnelsekontrollen, en faktura som förblir obetald och ett jobb som körs om. Återanvänd en idempotensnyckel för samma logiska händelse inom det [dokumenterade fönstret för nya försök](https://docs.brew.new/api-reference/api/idempotency).

## Personalisera utifrån deklarerade fält

Brew kan synka faktureringsfält till kontakter, bland annat prenumerationsstatus och plan. Händelsernas nyttolaster och kontaktfälten är olika källor. Läs utlösarens schema innan du använder `amount`, `currency`, `invoiceNumber`, `previousPlan`, `newPlan` eller `failureMessage`; alla händelser innehåller inte alla fält.

Objekt-ID:n från Stripe utelämnas i automatiseringens nyttolast. Bygg inte en URL till kundportalen utifrån ett antaget faktura- eller prenumerations-ID. Använd din applikations faktureringssida bakom inloggning, eller en länk som du medvetet skickar med i en anpassad händelse. Följ [guiden om personaliseringstaggar](https://docs.brew.new/create-emails/merge-tags).

## Ge varje system ett ansvar

Gå igenom [Stripes inställningar för kundmejl](https://docs.stripe.com/billing/revenue-recovery/customer-emails). Bestäm vilket system som skickar kvitton, aviseringar om misslyckade betalningar och påminnelser. Att slå på en automatisering i Brew stänger inte av mejlen från Stripe.

Håll säljande innehåll borta från kontoaviseringar, om du inte har gått igenom meddelandets syfte och vilka samtycken som finns. Påminnelser i marknadsföringssyfte kräver motsvarande samtycke och hantering av avregistreringar.

## Kontrollera hela kedjan

Kontrollera att händelsen syns i Brew, att den kopplade automatiseringen är aktiv och att körningshistoriken visar rätt mottagare och utfall. Granska sedan det mottagna mejlet och faktureringslänken. Om en händelse kom in men inget meddelande skickades, kontrollera filter, spärrar och om avsändardomänen är redo innan du utgår från att webhooken misslyckades.

Börja med en händelse och ett testat mejl. Lägg till senare påminnelser först när kontrollerna av aktuell status och beteendet vid nya försök täcks av testerna för din applikation.