I built a full Linktree clone with Next.js and Whop

I spent a few days building a Linktree clone. Public creator pages with free links anyone can click and premium links gated behind a one-time payment. Creators set their own unlock price, drag links into the order they want, and pick from a palette of accent colors. The whole thing is on GitHub.

The dashboard and the public profile page were the parts I expected to take time. They didn't, honestly — standard React with react-server-actions and dnd-kit. What I was actually dreading was the monetization layer: routing money to individual creators, identity verification so creators can legally receive payouts, an embedded balance and withdrawal UI, and webhooks that don't double-process when Whop retries. That's the kind of stack that turns a side project into months of paperwork.

I ended up using Whop for all of it: OAuth, connected accounts, KYC, direct charges, embedded payout portal, and webhooks.

What's in the box

It's a link-in-bio platform. Creators sign up, claim a handle, drop in free and premium links, and share /u/their-handle. Visitors see the free links right away; premium links show up as locked rows with a price chip. Click the unlock button, pay once, premium content unlocks for that browser. Here's what it does:

• Public profile page at /u/[handle] with the creator's bio, avatar initial, and ordered links
• Drag-and-drop link reordering with optimistic UI (dnd-kit + Prisma $transaction)
• Six accent-color presets driven by CSS variables, recoloring the public page live
• Free vs. premium link toggle per row, plus per-row visibility hiding
• One-time unlock checkout via Whop Direct Charges with a flat application fee per sale
• OAuth login through Whop (PKCE flow, iron-session cookies)
• Connected-account creator onboarding via Whop's hosted KYC, with a sandbox bypass modal for local dev
• Embedded payout portal in the dashboard (balance, verify, withdraw, withdrawal history)
• Webhook handler with signature verification and a unique-constraint-based idempotency store
• CSP headers tuned for Whop's hosted checkout and embedded components
• Two-path payment confirmation (redirect verify route + webhook handler converging on the same state)

Stack: Next.js 16 (App Router), Prisma + PostgreSQL, iron-session, Whop SDK, @whop/embedded-components-react-js, dnd-kit, Tailwind v4, deployed on Vercel.

It handles real money. You can deploy it and let creators monetize their audience today.

How Whop made the hard parts easy

Auth without a password table

I've implemented email/password auth from scratch before. Password hashing, email verification, reset tokens, session management. It takes a while and it's never fun. Whop OAuth replaces all of that with three routes (login, callback, logout) and a session helper.

The login route generates a PKCE challenge, stores the verifier in an HTTP-only cookie, and redirects to Whop:

const codeVerifier = generateCodeVerifier();
const codeChallenge = generateCodeChallenge(codeVerifier);
const state = randomBytes(16).toString("hex");
const nonce = randomBytes(16).toString("hex");

const params = new URLSearchParams({
  response_type: "code",
  client_id: process.env.WHOP_CLIENT_ID!,
  redirect_uri: process.env.WHOP_REDIRECT_URI!,
  scope: "openid profile email",
  state,
  nonce,
  code_challenge: codeChallenge,
  code_challenge_method: "S256",
});

const res = NextResponse.redirect(`${whopBase}/oauth/authorize?${params}`);
res.cookies.set("pkce_verifier", codeVerifier, cookieOpts);
res.cookies.set("oauth_state", state, cookieOpts);
return res;

The callback route exchanges the code for tokens, decodes the id_token to get the Whop user ID, upserts the creator into Postgres, and saves an iron-session cookie. That's it. No password table, no token rotation, no "forgot password" flow.

One thing worth calling out: the nonce parameter is required when the OAuth scope includes openid. Without it, Whop's authorize endpoint returns invalid_request. Easy to miss because it's not in the OAuth 2.1 spec — it's an OpenID Connect extension Whop enforces.

Connected accounts and payments in a few SDK calls

This was the feature I was most nervous about. If I'd gone other routes, I'd be building account onboarding flows, managing payout schedules, handling currency edge cases. Months of work plus ongoing compliance overhead.

Whop's Direct Charge model handles all of it. Each creator becomes a connected company under the platform's parent company. The buyer's payment goes directly to the creator's company, and the platform takes a flat fee via application_fee_amount. The platform is never the merchant of record.

Two SDK calls onboard a creator:

const company = await whop.companies.create({
  title: creator.title || creator.handle,
  parent_company_id: process.env.WHOP_PARENT_COMPANY_ID!,
  email: creator.user.email,
});

const accountLink = await whop.accountLinks.create({
  company_id: company.id,
  use_case: "account_onboarding",
  return_url: `${APP_URL}/api/earnings/complete`,
  refresh_url: `${APP_URL}/dashboard?refresh=true`,
});

redirect(accountLink.url);

That kicks the creator into Whop's hosted KYC flow. Identity documents, bank account linking, tax info — all handled by Whop. When the creator returns, the /api/earnings/complete route asks Whop for the company's payout methods and only marks the creator as payoutEnabled = true if a real method is on file. That guard matters because anyone could navigate directly to the return URL without actually completing KYC.

The unlock checkout is a single SDK call:

const checkout = await whop.checkoutConfigurations.create({
  plan: {
    company_id: creator.whopCompanyId,         // creator's connected account
    currency: "usd",
    plan_type: "one_time",
    initial_price: priceInDollars,
    application_fee_amount: feeInDollars,     // platform cut
  },
  redirect_url: `${APP_URL}/api/checkout/verify?handle=${handle}&unlock_id=${unlock.id}`,
  metadata: { unlock_id: unlock.id, creator_id: creator.id },
});

redirect(checkout.purchase_url);

The application_fee_amount is where the platform's flat per-sale fee comes off the top. The metadata carries the unlock ID through to both the redirect verification route and the webhook handler so I know which Unlock row to mark as paid.

Payouts without building a banking integration

After a creator completes KYC, their dashboard needs a balance, a withdraw button, and a withdrawal history view. That's normally banking-integration territory. Whop ships React components for all of it:

<Elements elements={elementsPromise}>
  <PayoutsSession
    companyId={companyId}
    token={fetchPayoutToken}
    currency="usd"
    redirectUrl={typeof window !== "undefined" ? window.location.href : "/dashboard"}
  >
    <div className="space-y-4">
      <StatusBannerElement />
      <VerifyElement />
      <BalanceElement />
      <WithdrawButtonElement />
      <WithdrawalsElement />
    </div>
  </PayoutsSession>
</Elements>

That's the whole payout UI. The token prop is a function (not a string), so the SDK refreshes the access token automatically before it expires. The token endpoint on the backend is six lines: look up the creator's whopCompanyId, call whop.accessTokens.create({ company_id }), return the result. The CSP headers in next.config.ts allow the Whop iframes and scripts to load. That's the whole integration.

The unlock flow (the part I actually engineered)

This is the most interesting piece from a pure engineering standpoint, and it's specific to the unlock pattern.

When a buyer pays, two things happen in parallel: Whop redirects the buyer's browser back to my app with a payment_id, and Whop fires a payment.succeeded webhook to my server. The redirect is fast and gives the buyer instant feedback ("you're paid, here are your premium links"). The webhook is reliable and arrives even if the buyer closes their tab on the success screen. Both paths need to converge on the same state — the Unlock row going from PENDING to PAID — without double-processing or missing each other.

The redirect route is straightforward: read payment_id from the query, retrieve the payment from Whop, mark the unlock as paid, redirect to the profile. The webhook handler has to be more careful, because it might fire before, after, or simultaneously with the redirect:

async function handlePaymentSucceeded(paymentId: string) {
  // Path A: redirect already linked the unlock by payment ID. Idempotent no-op.
  const existing = await prisma.unlock.findUnique({
    where: { whopPaymentId: paymentId },
  });
  if (existing) {
    if (existing.status !== "PAID") {
      await prisma.unlock.update({
        where: { id: existing.id },
        data: { status: "PAID" },
      });
    }
    return;
  }

  // Path B: webhook arrived first, or the buyer closed the tab. Pull
  // the unlock_id from the payment metadata and mark it paid.
  const payment = await whop.payments.retrieve(paymentId);
  const unlockId = (payment.metadata as Record<string, string> | null)?.unlock_id;
  if (unlockId) {
    await prisma.unlock.updateMany({
      where: { id: unlockId, status: "PENDING" },
      data: { status: "PAID", whopPaymentId: paymentId },
    });
  }
}

The system is correct under all four orderings: redirect-then-webhook, webhook-then-redirect, redirect-only (buyer waits for it), and webhook-only (buyer closes the tab). The whopPaymentId column has a unique constraint, so if both paths race they can't both set it. The updateMany with status: "PENDING" filter means the second writer is a no-op. And a separate WebhookEvent table with id as primary key gives the webhook handler a unique-constraint trip on duplicate deliveries before it does any other work:

try {
  await prisma.webhookEvent.create({
    data: { id: event.id, type: event.type },
  });
} catch (err) {
  if (err instanceof Prisma.PrismaClientKnownRequestError && err.code === "P2002") {
    return NextResponse.json({ received: true, deduped: true });
  }
  throw err;
}

Three idempotency layers stacked: the event-ID dedup at the top, the whopPaymentId unique constraint in the middle, the status: "PENDING" filter at the bottom. Whop can deliver the same event twice, the buyer can refresh the success page, both paths can race — none of it produces a duplicate Unlock row or a double-charge feeling for the buyer.

Same pattern works for any payment-driven app. It's a redirect-as-happy-path, webhook-as-source-of-truth design with idempotent merging at every step.

Things I'd do differently

I'd build the webhook handler first. Same lesson I learned building the StockX and Substack clones. The webhook handler is where payment state actually materializes in your database, and if it's broken people pay but your app has no idea. I burned a couple hours on a signature verification bug that turned out to be a trailing newline in the webhook secret. (printf, not echo, when setting env vars through a CLI.)

I'd start on the Whop sandbox from day one. I've done the "start on production then switch" dance before, and it always means recreating my app and re-entering credentials. Set NEXT_PUBLIC_WHOP_ENV=sandbox and a sandbox API key before writing any code.

Specific to this project: the SDK option for the sandbox API base is baseURL with a capital URL, and the value has to include /api/v1 (https://sandbox-api.whop.com/api/v1). TypeScript silently accepts baseUrl as an unknown property and the SDK falls back to production, so every SDK call hits the production API even with a sandbox key. The error you see is 401 Authentication failed on every SDK call. OAuth keeps working because that uses manual fetch against the Whop OAuth base, not the SDK — which makes the bug look like an auth scope issue when it's actually a typo.

Also: enable "Connected account events" when you create the webhook in the Whop dashboard. Without it, your handler never fires for payments to your creators' connected companies, which is every payment in this app.

Links

• Demo: linktree-clone-theta-azure.vercel.app
• Code: github.com/east-6/linktree-clone
• Full tutorial: 15-step walkthrough on the Whop blog covering every file from scaffold to deploy

The Whop-specific code in the whole project is maybe 350 lines. Everything else is a normal Next.js app with Prisma. If you're building a creator-monetization product where individual creators need to get paid and you want a payout UI without building a banking integration, the Whop developer docs are worth looking at.