Integrations

Stripe revenue attribution: connect payments to traffic

A successful Stripe payment tells you what sold. A tracked visit plus checkout metadata tells you which source brought the buyer. AnalyticFast joins those records without treating a checkout-button click as revenue.

Before you connect

Install the tracker on your verified website and confirm the first event. Open that site’s Settings → Revenue as a workspace owner or admin, choose Stripe, and copy the webhook URL shown there. Your deployment’s settings are the authority for its origin.

Configure the webhook

  1. In Stripe Workbench, open Webhooks and add an event destination for your account. Choose snapshot events; thin events require API retrieval and are not supported by this adapter.
  2. For hosted tracking, the endpoint has this form:
    https://t.analyticfast.com/api/webhooks/stripe/YOUR_SITE_ID
    Replace YOUR_SITE_ID with this site’s ID; use the exact URL from Settings if its origin differs.
  3. Subscribe to these events:
    • payment_intent.succeeded
    • invoice.paid
    • refund.created
    • refund.updated
  4. Reveal the destination’s signing secret beginning with whsec_ and save it in AnalyticFast. The manual signing-secret field expects this endpoint secret, not a Stripe API key. If you use the separate Connect option, supply a restricted key with Webhook Endpoints: Write; the connector creates the destination and stores its returned signing secret.
  5. Save. Optionally enter product IDs to filter transactions. A matching product includes the entire transaction, so a filter is not product-level revenue allocation.
Screenshot placeholder: Stripe webhook destination with the site URL and required events selected; hide all signing secrets.

Carry the visitor into checkout

Read the optional attribution IDs before checkout, then forward them to your server. For one-time Checkout sessions put them in payment_intent_data.metadata. Session-level metadata alone does not copy itself to the PaymentIntent. For subscriptions, set subscription_data.metadata so invoice context can supply attribution. See Stripe’s metadata propagation rules.

// Browser: read IDs immediately before asking your server to create checkout.
const attribution = window.analyticfast?.attribution?.() ?? {};
// Send these optional IDs with your existing checkout request.
// Server: validate them and copy only the present values into provider metadata.
// Keep prices, products and all payment credentials under server control.
// Server-side fragments for your existing Stripe Checkout creation code.
// Build metadata from validated attribution IDs; omit missing values.
// One-time payment:
payment_intent_data: { metadata: { ml_visitor_id, ml_session_id } }
// Subscription (a separate mode):
subscription_data: { metadata: { ml_visitor_id, ml_session_id } }

These are configuration fragments, not a complete Checkout request. Keep your existing mode, prices and success/cancel URLs. An optional ml_product_id metadata value supplies product evidence when the PaymentIntent has no expanded products.

What creates revenue and refunds

Only a successful PaymentIntent creates financial revenue, once by its PaymentIntent ID. Paid invoices add attribution, product context and renewal classification; they do not add a second payment. An invoice without a PaymentIntent reference cannot create revenue here. Successful refund resources subtract their settled amount from the original payment; pending and failed refunds do not.

Verify with a real signed test delivery

  1. On your separate test site, arrive with a unique UTM campaign and complete a sandbox payment through your actual checkout flow.
  2. Inspect the provider’s delivery log, then check the payment, its currency and its attributed visit in AnalyticFast. Test mode data should stay out of your production analytics site.
  3. Retry the same delivery and confirm no duplicate revenue. Issue a successful partial or full refund and confirm the net amount falls once. For subscriptions, test a later renewal.

The settings test button is a local parser preview. It does not contact Stripe, verify signatures over the network or persist revenue.

Limits to check before going live

Plain Stripe Payment Links are not automatically tagged. client_reference_id is an application reference, not arbitrary PaymentIntent metadata. Preserve your application reference and use a checkout creation flow that supplies the required metadata. Credit-only or out-of-band invoices without a successful PaymentIntent are outside this adapter’s financial coverage.

No universal historical import runs when you save a webhook. Validate new deliveries first. Keep currencies separate and compare like date ranges; an analytics revenue total is not a bank payout statement.

Official references

Setup reviewed against the current adapter and official documentation on October 31, 2026. This is an implementation guide, not a claim that a live checkout was exercised.

Add your website to AnalyticFast, then open Settings → Revenue to copy its webhook URL.

Questions, answered.

Will invoice.paid and payment_intent.succeeded double-count a subscription payment?

No. Financial identity is the PaymentIntent ID. Invoice events enrich that payment, including renewal classification and product evidence. Keep the PaymentIntent event enabled; an invoice by itself is not a replacement for it.

Does the test button send a real payment?

No. It is a local parser preview: it contacts no provider, verifies no signed delivery, and records no revenue. Use a separate AnalyticFast test site and your provider sandbox to check payment, renewal, retry and refund delivery.

Do I need to expose payment credentials in my website?

No. The Site ID is public. Webhook signing secrets belong in the Revenue settings, and payment API keys belong on your server. Only optional visitor and session IDs travel from the browser to your checkout code.