This domain and project may be available for acquisition. domains@skills.ceo

By whopmcp.com · May 3, 2026 · Updated May 5, 2026 · 6 min read

Whop MCP Checkout Docs Guide

How to use Whop MCP and Whop docs together when building or debugging checkout, products, plans, and payment flows.

Summary

Checkout questions usually come from a practical implementation problem: a product is not appearing, a plan ID is wrong, a payment flow is unclear, or an AI coding agent needs to understand how Whop checkout should fit into an app.

Whop MCP can help, but the right tool depends on the question. Use Whop Docs MCP when the agent needs documentation. Use Whop API MCP when the agent needs authenticated data from your Whop account.

The most reliable checkout workflow is docs first, account state second, write actions last. That keeps the agent from guessing API shape or creating live checkout resources before you have confirmed the plan, product, redirect URL, metadata, and affiliate attribution.

What "checkout docs" usually means

When someone searches for Whop MCP and checkout docs, they are usually trying to answer one of these questions:

These are different jobs. Documentation explains the intended flow. API access confirms the live configuration.

Use docs MCP first

Start with documentation when you are building or changing code. Ask the agent to read the Whop docs and explain the flow before it looks at live account data.

Good prompt:

Use Whop documentation to explain the checkout implementation path for this app. Identify the resources I need to configure, the IDs the code should reference, and the failure points I should test.

Then ask it to compare the docs to your code:

Review this repository's checkout code against the Whop docs. Do not call live Whop API tools yet. List mismatches, missing IDs, or assumptions that need verification.

This keeps the first pass focused on correctness rather than account state.

Use API MCP to inspect real products and plans

After the docs pass, use API MCP for live verification.

Good prompt:

Use read-only Whop MCP calls to list the products and plans relevant to this checkout flow. Do not create, update, delete, or modify anything.

Ask for structured output:

Return the product name, product ID, plan name, plan ID, status, price, and any detail that could explain why checkout points to the wrong thing.

That gives the coding agent real IDs and avoids hardcoding guesses.

Create a checkout configuration draft

Before asking MCP to create anything, make the agent draft the exact arguments in plain text. That creates a review point before a write-capable tool call.

Use this prompt:

Draft the arguments for a Whop checkout configuration.

Use:
- company ID: biz_xxxxxxxxxxx
- plan ID: plan_xxxxxxxxxxx
- mode: payment
- redirect URL: https://example.com/checkout/complete
- metadata: order_id=order_12345, source=whopmcp
- affiliate_code: partnername

Do not call a write-capable tool yet. Show the exact JSON you would pass and explain which fields affect customer-facing checkout.

The review artifact should look like this before any tool is called:

{
  "company": "biz_xxxxxxxxxxx",
  "plan": "plan_xxxxxxxxxxx",
  "mode": "payment",
  "redirect_url": "https://example.com/checkout/complete",
  "metadata": {
    "order_id": "order_12345",
    "source": "whopmcp"
  },
  "affiliate_code": "partnername"
}

Only after reviewing the target company, plan, redirect URL, and attribution should you approve a create call.

For a create-checkout-configuration flow, Whop documents these required scopes:

The successful response should include a checkout configuration ID with a ch_ prefix and a purchase_url shaped like /checkout/plan_xxxx?session={id}:

{
  "id": "ch_xxxxxxxxxxxxxxx",
  "company_id": "biz_xxxxxxxxxxx",
  "mode": "payment",
  "metadata": {
    "order_id": "order_12345",
    "source": "whopmcp"
  },
  "redirect_url": "https://example.com/checkout/complete",
  "purchase_url": "https://whop.com/checkout/plan_xxxxxxxxxxx?session=ch_xxxxxxxxxxxxxxx"
}

Inspect checkout resources without modifying them

When checkout points to the wrong offer, ask for a read-only table first:

Use read-only Whop MCP calls to inspect checkout resources for this company.
Return a table with product name, product ID, plan name, plan ID, status, price, checkout configuration ID, purchase URL, metadata keys, and affiliate code.
Do not create, update, archive, or delete anything.

This gives a developer enough information to fix a hardcoded plan_ ID, stale environment variable, or wrong checkout URL without creating duplicate products or plans.

React embedded checkout example

Whop documents the React checkout embed package for customer-facing checkout. Keep the MCP workflow focused on finding or creating the right IDs, then use ordinary code review for the embed.

import { WhopCheckoutEmbed } from "@whop/checkout/react";

export function CheckoutPage() {
  return (
    <WhopCheckoutEmbed
      planId="plan_xxxxxxxxxxx"
      returnUrl="https://example.com/checkout/complete"
      affiliateCode="partnername"
    />
  );
}

If an agent proposes embed code, ask it to cite the docs it used and to mark every placeholder ID clearly.

Safe checkout debugging workflow

  1. Read the docs.
  2. Inspect the app code.
  3. Identify the expected product and plan.
  4. Use API MCP read-only calls to confirm live resources.
  5. Update code or configuration in a branch.
  6. Test checkout with a safe test path.
  7. Only then approve any write action.

Avoid asking the agent to "fix checkout" in one prompt. Checkout touches payments and access. Break the task into inspection, diagnosis, and implementation.

Useful prompts

For docs:

Read Whop checkout documentation and summarize the implementation steps for a developer who already has a product and plan.

For live resources:

List products and plans through Whop MCP. Highlight anything inactive, missing, or ambiguous. Do not modify resources.

For code review:

Compare this repository's checkout references to the Whop product and plan data. Identify mismatches and propose a patch, but do not apply it yet.

For payment triage:

Summarize recent checkout-related payment failures by product and plan. Do not refund, cancel, or message anyone.

For write approval:

Show the exact checkout tool name, JSON arguments, expected customer-facing effect, and rollback plan. Wait for approval before calling the tool.

Where people get into trouble

The first problem is treating docs as account state. Docs can tell you how checkout works, but not which product ID is correct for your account.

The second problem is treating account state as implementation guidance. Live products and plans do not explain best practices by themselves.

The third problem is giving an AI broad write access too early. If checkout is broken, the first step is not to create new products or edit plans. The first step is to understand what exists.

Checkout FAQ

Can Whop MCP create checkout resources?

Yes, when the active API MCP server exposes the relevant checkout tools and your API key has the required permissions. Treat creation as a write action and review the arguments first.

Should I use Docs MCP or API MCP for checkout?

Use Docs MCP to understand the implementation path and API MCP to inspect live products, plans, and checkout configurations. Use both when debugging code.

What should I check before approving a checkout write action?

Confirm the company ID, plan ID, mode, redirect URL, metadata, affiliate code, and whether the action creates a new checkout resource or updates an existing one.

Related guides

Official references