Skip to main content

Make.com + Stripe: Automate Payment and Billing Workflows

· 11 min read
Yassine El Haddad
Software Developer & Automation Specialist

I build production AI agents, web scrapers, and automation pipelines. Most of what I publish here comes from the actual problems they run into: proxies that get banned, anti-bot stacks that fingerprint your client, RAG that drifts when the underlying data moves. Stack: Python, TypeScript, Go, FastAPI, LangChain, Crawlee, Playwright, deployed on AWS, GCP, and Cloudflare.

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.

ApproachSetup TimeRequires CodeMaintenance
Custom server (Node.js / Python)2–4 hoursYesHigh
Zapier15 minNoLow
Make.com10 minNoLow
n8n (self-hosted)30 minNoMedium

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

  1. Open Make.com and create a new scenario.
  2. Add the Webhooks > Custom Webhook module as the trigger.
  3. Click Add to create a new webhook — Make generates a unique URL (e.g., https://hook.eu1.make.com/abc123...).
  4. Click Copy address to copy the URL.

Step 2: Register the webhook in Stripe

  1. In your Stripe Dashboard, navigate to Developers > Webhooks.
  2. Click Add endpoint.
  3. Paste the Make webhook URL into the Endpoint URL field.
  4. Under Events to send, select the events relevant to your workflow. Start with these four:
    • payment_intent.succeeded
    • invoice.payment_failed
    • customer.subscription.deleted
    • invoice.created
  5. 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: type equals payment_intent.succeeded
  • Route 2: type equals invoice.payment_failed
  • Route 3: type equals customer.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

  1. 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.

  2. Add HubSpot > Create/Update a Contact (or your CRM equivalent). Map the fields:

Make fieldCRM 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
  1. 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):

  1. Webhook receives customer.subscription.deleted.
  2. Stripe: Get Customer fetches the customer's email.
  3. HubSpot: Update Contact sets churn_date = today and subscription_status = cancelled.
  4. 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:

  1. A separate scheduled Make scenario runs daily. It queries HubSpot for contacts where churn_date = 7 days ago and subscription_status = cancelled.
  2. 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:

  1. 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:

EventMake ActionTimeline
Subscription cancelledConfirmation email + CRM updateImmediate
7 days post-cancellationWin-back offer with Stripe couponDay 7
30 days post-cancellationFeedback survey or product updateDay 30
90 days post-cancellationArchive contact or move to cold nurtureDay 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

ModuleUse Case
Webhooks > Custom WebhookReceive Stripe events
Stripe > Get a CustomerFetch customer data by ID
Stripe > Create a CouponGenerate discount codes for win-back
Stripe > Create an InvoiceTrigger manual invoice creation
Stripe > Update a SubscriptionModify subscription quantities or plans
RouterBranch logic by event type
SleepAdd delays for timed email sequences
HTTP > Make a RequestCall 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.