Integrations

Whop revenue attribution with checkout metadata

Whop payment events can connect a membership sale to its acquisition source when the checkout carries analytics IDs. A plain outbound link cannot establish that connection on its own.

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 Whop, and copy the webhook URL shown there. Your deployment’s settings are the authority for its origin.

Configure the webhook

  1. Create a webhook in your Whop developer settings. Use the URL shown for this analytics site and pin the webhook API version. Keep the chosen version stable while testing payment, refund and renewal payloads.
  2. For hosted tracking, the endpoint has this form:
    https://t.analyticfast.com/api/webhooks/whop/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.succeeded
    • refund.created
    • refund.updated
  4. Paste the entire literal ws_ signing secret into AnalyticFast. Preserve its prefix and bytes; do not decode or re-encode it. The adapter validates the Standard Webhooks headers with the literal secret and a five-minute signed-timestamp window.
  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: Whop webhook destination with the site URL and required events selected; hide all signing secrets.

Carry the visitor into checkout

Create a checkout configuration on your server with metadata.ml_visitor_id and metadata.ml_session_id, or use the supported Elements checkout metadata option. Consult the API version used by your app: the versioned checkout-configuration reference and the Elements checkout guide.

// 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.
// Metadata fragment for your existing server-created Whop checkout configuration:
metadata: { ml_visitor_id, ml_session_id }
// Omit missing IDs; preserve application metadata and existing checkout settings.

Plain Whop links are not automatically tagged with invented query parameters. Keep payment credentials on the server; the browser forwards only optional attribution context.

What creates revenue and refunds

Successful payments use the Whop payment ID. Current payment Money values and supported pinned legacy payment payloads are normalized to minor units with currency. subscription_cycle payments are classified as renewals. Created/updated refund deliveries count only when successful and refer to the same refund identity, preventing double subtraction.

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 Whop, verify signatures over the network or persist revenue.

Limits to check before going live

Refunds need a settled amount and a link to the original payment. The adapter does not substitute a distinct processor-currency original_amount for the settlement amount. Fixtures cover supported shapes; they are not evidence of a completed live merchant checkout. Validate your pinned version in your own test environment.

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.

Can I append ml_visitor_id to any Whop checkout link?

Do not assume arbitrary hosted-link query parameters become payment metadata. Use the documented server checkout-configuration or Elements metadata option, then confirm those values appear in the signed payment payload.

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.