Make.com + Stripe: Automate Payment and Billing Workflows
Connect Stripe to Make.com in under 10 minutes and turn every payment event into an automated workflow — no code, no infrastructure, no manual follow-up.
Stripe handles the payment rail. Make.com handles everything else. When a subscription renews, an invoice fails, or a customer cancels, Make can automatically sync your CRM, send personalized emails, alert your team, and trigger win-back sequences — all triggered by Stripe webhooks in real time.
This tutorial covers four production-ready billing automation scenarios: processing Stripe webhook events, syncing subscription data to a CRM, automating dunning emails for failed payments, and running a churn prevention workflow.
Why Make.com + Stripe is the default billing automation stack
Stripe exposes every billing event as a webhook. Every subscription state change, payment attempt, invoice creation, and customer update fires a precisely structured JSON payload to any URL you provide. The problem is that raw webhooks require a server to receive them, code to parse them, and logic to route them — which means engineering time for every automation.
Make.com eliminates that. Its built-in Custom Webhook module acts as a zero-infrastructure receiver for Stripe events. Once the webhook URL is registered in Stripe, every event triggers a Make scenario that routes the data visually — no Express server, no Lambda function, no deployment pipeline.
| Approach | Setup Time | Requires Code | Maintenance |
|---|---|---|---|
| Custom server (Node.js / Python) | 2–4 hours | Yes | High |
| Zapier | 15 min | No | Low |
| Make.com | 10 min | No | Low |
| n8n (self-hosted) | 30 min | No | Medium |
Best for: SaaS founders, RevOps teams, and technical marketers who need production billing automations without dedicated engineering resources. If you need complex multi-branch conditional logic across more than 5 apps simultaneously, n8n's self-hosted model gives more flexibility.
Prerequisites
Before building any scenario, you need:
- A Make.com account (Free tier supports up to 1,000 operations/month)
- A Stripe account with at least one product and price object configured
- A CRM or email tool connected to Make (HubSpot, Mailchimp, ActiveCampaign, Airtable — any of Make's 3,000+ integrations work)
Make's free tier is sufficient to test all four scenarios below. For production usage at SaaS scale, Make's paid plans offer 10,000+ operations/month — see Make's pricing page for current rates.
Scenario 1: Receive and parse Stripe webhook events
This is the foundation every other scenario builds on. You'll configure a Make webhook URL as the Stripe endpoint and parse the incoming event payload.
Step 1: Create a Make Custom Webhook
- Open Make.com and create a new scenario.
- Add the Webhooks > Custom Webhook module as the trigger.
- Click Add to create a new webhook — Make generates a unique URL (e.g.,
https://hook.eu1.make.com/abc123...). - Click Copy address to copy the URL.
Step 2: Register the webhook in Stripe
- In your Stripe Dashboard, navigate to Developers > Webhooks.
- Click Add endpoint.
- Paste the Make webhook URL into the Endpoint URL field.
- Under Events to send, select the events relevant to your workflow. Start with these four:
payment_intent.succeededinvoice.payment_failedcustomer.subscription.deletedinvoice.created
- Click Add endpoint to save.
Step 3: Send a test event to detect the data structure
Back in Make, click Run once to put the webhook in "listening" mode. In Stripe Dashboard, click Send test webhook for the payment_intent.succeeded event. Make receives the payload and automatically detects the data structure.
The incoming JSON looks like this:
{
"id": "evt_1Nxxx",
"type": "payment_intent.succeeded",
"data": {
"object": {
"id": "pi_1Nxxx",
"amount": 4900,
"currency": "usd",
"customer": "cus_Pxxx",
"metadata": {
"user_id": "usr_789"
}
}
}
}
Make maps every field automatically. You can now reference {{data.object.customer}}, {{data.object.amount}}, and {{data.object.metadata.user_id}} in downstream modules.
Step 4: Add a Router for event type branching
Stripe sends all event types to a single endpoint. Use Make's Router module to branch on {{type}}:
- Route 1:
typeequalspayment_intent.succeeded - Route 2:
typeequalsinvoice.payment_failed - Route 3:
typeequalscustomer.subscription.deleted
Each route handles its own workflow independently.
Scenario 2: Sync new subscribers to your CRM
When a Stripe subscription is created or renewed, automatically create or update a contact record in your CRM.
Trigger: customer.subscription.created webhook event
Modules: Webhook → Stripe (Get Customer) → HubSpot (Create/Update Contact)
Build the flow
-
After the webhook trigger, add Stripe > Get a Customer and pass
{{data.object.customer}}as the Customer ID. This retrieves the full customer object including email and name. -
Add HubSpot > Create/Update a Contact (or your CRM equivalent). Map the fields:
| Make field | CRM field |
|---|---|
{{email}} | Email address |
{{name}} | Full name |
{{data.object.id}} | Stripe Subscription ID (custom property) |
{{data.object.status}} | Subscription status |
{{data.object.current_period_end}} | Next renewal date |
- Add a Slack > Create a Message module (optional) to notify your team channel when a new subscriber signs up.
Result: Every new Stripe subscriber has a live, up-to-date CRM record without any manual data entry.
Scenario 3: Automated dunning emails for failed payments
Failed payments are the leading cause of involuntary churn. Industry research consistently shows that a substantial share of monthly SaaS churn comes from declined cards and expired payment methods, not voluntary cancellations. Catching these early with a timed email sequence recovers a significant portion of otherwise-lost revenue.
Trigger: invoice.payment_failed webhook event
Modules: Webhook → Stripe (Get Customer) → Gmail/Mailchimp (Send Email) → HubSpot (Update Contact)
Build the dunning sequence
Email 1 — Immediate (0 minutes after failure):
Configure Make to send an email the moment the webhook fires. Subject line: "Action required: Your payment didn't go through". Body: direct link to Stripe's hosted payment update page ({{data.object.hosted_invoice_url}}).
Email 2 — Day 3 follow-up:
Use Make's Sleep module (or a scheduled secondary scenario) to delay 3 days. Send a second email with a softer tone: "We noticed you haven't updated your billing details yet".
Email 3 — Day 7 final notice:
Last email before subscription cancellation. Emphasize value loss: "Your access to [Product] will be suspended in 24 hours unless your payment is updated."
[Webhook Trigger: invoice.payment_failed]
↓
[Stripe: Get Customer → retrieve email + name]
↓
[Email: Send "payment failed" notification with update link]
↓
[HubSpot: Set contact property "payment_failed_at" = now]
↓
[Slack: Alert #billing-ops channel]
Pro tip: Stripe's Smart Retries feature automatically retries failed charges up to 4 times using machine learning to pick optimal retry times. Make's dunning email sequence complements this by handling the customer-facing communication layer that Stripe doesn't cover.
Scenario 4: Churn prevention — cancelled subscription win-back
When a customer cancels, the window to recover them is 30–90 days. A structured win-back email sequence, triggered automatically by Make when Stripe fires the cancellation event, runs this recovery without manual intervention.
Trigger: customer.subscription.deleted webhook event
Modules: Webhook → Stripe (Get Customer) → CRM (Update) → Email Sequence
Build the win-back workflow
Immediate action (0–5 minutes after cancellation):
- Webhook receives
customer.subscription.deleted. - Stripe: Get Customer fetches the customer's email.
- HubSpot: Update Contact sets
churn_date= today andsubscription_status=cancelled. - Gmail: Send Email — Subject: "We're sorry to see you go — here's what happens next." Acknowledge the cancellation, provide a clear data export/access instructions, and include one low-friction re-engagement link (e.g., "Changed your mind? Reactivate in one click.")
Day 7 — win-back offer:
- A separate scheduled Make scenario runs daily. It queries HubSpot for contacts where
churn_date= 7 days ago andsubscription_status=cancelled. - For each matching contact, send a win-back email with a limited-time discount coupon (generated via Stripe: Create a Coupon).
Day 30 — final check-in:
- Send a brief survey or product update email. This preserves the relationship even if they don't reactivate immediately — they remain in your CRM for future nurture campaigns.
Full scenario summary:
| Event | Make Action | Timeline |
|---|---|---|
| Subscription cancelled | Confirmation email + CRM update | Immediate |
| 7 days post-cancellation | Win-back offer with Stripe coupon | Day 7 |
| 30 days post-cancellation | Feedback survey or product update | Day 30 |
| 90 days post-cancellation | Archive contact or move to cold nurture | Day 90 |
Handling webhook security: Stripe signature verification
Every production Make scenario receiving Stripe webhooks should verify the Stripe-Signature header to prevent spoofed requests. Make doesn't have native Stripe signature verification, but you can add a lightweight check.
In Stripe Dashboard, copy the Webhook Signing Secret (starts with whsec_).
In your Make scenario, after the webhook trigger, add a Tools > Set Variable module to capture {{headers['stripe-signature']}}. Then use an HTTP > Make a Request module to call a lightweight validation function (e.g., a Cloudflare Worker or Vercel Edge Function) that verifies the signature using the Stripe SDK before the rest of the scenario continues.
For lower-stakes workflows (internal notifications, CRM syncs), the raw webhook without signature verification is acceptable. For workflows that trigger financial actions (creating coupons, issuing refunds), always verify the signature.
Make.com Stripe integration: key modules reference
| Module | Use Case |
|---|---|
| Webhooks > Custom Webhook | Receive Stripe events |
| Stripe > Get a Customer | Fetch customer data by ID |
| Stripe > Create a Coupon | Generate discount codes for win-back |
| Stripe > Create an Invoice | Trigger manual invoice creation |
| Stripe > Update a Subscription | Modify subscription quantities or plans |
| Router | Branch logic by event type |
| Sleep | Add delays for timed email sequences |
| HTTP > Make a Request | Call external APIs (signature verification, CRMs without native modules) |
Frequently asked questions
How do I connect Stripe to Make.com?
Create a Custom Webhook module in Make to get a unique URL, then register that URL in your Stripe Dashboard under Developers > Webhooks. Select the specific events you want to trigger your scenario (e.g., payment_intent.succeeded, invoice.payment_failed). No API keys are needed for receiving webhooks — Make's free-tier webhook URL is sufficient.
Can Make.com handle payments directly?
No. Make.com does not process payments. It automates workflows around payment events. Stripe handles all financial transactions — Make.com triggers on Stripe events to automate downstream actions like CRM updates, email sequences, and team notifications.
Does Make.com have a native Stripe integration?
Yes. Make includes a native Stripe app with modules for fetching customers, creating invoices, managing subscriptions, and generating coupons. You don't need the custom webhook approach for outbound calls to Stripe — only for receiving Stripe events inbound.
How many Stripe webhook events can Make handle?
Make's free tier supports 1,000 operations/month. Each webhook event that triggers a scenario counts as one operation, plus one per module executed. A 5-module dunning scenario triggered by 200 failed payments = 1,000 operations. For higher volume, paid Make plans cover significantly more operations — check the Make pricing page for current plan costs.
What's the difference between Make and Zapier for Stripe automation?
Zapier is simpler for basic 1:1 triggers (Stripe event → single action). Make handles multi-step conditional logic, routers, and loops — which are essential for billing automation workflows that branch across subscription statuses, retry counts, and customer segments. Make's visual canvas also makes complex billing flows easier to audit and debug.
Can I automate Stripe invoice creation in Make?
Yes. Use the Stripe > Create an Invoice module triggered on a schedule (e.g., monthly via Make's scheduling trigger) or on a specific CRM event (e.g., when a HubSpot deal reaches "Closed Won"). Make can also auto-finalize and send the invoice using the Stripe > Finalize an Invoice module.
Next steps
The four scenarios above cover the most common SaaS billing automation patterns. The right starting point depends on your current pain point:
- Highest immediate ROI: Build Scenario 3 (dunning emails) first. Failed payment recovery pays for your Make subscription in the first recovered customer.
- Best foundation for growth: Start with Scenario 1 (webhook receiver + router) — it becomes the base layer for all subsequent billing automations.
- Retention-focused teams: Prioritize Scenario 4 (churn prevention) if your monthly churn rate exceeds 3%.
Start building with Make.com for free →
Make's template library also includes pre-built Stripe scenarios you can clone and modify. Search for "Stripe" in the Make template marketplace to find invoice automation, subscription sync, and payment notification templates ready to deploy in under 5 minutes.
