Trigger emails from Stripe

Connect Stripe through OAuth to start branded emails when a subscription starts, a trial approaches its end, or an invoice payment fails. Brew registers the webhook and makes supported events available as automation triggers.

Stripe remains responsible for payments, retries, refunds, and subscription changes. Brew creates and sends the emails.

• Trial reminders: use the customer.subscription.trial_will_end event to explain what happens next and link to your plan or billing page.
• Failed-payment notices: use the invoice.payment_failed event to send a timely notice with a link to your own billing page. Coordinate with the customer emails Stripe sends, so the same notice does not go out twice.
• Subscriber welcome emails: start from the customer.subscription.created or checkout.session.completed event, choosing one trigger to avoid duplicate welcomes.
• Plan-change emails: the customer.subscription.updated event can supply the previousPlan and newPlan fields when the event includes them.
• Payment confirmations: invoice.paid fires when an invoice is paid. Use amount, currency, and invoiceNumber as merge tags.
• Renewal heads-ups: invoice.upcoming fires before Stripe creates the next invoice for a subscription and carries amount and currency. Its payload has no renewal date, so link to your billing page for the details.
• Cancellation follow-ups: customer.subscription.deleted fires when a subscription is canceled or deleted. A new subscription does not stop a run already in progress, so add a condition on contact.stripe_subscription_status before each later email.
• Pause and resume notices: customer.subscription.paused and customer.subscription.resumed confirm the change to the subscriber.
• Delayed payment results: checkout.session.async_payment_succeeded and checkout.session.async_payment_failed report how a delayed payment method settled after checkout. paymentStatus and sessionMode are available as merge tags.
• Abandoned-checkout reminders: Brew has no trigger for expired Checkout sessions. Fire your own custom event when your application sees a session expire.
• Refund confirmations: refund.created carries refundAmount, refundCurrency, refundReason, and refundStatus for the specific refund. charge.refunded carries only charge-level totals such as amountRefunded.
• Quote follow-ups: quote.finalized, quote.accepted, and quote.canceled carry the quote amount, currency, and status. There is no quote link field, so point the buyer to your own page.
• One-time payment failures: payment_intent.payment_failed carries failureCode, failureMessage, and declineCode, so the email can reflect why the payment failed.

Start with one email triggered by the invoice.payment_failed event. For a later reminder, have your application schedule a fresh invoice-status check in Stripe. Fire a separate Brew custom event only if the invoice remains unpaid and the customer is still eligible.

After a Wait, event fields still contain the original event payload. A contact.stripe_subscription_status condition reads the field’s current value on the Brew contact when that node runs. It does not query Stripe or prove that a particular invoice was paid. Contact updates and new payment events do not automatically cancel an earlier run. Updating a card is also not proof of payment.

Test both paths: a customer whose invoice is still unpaid, and who is still eligible, gets the reminder; a customer who pays before the scheduled check does not. Test retries with the documented idempotency contract.

• Open Integrations, choose Stripe, and select Connect. Authorize access through Stripe OAuth.
• Brew provisions the webhook and 22 supported event types. There is no event enable/disable switch.
• To import existing customers, open Stripe accounts on the integration page and choose Sync customers from Stripe. A customer record alone does not establish consent for marketing email.
• Create an automation and select its Stripe event. Review the recipient, payload fields, email content, and billing links.
• Brew connects live Stripe accounts, and test-mode events don’t sync contacts or start automations. Keep the automation a draft and test it with controlled recipients before publishing. Only Live automations execute when a matching event arrives.
• An agent can create, test, and publish automations through Brew MCP or the API after an authorized person connects the Stripe account in the app.

Brew supports these 22 event types:

• checkout.session.async_payment_succeeded
• checkout.session.async_payment_failed
• checkout.session.completed
• customer.created
• customer.updated
• customer.deleted
• customer.subscription.created
• customer.subscription.updated
• customer.subscription.paused
• customer.subscription.resumed
• customer.subscription.trial_will_end
• customer.subscription.deleted
• invoice.created
• invoice.paid
• invoice.payment_failed
• invoice.upcoming
• quote.finalized
• quote.accepted
• quote.canceled
• charge.refunded
• refund.created
• payment_intent.payment_failed

Customer and subscription events can update Brew contacts with billing context. Available contact fields include stripe_subscription_status, stripe_subscription_plan, stripe_plan_amount_cents, stripe_trial_end, stripe_renews_at, stripe_cancel_at_period_end, and stripe_delinquent. Availability depends on the Stripe event and data received.

Use the selected event's declared payload schema for merge tags. Depending on the event, fields include firstName, lastName, amount, currency, status, invoiceNumber, previousPlan, newPlan, and failureMessage. Monetary amounts are in cents where the schema specifies cents.

Stripe object identifiers are stripped from automation payloads. Do not assume invoice or subscription IDs can be used as merge tags. Brew does not store the Stripe customer ID on the contact either.

The per-event Sync full name setting controls whether Stripe can update the contact’s name. It does not enable or disable a trigger.

A later payment event does not automatically cancel a run started by an earlier failure. Schedule an application-side check before the reminder, and fire a new event only while the invoice is still unpaid.

Receiving an event and sending an email are separate steps. Confirm a matching automation is Live, inspect its filters and execution history, and check recipient eligibility and the sending domain. The Sync full name setting only controls name updates.

• Brew cannot create charges, issue refunds, or modify Stripe subscriptions.
• If an event appears on the Events tab under Stripe accounts but no email arrives, check the bound automation is Live, its filters and execution history, the recipient, and sending-domain readiness.
• For persistent webhook signature errors, reconnect Stripe to provision a fresh webhook secret.
• Use the refund.created event when the email needs refund-specific fields; confirm the available fields in the trigger schema.
• Review consent and the purpose of each email. Importing billing contacts does not authorize promotional sends.

• Build a Stripe lifecycle email workflow
• Compare Stripe email integrations
• Stripe setup guide
• Build an automation
• Merge tags
• Stripe event reference
• Stripe customer email settings