DEV Community: Doğukan Karakaş

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

Doğukan Karakaş — Wed, 13 May 2026 20:00:46 +0000

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
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. 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.

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

Doğukan Karakaş — Thu, 07 May 2026 16:18:46 +0000

I spent the last few weeks building a Fiverr clone called GigFlow. Tiered gig packages, seller KYC, in-app checkout, real-time chat per order, the whole multi-stage delivery loop. It's a single Next.js project and the whole thing is on GitHub.

The gig pages and the order workspace were what I expected to take time. They did, but it was straightforward React. What I was actually dreading was the marketplace plumbing: routing payments to individual sellers, identity verification so those sellers can legally receive money, payout management for them after the fact, and a chat system so buyers and sellers can coordinate without giving up email addresses. Those are the kinds of features that turn a side project into a quarter-long slog through Stripe Connect, Persona, Plaid, and a queue of compliance work.

I ended up using Whop for all of it - connected accounts, KYC, payouts, embedded chat - one SDK. And on top of that, I never had to redirect a user to a different domain to do any of it. I'll explain what I mean.

What's in the box

GigFlow is a freelance services marketplace. Sellers list gigs with three pricing tiers and optional add-ons, buyers purchase, requirements get submitted, deliveries happen, revisions happen if needed, and reviews get left at the end. Here's what it does:

Tiered gig packages (basic, standard, premium) with optional extras
Slide-out checkout via Whop's <WhopCheckoutEmbed /> (no redirect off the gig page)
In-app KYC and payouts via Whop's <VerifyElement /> and <PayoutsSession> (no redirect off the dashboard)
Direct charges with a configurable platform fee, set in basis points (10% by default)
Order lifecycle state machine: requirements → in_progress → delivered → completed, with revision and dispute branches
Embedded buyer-seller chat per order, via Whop's <ChatElement />
Whop OAuth (PKCE) with chat scopes; email/password through Supabase as a fallback
Reviews on delivered orders, with auto-completion when a review is left
Webhooks for payments, refunds, disputes, KYC verification, and payouts
Database-enforced KYC gate: a Postgres trigger that rejects gig publishes from unverified sellers
Supabase Row Level Security with self / participant / admin patterns

Stack: Next.js 16 (App Router), Supabase for Postgres + RLS, the Whop SDK + Whop Embedded Components + Whop Checkout, Tailwind v4, deployed on Vercel.

It handles real money. You can deploy it and run a marketplace today.

How Whop made the hard parts easy

Payments and KYC without the redirect

This was the bulk of what I expected to build. A marketplace like Fiverr has to onboard sellers (collect identity documents, link bank accounts, handle taxes), charge buyers, and route money to the right seller minus a platform fee. From scratch that's months of integration work plus ongoing compliance overhead.

Whop's Direct Charge model handles all three flows. The buyer pays, the funds go to the seller's connected company, and the platform's cut is captured via application_fee_amount. GigFlow is never the merchant of record.

Here's the checkout creation, with the gig package threaded through metadata so the webhook knows what got paid for:

const checkoutConfig = await client.checkoutConfigurations.create({
  mode: 'payment',
  plan: {
    company_id: seller.whop_company_id,
    currency: 'usd',
    initial_price: totalDollars,
    plan_type: 'one_time',
    application_fee_amount: applicationFee,
    title: gigTitle,
    product: {
      external_identifier: `gig_${gig.id}_pkg_${packageId}`,
      title: gigTitle,
    },
  },
  metadata: {
    gig_id: gig.id,
    package_id: packageId,
    package_title: packageTitle,
    quantity: String(quantity),
    extras_ids: extras.map((e) => e.id).join(','),
    buyer_user_id: user?.id ?? '',
  },
});

Money flow: buyer pays → funds land in the seller's connected company minus the platform fee → seller submits the delivery → buyer accepts → seller withdraws. The platform fee is configured in basis points (PLATFORM_FEE_BPS=1000 is 10%) and split off automatically.

The thing that's different about GigFlow vs. the other Whop-based marketplaces I've built is that I never redirect anywhere for a financial flow. Checkout is a slide-out panel rendering Whop's <WhopCheckoutEmbed />. KYC and payouts are Whop's <VerifyElement /> and <PayoutsSession> from @whop/embedded-components-react-js:

<Elements loader={loadWhopElements}>
  <PayoutsSession companyId={companyId} getToken={getToken}>
    <VerifyElement
      includeControls
      onVerificationSubmitted={async () => {
        // Optimistic local sync. The verification.succeeded
        // webhook is still the source of truth.
        await fetch('/api/sell/kyc/sync', { method: 'POST' });
        onComplete?.();
      }}
      onClose={onClose}
    />
  </PayoutsSession>
</Elements>

The seller never sees a URL change. The same <PayoutsSession> provider also wraps the seller dashboard, so payout method management and balance views live inside the app too. The whole seller-side financial UX is an embed, not a hosted page.

On the backend, two SDK calls bootstrap a seller: companies.create to create their connected company under the platform, and accountLinks.create for the embed to authenticate against. From then on, KYC status is owned by Whop, and a verification.succeeded webhook updates a local kyc_status column when the seller is approved. About 80 lines for the webhook handler plus four event-specific functions.

Auth that unlocks chat

GigFlow ships with two login paths: email and password through Supabase Auth, and "Continue with Whop" via Whop OAuth. Both work for buying and selling. But Whop OAuth is what unlocks the embedded chat in the next section, because the chat token endpoint needs a whop_user_id to mint a user-scoped access token.

The login route uses PKCE and asks for the chat scopes upfront:

const scopes = [
  'openid',
  'profile',
  'email',
  'chat:message:create',
  'chat:read',
  'dms:read',
  'dms:message:manage',
  'dms:channel:manage',
].join(' ');

The route generates a PKCE challenge, stashes the verifier in an HTTP-only cookie, and redirects to Whop. The callback exchanges the code for a token, fetches /oauth/userinfo, links the Whop user to a Supabase user record, and stores whop_user_id and refresh_token on the profile. Then the chat token endpoint can mint short-lived access tokens whenever a buyer or seller opens an order workspace.

If you skip those scopes, you can still ship GigFlow - the chat embed degrades to a "connect your Whop account" prompt - but you've left the most polished part of the product on the floor.

Chat without building chat

Real-time chat means WebSocket servers, message persistence, connection state, moderation, and a UI people will actually like. Skipping all of that on a side project is a gift:

<Elements loader={loader}>
  <ChatSession
    getToken={async () => token}
    environment={whopEnv}
    appearance={{ theme: 'light' }}
  >
    <ChatElement
      channelId={channelId}
      emptyState="Send a message to start the conversation"
      onReady={() => setIsReady(true)}
    />
  </ChatSession>
</Elements>

That's the entire frontend chat implementation. The channelId is on the order record (created when the order is paid for), and the getToken prop hits /api/token, which mints a Whop access token from the user's whop_user_id (Strategy 1), an OAuth refresh token (Strategy 2), or a company-scoped fallback for sellers (Strategy 3). I wrote zero backend code for messaging - just the token endpoint.

Buyers and sellers get typing indicators, read receipts, file uploads, and emoji reactions. None of that is my code.

The KYC gate (the part I actually engineered)

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

A seller has to complete identity verification before they can publish a gig. Most apps enforce this with a UI check (disable the "Publish" button, show a tooltip) and a duplicate check in the API route. Both can be bypassed: the UI by anyone with a browser console, the API check by anyone who reads the route handler and forgets to update it when they add a new "create gig" surface six months later.

GigFlow enforces the rule in the database with a Postgres trigger:

create or replace function public.enforce_kyc_before_gig_publish()
returns trigger
language plpgsql
security definer
set search_path = public
as $$
declare
  kyc public.kyc_status;
begin
  if (TG_OP = 'INSERT' or TG_OP = 'UPDATE') then
    if new.status = 'published' then
      select s.kyc_status into kyc
      from public.seller_accounts s
      where s.user_id = new.seller_user_id;
      if kyc is null or kyc != 'verified' then
        raise exception 'Seller must complete KYC before publishing';
      end if;
    end if;
  end if;
  return new;
end;
$$;

create trigger trg_enforce_kyc_before_gig_publish
before insert or update of status
on public.gigs
for each row
execute function public.enforce_kyc_before_gig_publish();

Before any insert or status update on the gigs table, Postgres looks up the seller's kyc_status and rejects the operation if the seller isn't verified. It doesn't matter how the call got there - service role key, leaked admin endpoint, a future "approve gig in review" route someone forgets to lock down. The database is the last line of defense and it can't be bypassed from outside.

This pairs with Row Level Security for ownership. RLS handles "who can see what", but RLS by itself doesn't validate state transitions or cross-table invariants. The trigger fills that gap. Once you start writing rules at this layer, you stop worrying about whether some new API route accidentally shipped without the right authorization check.

I'd add similar triggers for any future "publish a thing" surface - a creator going public, a course going off draft. Defense in depth is a lot easier when the database is the floor.

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 and KYC state actually materialize in your database, so when it's broken the rest of the app silently lies to you. The verification.succeeded event is the canonical signal that a seller is allowed to publish - if your handler doesn't process it, the embedded <VerifyElement /> says they're verified but the database trigger says they're not, and you spend an hour figuring out why everything works locally but INSERT INTO gigs keeps throwing.

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 apps and re-entering credentials. Worth setting NEXT_PUBLIC_WHOP_ENVIRONMENT=sandbox and a sandbox API key before writing any code.

Specific to GigFlow: I'd nail down the order state machine before building any UI. Orders move through awaiting_requirements → in_progress → delivered → completed, with branches for revision_requested, cancel_requested, disputed, and refunded. Each transition has its own API route and a role check (only the buyer can request a revision, only the seller can deliver). Once the matrix is on paper, the UI is just buttons that POST to the right route. I built bits of it ad-hoc and ended up rewriting the order workspace twice.

Also: use the company API key, not the app API key. The company key has the permissions for companies.create with parent_company_id (creating a connected company for a seller). Same gotcha I ran into with the StockX clone, just a different SDK call.

Links

Demo: gigflow.vercel.app
Code: https://github.com/whopio/whop-tutorials/tree/main/fiverr-clone
Full tutorial: 13-step walkthrough on the Whop blog covering every file from scaffold to deploy
Whop developer docs: dev.whop.com

The Whop-specific code in the whole project is maybe 500 lines. Everything else is a normal Next.js app with Supabase. If you're building a marketplace where sellers need to get paid and KYC needs to happen before they can list anything, the Whop developer docs are worth looking at.

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

Doğukan Karakaş — Fri, 13 Mar 2026 16:10:52 +0000

I spent a few days building a StockX clone called Swaphause. Real-time bid/ask marketplace, escrow payments, seller identity verification, embedded buyer-seller chat per trade. It's a single Next.js project and the whole thing is on GitHub.

The matching engine and product pages were the parts I expected to be hard. They were interesting, but manageable, standard algorithms and React. What I was actually dreading was the marketplace infrastructure: escrow payments where funds are held until a product is authenticated, routing money to individual sellers, handling KYC so sellers can actually receive payouts, and building a real-time chat system so buyers and sellers can coordinate shipping. Those are the kinds of problems that turn a side project into a multi-month ordeal.

I ended up using Whop for all of it, connected accounts, KYC, escrow, webhooks, embedded chat, one SDK. I'll explain what I mean.

What's in the box

Swaphause is a bid/ask marketplace. Buyers place bids, sellers place asks, and when prices cross, a trade executes automatically. Here's what it does:

Bid/ask matching engine with automatic trade execution
Real-time pricing via Supabase Realtime
Escrow payments via Whop for Platforms (connected accounts, KYC, fee splits)
OAuth login through Whop (PKCE flow, iron-session cookies)
Seller identity verification (KYC) handled by Whop's hosted flow
Embedded buyer-seller chat per trade via Whop components
Product authentication/verification admin flow
Search, category filters, custom pagination
User dashboard with portfolio, active orders, trade history
In-app notifications for bids, payments, shipping

Stack: Next.js 15 (App Router), Prisma, Supabase, Whop SDK, Zod, deployed on Vercel.

It handles real money. You can deploy it and run a marketplace today.

How Whop made the hard parts easy

Escrow payments without being the merchant

This was the hardest problem. A marketplace like StockX doesn't just charge people, it holds funds in escrow until a product is verified as authentic, then pays the seller. If I'd built this from scratch I'd be dealing with payment holds, payout scheduling, refund logic, and compliance.

Whop's Direct Charge model handles the escrow pattern. The payment goes directly to the seller's connected account, the platform takes a percentage via application_fee_amount, and the funds are held until the product clears authentication. Swaphause is never the merchant of record.

Here's the checkout creation. This is the core of the payment system:

export async function createCheckoutForTrade(
  trade: TradeForCheckout
): Promise<CheckoutResult> {
  const checkoutConfig = await whopsdk.checkoutConfigurations.create({
    redirect_url: `${env.NEXT_PUBLIC_APP_URL}/api/trades/${trade.id}/payment-callback`,
    plan: {
      company_id: trade.seller.connectedAccountId,
      currency: "usd",
      initial_price: trade.price,
      plan_type: "one_time",
      application_fee_amount: trade.platformFee,
    },
    metadata: {
      tradeId: trade.id,
      buyerId: trade.buyerId,
      sellerId: trade.sellerId,
    },
  });

  return {
    checkoutUrl: checkoutConfig.purchase_url as string,
    checkoutId: checkoutConfig.id,
  };
}

That single SDK call creates a hosted checkout page. The company_id points to the seller's connected account, the application_fee_amount is Swaphause's cut (9.5%), and the metadata carries trade IDs through to the webhook so I know which trade got paid.

The money flow: buyer pays → funds held → seller ships → platform authenticates the item → if it passes, payout releases to the seller's account; if it fails, the buyer gets a full refund and the seller's ask reopens.

Sellers also need identity verification before they can receive payouts. That's two SDK calls:

// Create a connected account under the platform
const company = await whopsdk.companies.create({
  title: user.displayName || user.username,
  parent_company_id: env.WHOP_COMPANY_ID,
  email: user.email,
});

// Generate hosted KYC URL
const accountLink = await whopsdk.accountLinks.create({
  company_id: company.id,
  use_case: "account_onboarding",
  redirect_url: `${env.NEXT_PUBLIC_APP_URL}/dashboard`,
});

Whop hosts the entire KYC flow, identity documents, bank account linking, tax info. Swaphause doesn't see or store any of it.

On the webhook side, Whop sends payment.succeeded and payment.failed events. The handler verifies the signature with whopsdk.webhooks.unwrap(), does an idempotency check (so duplicate deliveries don't create duplicate records), and routes each event to the right database update. About 60 lines for the handler plus two event-specific functions, all wrapped in a single Prisma $transaction.

Auth without a password table

Same pattern as my Substack clone. Whop OAuth with PKCE replaces all the password hashing, email verification, reset tokens, and session management. Two API routes and a config object. The login route generates a PKCE challenge, stashes the verifier in an iron-session cookie, and redirects to Whop. The callback exchanges the code for a token, pulls the user profile, upserts them into Postgres, and sets the session.

One thing worth calling out: the WHOP_API_BASE env var controls sandbox vs. production for the entire app. Set it to https://sandbox-api.whop.com during development, https://api.whop.com when you go live. One toggle, everything switches.

Chat without building chat

Building a real-time messaging system means WebSocket servers, message persistence, connection state, moderation. Whop has embeddable chat components, so I skipped all of that:

import { ChatElement, ChatSession, Elements } from "@whop/embedded-components-react-js";
import { loadWhopElements } from "@whop/embedded-components-vanilla-js";

const elements = loadWhopElements({ environment: whopEnvironment });

async function getToken({ abortSignal }: { abortSignal: AbortSignal }) {
  const response = await fetch("/api/token", { signal: abortSignal });
  const data = await response.json();
  return data.token;
}

export function TradeChat({ channelId }: { channelId: string | null }) {
  if (!channelId) return <div>Chat available once trade is matched.</div>;

  return (
    <Elements elements={elements}>
      <ChatSession token={getToken}>
        <ChatElement
          options={{ channelId }}
          style={{ height: "500px", width: "100%" }}
        />
      </ChatSession>
    </Elements>
  );
}

Each trade gets a DM channel auto-created when a bid matches an ask. The matching engine calls Whop's DM channel API, stores the chatChannelId on the trade, and sends an initial system message. Buyers and sellers can coordinate shipping details without leaving the app. I wrote zero backend code for messaging.

The matching engine (the part I actually engineered)

This is probably the most interesting piece from a pure engineering standpoint. When a new bid comes in, the engine needs to find the lowest ask at or below the bid price and execute a trade. The tricky part: two concurrent bids could try to match the same ask.

The solution is a double-check-inside-transaction pattern:

// Fast path, check outside transaction
const matchingAsk = await prisma.ask.findFirst({
  where: {
    productSizeId: bid.productSizeId,
    status: "ACTIVE",
    price: { lte: bid.price },
  },
  orderBy: { price: "asc" },
});

if (!matchingAsk) return null;

// Safe path, re-validate inside transaction
const trade = await prisma.$transaction(async (tx) => {
  const ask = await tx.ask.findFirst({
    where: {
      id: matchingAsk.id,
      status: "ACTIVE",
    },
  });
  if (!ask) return null;

  const freshBid = await tx.bid.findUnique({
    where: { id: bid.id, status: "ACTIVE" },
  });
  if (!freshBid) return null;

  // Trade executes at the ask price (seller's price)
  const tradePrice = ask.price;
  const platformFee = tradePrice * (PLATFORM_FEE_PERCENT / 100);

  // Mark both as matched, create trade, update product stats
  await tx.bid.update({ where: { id: bid.id }, data: { status: "MATCHED" } });
  await tx.ask.update({ where: { id: ask.id }, data: { status: "MATCHED" } });

  return tx.trade.create({
    data: {
      buyerId: bid.userId,
      sellerId: ask.userId,
      productSizeId: bid.productSizeId,
      bidId: bid.id,
      askId: ask.id,
      price: tradePrice,
      platformFee,
      status: "MATCHED",
    },
  });
});

Check outside the transaction first (fast path, avoids locking when there's no match), then re-validate inside the transaction (safe path, guarantees no two bids match the same ask). The trade always executes at the ask price, same as StockX.

Things I'd do differently

I'd build the webhook handler first. Same lesson I learned building the Substack clone. It's the most important code in the project because it's where payment state materializes in your database. If it's broken, people pay but your app doesn't know.

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 your app and re-entering all your credentials.

One thing specific to this project: Whop's sandbox doesn't deliver real webhook events. I ended up building a payment callback route as a fallback, after checkout, Whop redirects the buyer to a callback URL with a payment_id param, and the callback verifies payment status directly with the API. Build that from the start instead of debugging why your webhook never fires in sandbox.

Also: use the company API key, not the app API key. The company key has the permissions needed for company:create_child (creating connected accounts for sellers). I burned time on 403 errors before figuring that out.

Links

Demo: stockx-clone-zeta.vercel.app
Code: github.com/east-6/stockx-clone
Full tutorial: 3-part walkthrough on the Whop blog covering every file from scaffold to deploy
Whop developer docs: dev.whop.com

The Whop-specific code in the whole project is maybe 400 lines. Everything else is a normal Next.js app. If you're building a marketplace where sellers need to get paid and products need authentication before payout, the Whop developer docs are worth looking at.

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

Doğukan Karakaş — Mon, 09 Mar 2026 11:32:09 +0000

I spent the last few weeks building a Substack clone called Penstack. Rich text editor, paid subscriptions where money goes directly to writers, OAuth login, embedded chat per publication.

The editor and publication pages were the parts I thought would be hard. They weren't, honestly. Standard React. What I was dreading was the payments layer: routing money to individual creators, handling identity verification, dealing with tax stuff. And then building a chat system on top of that. Those are the kinds of features that turn a weekend project into a quarter-long slog.

I ended up using Whop for all of it, and most of those problems just... went away. I'll explain what I mean.

What's in the box

Penstack is a multi-writer publishing platform. Readers browse, subscribe to writers, and get access to paid content. Writers get a rich text editor, an analytics dashboard, and a chat channel for their community. Here's what it does:

Rich text editor (Tiptap) with images, code blocks, formatting, links
Custom paywall break: writers drop a marker anywhere in a post, and everything below it is gated
Paid subscriptions via Whop Direct Charges. Money goes to the writer, Penstack takes 10%
OAuth login through Whop (PKCE flow, iron-session cookies)
Identity verification (KYC) for writers, handled by Whop's hosted flow
Embedded chat per publication using Whop's React components
Explore page with trending writers and category filters
Notifications for follows, subscriptions, and payments
Writer dashboard with subscriber/follower/view counts

Stack: Next.js 15 (App Router), Prisma 7, Supabase for Postgres, Tiptap for the editor, Whop SDK, UploadThing for images, deployed on Vercel.

It handles real money. You can deploy it and charge people 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 token generation and expiration, session management, CSRF protection. It takes a while and it's never fun. The Whop OAuth setup replaced all of that with two API routes and a config object.

The whole OAuth config:

const isSandbox = process.env.WHOP_SANDBOX === "true";
const whopDomain = isSandbox ? "sandbox.whop.com" : "whop.com";
const whopApiDomain = isSandbox ? "sandbox-api.whop.com" : "api.whop.com";

export const WHOP_OAUTH = {
  authorizationUrl: `https://${whopDomain}/oauth`,
  tokenUrl: `https://${whopApiDomain}/oauth/token`,
  userInfoUrl: `https://${whopApiDomain}/oauth/userinfo`,
  clientId: process.env.WHOP_CLIENT_ID!,
  clientSecret: process.env.WHOP_CLIENT_SECRET!,
  scopes: ["openid", "profile", "email"],
  redirectUri: `${process.env.NEXT_PUBLIC_APP_URL}/api/auth/callback`,
};

The login route generates a PKCE challenge, stashes the verifier in an iron-session cookie, and redirects to Whop. The callback exchanges the authorization code for a token, pulls the user profile from /oauth/userinfo, upserts them into Postgres, and sets the session. That's it. No password table, no token rotation, no "forgot password" flow.

One thing I really like: the WHOP_SANDBOX toggle. Set it to true during development and every OAuth call hits the sandbox environment instead of production. When you're ready to go live, just remove it.

Payments in about 100 lines

This was the feature I was most nervous about. If I'd gone the Stripe Connect route, I'd be building account onboarding flows, managing payout schedules, handling currency edge cases for different countries. That alone could eat weeks.

Whop's Direct Charge model skips most of that complexity. The payment goes directly to the writer's connected account, and Penstack takes a 10% application fee. Penstack is never the merchant of record, which means I'm not on the hook for refunds, chargebacks, or international tax compliance.

Here's the checkout route. This is the core of the whole payments system:

const priceInCents = writer.monthlyPriceInCents ?? 0;
const priceInDollars = priceInCents / 100;
const applicationFee =
  Math.round(priceInCents * PLATFORM_FEE_PERCENT) / 10000;

const checkout = await whop.checkoutConfigurations.create({
  plan: {
    company_id: writer.whopCompanyId,
    currency: "usd",
    renewal_price: priceInDollars,
    billing_period: 30,
    plan_type: "renewal",
    release_method: "buy_now",
    application_fee_amount: applicationFee,
    product: {
      external_identifier: `penstack-writer-${writer.id}`,
      title: `${writer.name} Subscription`,
    },
  },
  redirect_url: `${process.env.NEXT_PUBLIC_APP_URL}/${writer.handle}`,
  metadata: { userId: user.id, writerId: writer.id },
});

return NextResponse.json({ url: checkout.purchase_url });

That single SDK call creates the plan, the product, and a hosted checkout page. The application_fee_amount field is where Penstack takes its cut. The metadata carries user and writer IDs through to the webhook so I know who subscribed to whom.

The subscriber flow looks like this: they click "Subscribe," my server creates the checkout config, Whop hosts the actual payment page, and after payment succeeds Whop fires a membership.activated webhook. My handler picks that up and creates the subscription record in Postgres.

Writers also need identity verification before they can accept payments. That's two more SDK calls:

// Create a connected account under the platform
const company = await whop.companies.create({
  title: writer.name,
  parent_company_id: process.env.WHOP_COMPANY_ID!,
  email: writer.user.email,
});

// Generate hosted KYC URL
const setupCheckout = await whop.checkoutConfigurations.create({
  company_id: company.id,
  mode: "setup",
  redirect_url: `${process.env.NEXT_PUBLIC_APP_URL}/settings`,
});

Whop hosts the whole KYC flow. Identity documents, bank account linking, tax info. Penstack doesn't see or store any of it.

On the webhook side, Whop sends events like payment.succeeded and membership.activated. The webhook handler verifies the signature, does an idempotency check (so duplicate deliveries don't create duplicate records), and routes each event type to the right database update. About 60 lines for the handler plus four event-specific functions.

Chat without building chat

I was fully prepared to skip this feature. Building a real-time chat system means WebSocket servers, message persistence, connection state management, moderation tooling. It's a ton of infrastructure for something that isn't core to a publishing platform.

But Whop has embeddable chat components, so I tried them:

import { Elements } from "@whop/embedded-components-react-js";

<Elements elements={elements}>
  <ChatSession token={getToken}>
    <ChatElement
      options={{ channelId }}
      style={{ height: "500px", width: "100%" }}
    />
  </ChatSession>
</Elements>

That's the whole chat implementation on the frontend. Each writer's publication has a channelId, and the token prop grabs the user's OAuth access token from a lightweight API endpoint. Writers can also set their chat to subscriber-only with a boolean toggle. I wrote zero backend code for messaging.

The paywall break (the part I actually engineered)

This is probably the most interesting piece from a pure engineering standpoint. Substack gives you a binary choice: a post is free or it's paid. Penstack lets writers place the paywall break wherever they want in a post. Write three paragraphs of free preview to hook the reader, then drop the break, and everything after it requires a subscription.

It's a custom Tiptap node, defined as an atom in the block group so it sits between paragraphs like a horizontal rule:

import { Node, mergeAttributes } from "@tiptap/core";

export const PaywallBreak = Node.create({
  name: "paywallBreak",
  group: "block",
  atom: true,

  parseHTML() {
    return [{ tag: 'div[data-type="paywall-break"]' }];
  },

  renderHTML({ HTMLAttributes }) {
    return [
      "div",
      mergeAttributes(HTMLAttributes, {
        "data-type": "paywall-break",
        class: "paywall-break",
      }),
      "Content below is for paid subscribers only",
    ];
  },

  addCommands() {
    return {
      setPaywallBreak:
        () =>
        ({ commands }) => {
          return commands.insertContent({ type: this.name });
        },
    };
  },
});

Writers insert it from the toolbar (there's a lock icon) or with Cmd+Shift+P. In the editor it renders as a visible divider with a label.

The server-side part is dead simple. When saving a post, the client scans the Tiptap JSON for the break's position:

let paywallIndex: number | undefined;
if (content?.content) {
  const idx = content.content.findIndex(
    (node) => node.type === "paywallBreak"
  );
  if (idx !== -1) paywallIndex = idx;
}

That index gets stored on the post record. When a non-subscriber loads the article, the server slices the content array at that position and only sends back what's above the break. The node itself doesn't know anything about pricing or subscription status. It's just a position marker. All the access control happens on the server.

Things I'd do differently

I'd build the webhook handler first if I started over. It's the most important code in the project because it's where payment state actually materializes in your database. If the webhook handler is 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. Lesson learned.)

I'd also use the Whop sandbox (sandbox.whop.com) from the very beginning. I started on production and switched to sandbox later, which meant recreating my app and re-entering all my credentials again. Starting on sandbox and switching to production when you're ready is way smoother.

The other thing: if you're deploying to Vercel with Supabase, use the Vercel integration instead of setting up Supabase manually. It populates your connection strings automatically, and you avoid the whole "which pooler port do I use" confusion. (Transaction mode on port 6543 for your app, session mode on port 5432 for Prisma migrations. I mixed them up more than once.)

Links

Demo: penstack-fresh.vercel.app
Full tutorial: 7-part walkthrough on the Whop blog covering every file from scaffold to deploy
Whop developer docs: dev.whop.com

The Whop-specific code in the whole project is maybe 300 lines. Everything else is a normal Next.js app. If you're building something where creators need to get paid, the Whop developer docs are worth looking at.