Whop Checkout via MCP

Safe checkout workflow

Checkout has two layers: implementation code and live Whop account state. MCP is useful because it can compare both, but it should not jump straight to creation.

1. Ask Docs MCP for the checkout implementation path and current component props.
2. Inspect app code for plan_ IDs, sessionId, return URLs, embed props, and environment variables.
3. Use API MCP read-only tools to list products, plans, checkout configurations, setup intents, and payment methods.
4. Compare live resources to the codebase and identify mismatches.
5. Draft a checkout configuration, embed change, or debugging plan.
6. Approve only after seeing exact arguments and customer-facing effects.

Checkout primitives

Inspect checkout without modifying data

Most checkout bugs can be diagnosed before creating or updating anything. Start with a read-only inventory that connects product names to plan IDs and customer-facing URLs.

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, affiliate code, and environment.
Do not create, update, archive, delete, refund, retry, or message anything.

Use the result to catch stale plan_ IDs, inactive plans, checkout links pointing to the wrong product, missing metadata, sandbox/production mismatches, or affiliate attribution that never reaches checkout.

Create a checkout configuration draft

A checkout configuration can be valuable, but it is a write action. Make the agent draft the JSON first, then approve the tool call only after reviewing the customer-facing effect.

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.

{
  "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"
}

A successful create call returns a checkout configuration ID and a customer-facing purchase URL. Whop documents checkout configuration IDs with a ch_ prefix and purchase URLs in the shape /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"
}

Embedded checkout

Whop documents a React checkout embed package and a WhopCheckoutEmbed component. MCP can help find the right plan or session, but the generated embed should still go through code review.

Simple plan-based embed

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

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

Session-based embed

Use sessionId when your flow creates or retrieves a checkout session/configuration first and needs metadata or other server-side context to travel with checkout.

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

export function CheckoutPage() {
  return (
    <WhopCheckoutEmbed
      sessionId="ch_xxxxxxxxxxxxxxx"
      returnUrl="https://example.com/checkout/complete"
      theme="system"
      skipRedirect
      onComplete={(planId, receiptId) => {
        console.log(planId, receiptId);
      }}
    />
  );
}

Embed prop checklist

Use this as a planning checklist, not as the final component reference. Before shipping, compare the generated code against Whop's checkout embed docs.

Webhook context after checkout

Checkout UI callbacks are useful, but server-side fulfillment should rely on verified webhook events. Whop's webhook guide documents signature verification and common events such as payment.succeeded, membership.activated, and setup-intent events.

Inspect the Whop webhook handler for checkout fulfillment.
Confirm it verifies signatures, returns 2xx quickly, handles duplicate delivery, and treats embed callbacks as UI state rather than final fulfillment proof.
Do not edit the handler yet.

Affiliate attribution

Whop affiliate attribution can appear in links and checkout/API fields. Keep attribution explicit so you can tell whether traffic came from a partner link, embedded checkout, or an MCP-created checkout configuration.

Approval prompt for write actions

Use this before approving checkout creation, checkout updates, promo code changes, payment retries, or anything that can affect a customer purchase.

Before calling a write-capable Whop checkout tool, show:
1. Exact tool name
2. Exact JSON arguments
3. Target company, product, plan, checkout configuration, payment, or promo code
4. Customer-facing effect
5. Whether this is sandbox or production
6. Required permissions
7. Rollback or cleanup path

Wait for approval before calling the tool.

FAQ

Related Whop MCP guides

• Whop MCP tools reference
• Whop API keys for MCP
• Whop API permissions for MCP
• Whop MCP checkout docs guide
• Whop MCP troubleshooting

Official checkout references

• Create checkout configuration
• Whop checkout embed
• Whop webhooks