Ready to send better email?
Brew is the AI-native ESP. Define your brand once, ship on-brand email in minutes.
Brew is the AI-native ESP. Define your brand once, ship on-brand email in minutes.
Connect Stripe to Brew, choose the right billing events, and check current invoice or subscription state before sending later reminders.
Stripe emits events when subscriptions, invoices, and payments change. Those events can start useful emails, but each message still needs a defined recipient, purpose, and rule for deciding whether it is timely.
Brew's Stripe integration handles the OAuth connection and webhook setup. This guide covers how to design the resulting email program. For flows that start from product events instead of billing, see AI email automation.
| Outcome | Candidate event | Review before sending |
|---|---|---|
| Welcome a subscriber | customer.subscription.created |
Avoid a duplicate welcome from checkout |
| Explain a trial ending | customer.subscription.trial_will_end |
Actual deadline and whether a charge will occur |
| Report a failed invoice payment | invoice.payment_failed |
Current invoice, billing link, existing Stripe notices |
| Explain a plan change | customer.subscription.updated |
Which fields changed and whether the change matters |
| Acknowledge cancellation | customer.subscription.deleted |
When access ends and what the customer requested |
| Explain a refund | refund.created |
Refund-specific fields available in the event |
Use the Stripe event reference and the selected Brew trigger schema. A subscription update can represent several kinds of change; do not send a plan-change email for every update without checking its data.
Authorize Stripe in Brew's Integrations page. Brew registers the webhook and provisions supported triggers. There is no event enable/disable switch. Only Live automations bound to the event run.
Use Sync customers if you need to import historical contacts. Importing a billing contact does not establish marketing consent. The per-event Sync customer name setting controls name updates, not whether emails fire.
Build the first automation as a draft, inspect the generated email, and test with controlled recipients before publishing. Follow the Stripe setup guide for connection and test-mode details.
An immediate failure notice can start from invoice.payment_failed. Explain what happened and link to your own billing page. Do not promise that Brew will retry the charge; Stripe owns payment operations.
For a reminder three days later, have your application schedule an invoice-status check. If the invoice remains unpaid and the customer remains eligible, fire a separate Brew reminder event. If payment has recovered, finish without firing it.
After a Wait, event fields still contain the original payload. A condition on contact.stripe_subscription_status reads the current Brew contact field when that node executes. It does not query Stripe or prove that this particular invoice was paid. A later invoice.paid event does not automatically cancel the older run. Updating a payment method is not proof of payment either.
Test recovery before the reminder check, an invoice that remains unpaid, and a retried job. Reuse an idempotency key for the same logical event within the documented retry window.
Brew can sync billing fields onto contacts, including subscription status and plan. Event payloads and contact fields are different sources. Read the trigger schema before using amount, currency, invoiceNumber, previousPlan, newPlan, or failureMessage; not every event provides each field.
Stripe object IDs are omitted from the automation payload. Do not construct a customer portal URL from an assumed invoice or subscription ID. Use your application's authenticated billing page or a link deliberately supplied in a custom event. Follow the merge-tag guide.
Review Stripe's customer email settings. Decide which system sends receipts, payment-failure notices, and reminders. Turning on a Brew automation does not turn off Stripe email.
Keep promotional content out of an account notice unless you have reviewed the message's purpose and permissions. Marketing reminders require the corresponding consent and unsubscribe handling.
Confirm the event appears in Brew, the bound automation is Live, and its execution history shows the expected recipient and outcome. Then inspect the received email and billing link. If an event arrived but no message was sent, check filters, suppression, and sending-domain readiness before assuming the webhook failed.
Start with one event and one tested email. Add later reminders only when the current-state checks and retry behavior are covered by your application tests.
