A Whop-gated Discord community is paid for twice: once at the ad platform, once at the Whop checkout. Whop shows you the second number and Meta the first, and neither says which member or which purchase came from which ad. This guide puts the click, the Discord join and the Whop purchase on one line and sends the purchase back to Meta with its value.
Whop is where the money is: the product page, the checkout, the membership that gates the Discord server, the renewals. Its ads reporting, which as of November 2026 connects to Meta, shows what each campaign spent next to what the store earned. What it does not show is the chain between them: this click, this member, this purchase. A creative with cheap clicks and no paying members looks as good as the one that fills the server, because nothing ties a sale to a creative.
On the Meta side the gap is the same from the other direction. Meta sees the click and, with a pixel on a landing page, the page view. The join happens inside Discord and the purchase inside Whop, both out of the pixel's reach, so the campaign is optimised for clicks and cost per paying member is worked out in a spreadsheet at the end of the month, if at all.
Tellmetric has no Whop Ads API integration; the Ad accounts hub lists Whop campaign reporting as coming soon. What exists today is the attribution: the click recorded with Whop's visitor id, the Discord join matched to the click, the purchase arriving by postback, and the Purchase reported to Meta with value.
Both work; the difference is where the click id has to be kept. The steps below cover both.
For the server-first order, the ad points at a tracking link of the kind "Opens your Discord server", created on Links. The redirect records the click with the fbclid, the campaign parameters (utm_campaign is filled from the link's name), sub-ids, country and device, and issues a click id.
For the checkout-first order, the ad points at your own landing page with the tracker.js snippet from the Developers page. The script records the visit, reads the fbclid and the UTMs from the page address, keeps the click id in a first-party fbc cookie, picks up the fbp cookie if a Meta pixel is present, and reads Whop's first-party visitor cookie, _wuid, when Whop's checkout embed or script on the page has set it. Whop sets that cookie asynchronously, so the script checks again a few times over the first seconds and re-sends the visit once the id appears. Every tracking link on the page is then filled with the click data, so a tap on it records a click that carries the Whop visitor id as wuid alongside the fbclid.
The visitor id is the bridge to Whop's records. It is stored with the click, and it is available as the {wuid} macro in outbound webhooks, so a Whop purchase that your system can see with the same id can be matched to the click that brought the buyer.
The tracking link sends the visitor to Discord's authorise screen for your own application ("know your username, join servers for you"); the click id travels in the signed state of the request. On Authorise, your application adds the person to the server and opens the channel you chose, and the join is recorded against that one click. Someone already in the server is not counted again; someone who pressed Cancel gets in through a plain invite, unattributed. The join is reported to Meta as CompleteRegistration with the click's identifiers, and never with anything from Discord about the person.
After the days you set on Connections, the worker asks Discord whether the member is still there: Retained if so, Leave if not. For a Whop community that is a useful early read: a creative whose members leave before the paid tier is unlikely to produce purchases either. Discord tracking without a pixel explains what the authorised join records and what reaches the ad platform.
Connections → Payments from Stripe or Whop gives your workspace a receiving address for Whop. Create a webhook in the Whop dashboard for payment.succeeded pointing at it and paste the signing secret; every delivery is checked against that secret, and Whop retries a refused one. Each successful payment becomes a Purchase with Whop's amount and currency and the payment id as the transaction id, so a retried delivery stores once and a renewal counts as its own payment.
Which ad gets the credit depends on what the payment carries:
clickid in its metadata (the value your offer link fills in) lands the purchase on the click's campaign, ad set and creative.A postback works as well, for a backend of your own: the same grammar every broker uses, with the click id, the status, the payout and Whop's payment id as the transaction id.
GET https://www.tellmetric.com/postback?clickid={clickid}&status=sale&payout=49¤cy=USD&txid={whop_payment_id}&api_key=YOUR_KEY
The Whop visitor id on its own is not a match key: it is stored on the click and forwarded with every conversion (the {wuid} macro and the webhook body), so a system of your own can join the two. So the step that needs care is getting the click id, or the buyer's email, into what Whop sends.
The postback lands on the click's campaign, ad set and creative, and the delivery worker sends it to Meta's Conversions API as a Purchase with value and currency, the fbc rebuilt from the original fbclid, the fbp if the landing page had it, the IP address and user agent from the click, the hashed email, and a stable event id. Meta can then optimise for buyers rather than clickers. On Pro and Agency the same purchase goes to TikTok, Snapchat, Reddit, Spotify, X and Google Ads, each with its own click id captured at the redirect.
Meta refuses events older than seven days, so send the postback when the payment happens, not in a nightly batch. If a Meta pixel on the landing page also fires a Purchase, give both the same event id so Meta counts one; the event API accepts your own event id for that.
The Dashboard shows, per link and per creative, clicks, joins, retained members and purchases with their value, and once spend is imported from Meta, cost per join and cost per retained member beside each row. The creative with the cheap clicks and no buyers is visible as such, and the money moves to the one whose members pay and stay.
The figures are illustrative. A sports-picks community sells a monthly Whop membership for the paid channels of its Discord server. Three Meta creatives spend the same budget; Whop reports the month's sales as one number. On the Dashboard, creative A shows 180 joins and 9 purchases, creative B 240 joins and 3, creative C 90 joins and 11. Cost per paying member is lowest on the creative with the fewest joins, Meta receives 23 Purchase events with value, and the budget on creative B is cut.
Not yet. The Ad accounts hub lists Whop campaign reporting as coming soon. Attribution of Whop purchases to the ad works today through the click, the authorised Discord join and the postback.
No. A purchase reaches Tellmetric through the standard postback URL or the event API, which your backend or a Zapier or Make step calls when Whop reports a payment.
Whop's first-party visitor id, read from its cookie by tracker.js on your landing page and stored with the click. It is forwarded as the {wuid} macro and in the webhook body so your own system can relate a Whop record to a click.
A Purchase with value and currency, the click's fbc, fbp, IP address and user agent, a hashed email if the postback carried one, and an event id. Nothing from Discord about the person, and nothing from Whop beyond the amount.
Meta on every plan. TikTok, Snapchat, Reddit, Spotify, X and Google Ads on Pro and Agency, which also include CSV exports and the match-quality panel.
The Free plan requires no card. Upgrade to Pro at any time.