Checkout Page platform help — no-code Stripe-based hosted checkout builder (checkoutpage.com) for digital products, subscriptions, payment plans, pay-what-you-want, and event tickets, with order bumps, 1-click upsells, cart-abandonment recovery, and form/lead capture; a REST API (api.checkoutpage.com/v1, Bearer auth, cursor pagination), conversion webhooks, and a native MCP server for AI assistants. Use when setting up a Checkout Page checkout or event-ticket page, syncing Checkout Page payments or subscriptions into a CRM or warehouse, verifying or backing up the unsigned conversion webhook, building a paid checkout via the Checkout Page MCP, choosing between the Launch and Grow plans or forecasting the sales-volume cap, or troubleshooting Stripe-only limits and owning your own tax (not a Merchant of Record). Do NOT use for checkout-conversion strategy across carts (use /sales-checkout) or picking a Merchant of Record for global tax (use /sales-merchant-of-record).
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Checkout Page platform help — no-code Stripe-based hosted checkout builder (checkoutpage.com) for digital products, subscriptions, payment plans, pay-what-you-want, and event tickets, with order bumps, 1-click upsells, cart-abandonment recovery, and form/lead capture; a REST API (api.checkoutpage.com/v1, Bearer auth, cursor pagination), conversion webhooks, and a native MCP server for AI assistants. Use when setting up a Checkout Page checkout or event-ticket page, syncing Checkout Page payments or subscriptions into a CRM or warehouse, verifying or backing up the unsigned conversion webhook, building a paid checkout via the Checkout Page MCP, choosing between the Launch and Grow plans or forecasting the sales-volume cap, or troubleshooting Stripe-only limits and owning your own tax (not a Merchant of Record). Do NOT use for checkout-conversion strategy across carts (use /sales-checkout) or picking a Merchant of Record for global tax (use /sales-merchant-of-record).
argument-hint
[describe what you need help with in Checkout Page]
Checkout Page (checkoutpage.com) is a no-code, Stripe-based hosted checkout builder for
creators and small teams: branded checkout pages for digital products, subscriptions, payment
plans, pay-what-you-want, and event tickets, plus form/lead capture — with order bumps,
1-click upsells, and cart-abandonment recovery. 0% platform transaction fees, but it is
not a Merchant of Record (runs on your Stripe account → you own tax). Its edge is that forms,
checkout, events, and customers share one REST API + native MCP server.
Step 1 — Gather context
If references/learnings.md exists, read it first for accumulated platform knowledge.
Ask only what you can't infer from the user's prompt:
What are you trying to do?
A) Integrate Checkout Page data (payments/subscriptions/customers) with a CRM, warehouse, or app
B) Set up or debug the conversion webhook
C) Build/query checkouts, forms, or coupons via the native MCP server
D) Configure a checkout, event-ticket page, upsell, or form in the product
E) Decide on a plan (Launch vs Grow vs Enterprise) or understand fees/caps
Do you have your API key / Stripe connected? The API key comes from the dashboard; the MCP
connects via OAuth and needs a Stripe-connected account.
Skip-ahead rule: if the user's prompt already has enough context, go straight to Step 2.
Step 2 — Route or answer directly
If the user's question is about…
Route to
Which cart/checkout platform to pick, or checkout-conversion strategy across tools (bump/upsell design, cart abandonment)
Choosing a Merchant of Record for global tax/VAT (Checkout Page is NOT one)
/sales-merchant-of-record {question}
Migrating active subscriptions between billing platforms without double-billing
/sales-subscription-billing {question}
Running an affiliate program (Checkout Page integrates Rewardful/Tolt)
/sales-affiliate-program {question}
When routing, give the exact command: "This is a {domain} question — run: "
/sales-checkout {original question}
Otherwise, answer Checkout Page-specific questions directly using Step 3.
Step 3 — Checkout Page platform reference
Read references/platform-guide.md for the full reference — capabilities & automation
surface (what's API-, webhook-, MCP-accessible vs UI-only), pricing/plan gates and the
sales-volume cap, data model (decimal-string money, Stripe id cross-reference), and quick-start
recipes (webhook listener, nightly incremental pull, MCP event-checkout build).
For raw endpoint detail, auth, pagination, rate limits, verbatim conversion webhook payloads,
and MCP tool list, read references/checkoutpage-api-reference.md.
Answer using only the relevant section — don't dump the full reference.
Step 4 — Actionable guidance
Treat the webhook as a hint, the API as truth. Register a store-level webhook (fires for
every page) and branch on object — payment, subscription, or submission — to route
each conversion type. The conversion payload has no documented HMAC signature or retry
policy — post to a tokenized/unguessable endpoint URL, re-fetch the object by id via the REST
API before provisioning access or moving money, dedupe on orderId, and keep a polling backup.
Re-check the live docs for a signing scheme before trusting deliveries.
Parse money as a decimal string, not cents. Amounts arrive as "23.99" in the display
currency — unlike SamCart/Sellfy (cents). Read Stripe object ids (stripePaymentId,
stripeSubscriptionId, stripeCustomerId) straight from the payload to reconcile in Stripe.
Say it's not a Merchant of Record. Checkout Page runs on the user's own Stripe account, so
they are the seller of record and own sales-tax/VAT (Stripe Tax can calculate). For global
tax handled for them, point to /sales-merchant-of-record.
Model the sales-volume cap, not features. ~99% of features are on every plan; plans differ
mainly by monthly sales volume, support, and custom domains — forecast expected sales when
choosing Launch vs Grow. Present all pricing as best-effort and tell the user to verify current
numbers at checkoutpage.com/pricing.
Reach for the native MCP for build/query tasks.claude mcp add --transport http checkoutpage https://mcp.checkoutpage.com then /mcp to authenticate — because forms + Stripe checkout share
one MCP (13 tools), an agent can build a paid event-registration page end-to-end from a prompt.
Respect the rate limits. 500 req/min per store, 100 req/min per key → on 429, back off and
resume from the last cursor (starting_after = last id); keep bulk pulls incremental.
If you discover a gotcha or tip not in references/learnings.md, append it there with today's date.
Gotchas
Best-effort from research (2026-07) — review these, especially plan pricing/caps and the
webhook-signature status, which may have changed.
Conversion webhooks appear unsigned — no documented HMAC header, signing secret, or retry
policy. Tokenize the endpoint URL, verify by re-fetching via the API, and keep a polling backup.
Money is a decimal string in the display currency ("23.99"), not cents — don't divide by 100.
Stripe-only. Payments run exclusively through Stripe; there's no PayPal/other-gateway option.
If the user needs an alternate processor, this is a hard limit — flag it early.
Not a Merchant of Record — the seller owns VAT/GST/sales tax (Stripe Tax available).
Volume-cap pricing. Crossing a plan's monthly sales ceiling forces an upgrade; features are
mostly not gated — forecast sales, not features.
trailStart is a vendor typo in the subscription payload (trial start); trialEnd is
spelled correctly. Read fields exactly as sent.
Docs are partly JS-rendered and show both REST (GET /v1/checkout-pages) and action
(/v1/checkout-pages/list) path styles — confirm the exact spelling against live docs before coding.
Related skills
/sales-checkout — Checkout-page strategy and cart-platform selection (Checkout Page vs ThriveCart vs SamCart vs Gumroad; bumps, upsells, cart abandonment)
/sales-merchant-of-record — Choosing a Merchant of Record for global tax (Checkout Page is not one)
/sales-subscription-billing — Subscription billing engines and migrating active subscribers without double-billing
/sales-samcart — SamCart platform help (the subscription-priced dedicated cart, feature-gated instead of volume-capped)
/sales-thrivecart — ThriveCart platform help (the lifetime-license cart alternative)
/sales-affiliate-program — Affiliate program strategy (Checkout Page integrates Rewardful/Tolt)
/sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do -a claude-code
Examples
Example 1: Sync Checkout Page sales into a CRM (developer/automation)
User says: "How do I get every Checkout Page sale and subscription into HubSpot automatically?"
Skill does: Sets up a store-level webhook at a tokenized URL, branches on object
(payment/subscription/submission), ignores livemode:false in production, and — because the
payload is unsigned — re-fetches the customer/payment by id via GET /v1/customers/{id} before
upserting; parses amount as a decimal string, maps queryParameters UTMs for attribution, and
adds a nightly cursor-paginated GET /v1/payments reconciliation pull (per the platform-guide recipes).
Result: HubSpot stays in sync with verified data even if an unsigned webhook is missed or spoofed.
Example 2: Build a paid event-registration page from a prompt (MCP)
User says: "Can I make a ticketed workshop checkout with an attendee name and dietary field without clicking around?"
Skill does: Walks them through claude mcp add --transport http checkoutpage https://mcp.checkoutpage.com
/mcp OAuth, then prompts the agent to call create_checkout_page for the ticket, create_form
for the attendee fields, and create_coupon for a launch code — noting forms + Stripe checkout
share one MCP so the whole flow runs in chat.
Result: A live paid event page with custom fields, built end-to-end from a single prompt.
Example 3: Launch vs Grow plan decision
User says: "I'm doing about $8K/mo in digital sales — is Checkout Page's Launch plan enough or do I need Grow?"
Skill does: Flags that Launch caps around ~$3K/mo in sales while $8K/mo lands in a Grow volume
tier, so the cap — not features (which are ~all shared) — forces the choice; notes 0% platform fees
(Stripe's ~2.9%+30¢ still applies) and presents pricing as best-effort to verify at checkoutpage.com/pricing.
Result: User picks Grow from their sales volume, not feature FOMO.
Troubleshooting
The conversion webhook fired but I don't trust it (or it never arrived)
Symptom: Payloads look spoofable, occasionally missing, or contain test data in production.
Cause: No documented HMAC signature or retry policy; livemode:false events come from the
dashboard "Test payments" tool; there's no documented delivery log.
Solution: Put a secret token in the endpoint URL path, verify every payload by re-fetching the
object via the REST API, drop livemode:false in prod, return 200 fast, dedupe on orderId, and
reconcile nightly with a cursor-paginated GET /v1/payments pull.
401 Unauthorized on every API call
Symptom: All requests fail with 401 even with a key.
Cause: Key not sent as a Bearer token, or generated for the wrong store/environment.
Solution: Send Authorization: Bearer YOUR_API_KEY over HTTPS with a key generated in the
dashboard for the correct store. For the MCP, authenticate via OAuth (/mcp) on a Stripe-connected account.
429 Too Many Requests on a bulk export
Symptom: Large payment/customer pulls start returning 429.
Cause: 500 req/min per store, 100 req/min per API key.
Solution: Back off on 429 (exponential, start ~1–2s) and resume from the last cursor
(starting_after = last object id); page at limit=100; keep pulls incremental rather than
re-reading history.
