AI Employee Bootcamp: payments move to Whop

The flow

One Worker sits between Whop and everything downstream. It knows what was bought at the moment of the charge, so nothing after it has to guess.

Affiliates

Sales reach FirstPromoter directly from the Worker. Eight GHL workflows are gone.

Capture

• FirstPromoter's tracking script is in the funnel head code and sets _fprom_tid / _fprom_ref on go.theuncommonbusiness.co.
• The checkout block reads those cookies at load and sends them with the payment, so they arrive as Whop payment metadata and are reported with the sale.
• Cookies first, ?fpr= as fallback: the parameter only exists on the landing hop and is gone by the time most buyers reach checkout.
• Same origin throughout, so the read works — provided FirstPromoter does not set those cookies HttpOnly. Nothing can read an HttpOnly cookie from a page script. The live payment test is what proves this end to end, and it is the single most important thing that test checks.

Plan strings the Worker sends

FirstPromoter's plan is free text, not an ID: whatever string we POST has to already exist in FirstPromoter with a reward rate on it, or the sale lands against the promoter at no commission. The Worker now sends your strings, from the First Promoter Product column of the Price Points database — not an invented set.

These thirteen strings are exactly what the Worker sends — verified in the code, not copied from a doc. The eight marked yes were matched against your Price Points database on 15 Aug.

The five marked confirm have never had affiliate tracking under any setup — no Price Points row, no GHL workflow, no FirstPromoter plan — and nobody has confirmed since whether they were created. Only Lisa can check. If a string does not exist in FirstPromoter the sale still lands against the promoter, but at no commission and with no error anywhere. Every bootcamp row in Price Points sets commission equal to price, so unless someone says otherwise these five should be 100% too.

The price is in the string on purpose. FirstPromoter sets reward rates per plan, so a price change has to be a distinct plan or the commission silently follows the old rate — which is why the Sep 20 step-ups get their own entries rather than inheriting.

On a cart with an order bump the bump wins: one payment reports one plan, and it is the upgrade rung, because that is the rung the commission is owed on.

The affiliate tag

The Worker applies aieb-fall26_affiliate to the contact whenever the buyer arrived through a promoter link. This is the tag the old FirstPromoter BID is not empty branch used to apply, and it is applied on exactly the same condition the Worker uses to decide the sale is a referral — so the tag and the FirstPromoter POST can never disagree about whether one happened.

One difference from the old branch, deliberately: it fires on the tracking cookie or the ?fpr= parameter, not the cookie alone. A buyer who lands on a promoter link before the cookie is set is still an affiliate sale, and that is the case that used to disappear without trace.

Your side  Tracking is on every funnel already and carries to checkout. Outstanding: the plan strings above, and add the bootcamp link to the promoter signup so promoters have one to share.

Attribution

Organic, ads and tripwire are one attribute on the page. No logic to build.

• Each block declares data-funnel="organic" | "ads" | "tripwire". It rides the payment; the Worker turns it into a tag.
• New funnel page = copy the block, change data-tier and data-funnel. Nothing else.
• Declared, not inferred, because two bootcamp funnels share one page URL.
• The exact page slug also lands in aieb_page, so GHL conditions can target one ad page without a code change.
• Tripwire is a real third value. GHL only ever wired ads and organic.
• Confirmed 16 Aug: /bootcamp-2026 is the organic funnel, /ads-bootcamp-2026 is paid. Only organic has to be live for Monday.

GHL changes

Tier workflows stay separate, one per tier. Each loses its payment trigger and its price branching, and keeps everything that speaks to the buyer.

The live set is the folder The AI Employee Bootcamp — WHOP: 1 — General Admission (Early Bird + GA), 2 - VIP, 2a — VIP upgrade, 3 - Platinum, 3a - Platinum upgrade, plus 4 - Bounce Email. All five are published and the Worker enters them by ID. The originals are untouched, kept only so the old build can be read side by side — sending a Whop buyer into one would re-run branches that read a GHL order amount that no longer exists.

One addition per workflow: the n8n webhook's custom data gains whop_payment_id. It replaces ghl_order_id as the dedupe key and is the same value Supabase stores as processor_ref.

Fields & tags

Written to the contact on every purchase, before any workflow runs.

The tier map

Every rung that sells, what it costs, and the tags it leaves behind. This is the whole ladder — there is nothing else to sell.

Tags that go on top

Hub gating reads the entitlement; the dashboard reads the trail. Prices, windows and plan IDs live in worker/src/plans.js — that file is the source, this map is the summary.

Checkout map

data-tier and data-funnel are the only two things that differ between one checkout and the next.

AI Employee Bootcamp — main funnel

AI Employee Bootcamp Ads — rebuilt 15 Aug, new slugs

Source: live GHL funnel pull, 15 Aug 2026, 15:10 ET.

Two things to watch

Editing the checkout

A checkout page holds two lines. Everything inside the block is served from one place, so a wording or styling change is one edit and one deploy — never twelve pages re-pasted.

What a page contains

Who edits what

Links

Where it runs

Everything is on your own Cloudflare account — Hello@theuncommonbusiness.co, account 81ac8dfc3cfa5c403247c595aef3db16. Nothing is hosted by Whop, so it stays yours at handover.

Getting to it: dash.cloudflare.com → Compute (Workers) → aieb-fall26-checkout. Login credentials live in your password manager, never on this page.

Source

github.com/The-Uncommon-Business/aieb-checkout — private. Send the GitHub usernames who need it and they will be added as collaborators.

Everything is in there: the Worker, the generated checkout blocks, the GHL inventory scripts and this document. No secrets — env/.env is gitignored and the Worker's credentials are stored in Cloudflare, write-only.

Deploying a change

Step 1 is not optional. embed.js is generated, so the source file can be valid while the string it produces is not — that took every checkout down silently on 15 Aug, with a blank space where the form should be and nothing in the console.

Running it yourselves

Added 24 Aug at Lex's ask. Who owns what, which jobs need a deploy and which do not, and how to drive the repo with Claude without taking the cart down.

Who owns what

Anyone not on this list has no system ownership recorded — say so and it gets added. Philip was named on the 14 Aug kickoff as the most dev-forward of the team and has not been in a thread since; if he is the one taking the repo, he needs the GitHub and Claude setup below.

Does this job need a deploy?

Most of the bottleneck is this question being unanswered. Almost nothing your team wants to do needs code.

Set up once

Claude, connected to the repo

Five commands, once. After this Claude can read every file in the worker, explain what a change would do, make it, and open a pull request — all from the folder on your machine.

For reporting rather than code, the Whop MCP connected to Claude will pull custom reports out of the account — payments, refunds, payouts — without anyone writing a query. It is being rebuilt on the Whop side, so check one number against the dashboard before a figure goes into a deck.

Asking Claude for the right thing

Runbook — a coupon code

Abs. Steps 1–3 are yours alone and need nobody. Step 4 is the one that gets missed.

Runbook — a new product and its checkout

Abs, with Lex. One question decides the route: does the purchase have to reach GHL?

Runbook — purchase → tag → workflow

Nikhil. The worker writes 17 fields and the whole tag set onto the contact before any workflow runs, so nothing downstream has to work out what was bought.

Deploying — the only sanctioned path

This supersedes the local wrangler deploy in Editing the checkout above. A laptop deploy from stale source is exactly what reverted the 3-D Secure and Apple Pay fixes on 17 Aug, twenty-five minutes after they went in.

If something ships broken: Cloudflare → Compute (Workers) → aieb-fall26-checkout → Deployments → roll back to the previous version. One click, no code, faster than any fix.

Supabase

Scott's own Whop webhook writes the purchase into Postgres from Railway. It subscribes to Whop directly, so nothing of ours sits between — and it keeps recording sales even if our Worker does not.

• That keeps sales private — reaching it over the API would have meant exposing all 17 tables for one insert.
• Rows land as processor = 'whop', processor_ref = the Whop payment ID — the same shape as the 25,000 GHL rows, so reporting spans both.

One payment can hold two products

A plan is one product at one price — that never changes. But an order bump is one payment carrying two of them: Early Bird $47 plus the VIP upgrade $150, charged once as $197.

Whop's payments API takes a single plan with a single price and has no line-item array, so the parts cannot be expressed as plan IDs on the charge itself. They ride in the payment metadata instead, as three parallel comma-separated lists in line order, base first:

One row per entry, resolved by plan ID. That is the same two-row shape a GHL multi-line order already produces against one processor_ref — the 539 pairs already in purchases. A single-item cart is a list of one, so it stays one code path. The idempotency key needs to include the plan ID to keep both rows.

Other webhooks

Only payment.succeeded is subscribed today. Refunds, failed payments, cancellations and disputes each have their own event at dev.whop.com. Refunds are the one that matters before launch — without it a refunded seat still counts as sold.