DEV Community: Doğukan Karakaş

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.