Make.com Stripe Webhook Setup for Server-Side Ad Tracking (2026)

1. Why Stripe Webhooks Outperform Browser Pixels

Most tutorials teach you how to pass basic payment alerts into Slack using Stripe webhooks. That is a notification use case. The architecture documented here is a server-side attribution engine — a pipeline that intercepts verified payment events the moment they occur and routes the enriched data to Meta’s Conversions API and Google’s Enhanced Conversions endpoint simultaneously, bypassing every browser-level tracking restriction that would otherwise lose that conversion.

The fundamental reason Stripe webhooks outperform browser pixels for conversion attribution is the transmission origin. A browser pixel fires JavaScript from the user’s device — a device that may have an ad blocker installed, a browser with ITP enabled, or iOS privacy settings that prevent tracking. A Stripe webhook fires from Stripe’s own infrastructure to your Make.com endpoint the moment a payment is confirmed. It is a server-to-server transmission that never touches the user’s device, making it immune to every client-side privacy mechanism that degrades pixel accuracy.

The secondary advantage is event certainty. A browser pixel fires when the user lands on your thank-you page — before the payment is fully captured, before fraud checks run, and before any post-payment processing completes. A charge.succeeded webhook fires only after the funds are confirmed and the charge is captured. You are attributing verified revenue, not optimistic checkout completions. For ad platforms whose algorithms use conversion data to optimise bidding, verified payment events produce more accurate training signals than confirmation page loads.

According to Stripe’s official webhook documentation, Stripe retries failed webhook deliveries up to 16 times over three days using exponential backoff, ensuring your attribution pipeline receives every event even during temporary Make.com downtime or maintenance windows.

2. Generating the Make.com Webhook Endpoint

Before configuring anything in Stripe, you need the receiving endpoint — the URL where Stripe will send payment events. Make.com generates this automatically when you create a Custom Webhook module.

3. Configuring the Stripe Webhook

With your Make.com endpoint URL copied, navigate to the Stripe Webhooks section under Developers in your Stripe dashboard. Click Add an Endpoint and paste your Make.com URL into the endpoint URL field.

4. Capturing Click IDs Before Checkout

The webhook configuration handles data transmission. But the data is only as useful as the information it contains. For server-side attribution to link a conversion back to the specific ad click that drove it, the fbclid (Meta Click ID) and gclid (Google Click ID) must travel from your landing page through checkout and into the Stripe payment metadata, where they are available in the webhook payload.

This is the step most guides skip, and it is the reason many Make.com Stripe webhook setups catch the payment data but cannot attribute it to the right ad. The click ID disappears between landing page and payment confirmation because no mechanism was put in place to carry it forward.

5. The Webhook Payload Structure

When a successful purchase occurs, Stripe fires a JSON payload to your Make.com webhook endpoint. Here is the exact structure for a correctly configured tracking payload, including the metadata fields that carry click IDs and UTM parameters:

{
  "id": "evt_123456789",
  "type": "charge.succeeded",
  "data": {
    "object": {
      "id": "ch_3Pxxxxxxxxxxxxx",
      "amount": 99700,
      "currency": "usd",
      "billing_details": {
        "email": "customer@example.com",
        "phone": "+14155551234",
        "name": "Jane Operator"
      },
      "metadata": {
        "fbclid": "IwAR2xyz123abc...",
        "gclid": "Cj0KCQiA_qG5BhDTARIsAA...",
        "utm_source": "facebook",
        "utm_campaign": "Q2_Retargeting",
        "utm_medium": "cpc"
      },
      "customer": "cus_Pxxxxxxxxxxxxxx",
      "balance_transaction": "txn_3Pxxxxxxxxxxxxx"
    }
  }
}

Key fields to note: amount is in cents — divide by 100 to get dollars. The metadata object contains the click IDs and UTM parameters you passed from checkout. The billing_details object contains the customer PII that must be normalised and hashed before transmission to any ad platform API. The id under data.object is the Charge ID — this is your event_id for Meta CAPI deduplication.

6. Parsing and Hashing the Payload in Make.com

After Make.com receives the webhook payload, the next modules in the scenario parse the JSON structure and apply the PII normalisation and hashing required by both Meta CAPI and Google Enhanced Conversions before any data is transmitted to an ad platform API.

7. Routing to Meta CAPI and Google Enhanced Conversions

With the payload parsed and hashed, add a Router module to branch the data into two simultaneous paths. Path A sends the Meta CAPI payload. Path B sends the Google Enhanced Conversions payload. Both execute from the single charge.succeeded trigger.

For Path A (Meta CAPI), add an HTTP Make a Request module pointing to https://graph.facebook.com/v19.0/{PIXEL_ID}/events with the hashed user_data object, event_name: "Purchase", the event_id set to the Stripe Charge ID for deduplication, and custom_data.value set to the net conversion amount. The complete payload structure is documented in our CAPI deduplication guide.

For Path B (Google Enhanced Conversions), use Make.com’s native Google Ads module or an HTTP call to Google’s conversion upload endpoint with the hashed email in the user_identifiers array, the gclid from the payment metadata, and the conversion value and timestamp. The complete Google payload structure is in our Google Enhanced Conversions guide.

8. Testing and Verification

Related Attribution Guides

9. Frequently Asked Questions