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.