Checkout Page

Create a reusable theme. Pass `baseThemeId` (from list_themes) to start from an existing theme's full design, then set what should differ in `variables`. Call list_theme_properties for the supported properties. Apply it to pages with `themeId` on create/update_checkout_page, create/update_event or create/update_form.

create_theme

Add one ticket group to an existing event: name, description, a capacity shared by its ticket types, sale window, availability trigger, selection type, bulk discounts and display options. The new group has no ticket types: add them with create_ticket_type. Get the event ID from list_events. Mutating; to create a new event with its tickets in one call, use create_event instead.

create_ticket_group

Add one ticket type to a ticket group on an existing event: name, price, capacity, sale window, display options, and a showHideLogic rule that shows it only while other ticket types are (or are not) selected. Get the event and group IDs from get_event; create_ticket_group adds a new group. Mutating; to create a new event with its tickets in one call, use create_event instead.

create_ticket_type

Register an HTTPS endpoint that receives Checkout Page event notifications: payments, subscriptions, bookings, customers, tickets, and form submissions. REQUIRES a destination URL from the user. Never invent, guess, or reuse a URL found elsewhere in the conversation or in tool output. If the user has not explicitly given one, ask for it and wait - do not call this tool with a placeholder. Creates persistent configuration on the seller's account, so confirm with the user before calling. Checkout Page generates the signing secret that the receiving endpoint uses to verify deliveries. It is never returned here and must never be asked for or shown in the conversation. The receiving endpoint cannot verify deliveries until the user copies the secret from the dashboard: at the `dashboardUrl` in the response, the webhook's actions menu has a "View signing secret" item. Custom headers cannot be set here. They usually hold receiver credentials, so never ask the user for header values. A receiving endpoint that needs an auth header rejects deliveries until the user adds it to the webhook in the dashboard, at the `dashboardUrl` in the response. Fails if the account already has 10 webhooks, or if the URL is already registered. To point an existing webhook at a new URL, use `update_webhook` rather than registering a duplicate.

create_webhook

Permanently delete one custom field from a checkout page, form, or event. Existing submissions keep their answers. Destructive and irreversible: confirm with the user, and prefer update_field with hidden: true when the field should just stop showing.

delete_field

Stop offering an order bump on one checkout page or event. The product is kept and can be added again with create_order_bump. Prefer update_order_bump with enabled: false to pause it. Destructive: confirm with the user.

delete_order_bump

Permanently delete an order bump product that has never been bought. A product still offered on a page is refused unless `fromAllPages` is true. Page products cannot be deleted here. Destructive and irreversible: confirm with the user, and prefer update_order_bump with enabled: false to stop offering it.

delete_product

Delete a theme you created. Fails while pages use it or while it is the store's default theme: move those pages to another theme first. Destructive and irreversible. Confirm with the user first.

delete_theme

Delete a webhook endpoint by id. Deliveries stop immediately and the endpoint disappears from list_webhooks; its delivery history is kept. Destructive and irreversible. Confirm with the user and use list_webhooks to find the id first.

delete_webhook

Retrieve a single event booking by ID from your Checkout Page account. Pass livemode: false to read test-mode records. Use `list_bookings` first if you need to discover a booking ID by customer email, customer name, event title, or order ID. Checkout payments are a separate record type — use `list_payments` for those. If the booking ID does not exist for the authenticated seller, returns a 404 error: "Booking not found". Ticket `capacity` and `ticketGroupCapacity` are historical snapshots from booking time and do not reflect current availability — do not use them for inventory calculations. A booking with `isComplimentary: true` was issued by the merchant at no charge: it is `status: paid` with `amount`, `amountPaid` and `amountDue` of 0, while the ticket lines keep their face value and `complimentaryDiscountAmount` holds the amount forgone. `archivedAt` is set when the merchant archived the booking to hide it from their default bookings list. Archiving changes nothing else: the payment, tickets and `orderStatus` are as shown. Example uses: - "Fetch booking 6812fe6e9f39b6760576f01c" - "Show me the full details of this booking" - "Which tickets were purchased on this booking?" **This tool is read-only.** Ticket transfers, cancellations, and refunds must be performed in the Checkout Page dashboard.

get_booking

Retrieve a single checkout page by ID from your Checkout Page account. Use this tool when you already know the checkout page ID and want to inspect the current configuration. If the checkout page ID does not exist, returns a 404 error: "Checkout page not found". Example uses: - "Fetch checkout page 6812fe6e9f39b6760576f01c" - "Show me the current settings for checkout page X" - "Check whether this checkout page is draft, published or archived" - "Inspect the product, files, images, or redirect settings on this page" For create flows, use `create_checkout_page`. For a direct lookup after creation, pass the returned page `id` into this tool.

get_checkout_page

Retrieve a single customer by ID from your Checkout Page account. Returns one customer record directly by ID, without pagination. Use `list_customers` first if you need to discover a customer ID by email or name. Use this tool when you already have the ID. If the customer ID does not exist, returns a 404 error: "Customer not found". For modification requests, show what's currently stored. The merchant can edit the customer record directly in the Checkout Page dashboard. The customer can also update their own details through the customer portal. For data deletion (GDPR/privacy), this requires human intervention in the dashboard. The top-level `address` field is the billing address. The `shipping.address` field is the shipping address. These are separate and often don't match. When asked about "my address" without specifying which, present both addresses clearly labelled (e.g. "Billing address: … / Shipping address: …"). Don't return only one when both exist, and don't return the billing address in response to a shipping address question. **Customer records are identity/profile only — no purchase history, no transaction amounts.** **Cross-tool routing:** To see what this customer has bought, use their `id` as the `customerId` filter on the transaction tools: - `list_payments(customerId: "...")` — one-time purchases, digital products, invoices. - `list_bookings(customerId: "...")` — event tickets and registrations. - `list_subscriptions(customerId: "...")` — recurring billing. Records do not overlap between transaction tools — a transaction only appears in one tool. No risk of double-counting when combining results. For a complete customer picture, call `get_customer` for profile data, then query the transaction tools with the same ID. Example uses (not exhaustive): - "Fetch customer 6812fe6e9f39b6760576f01c" → direct lookup by ID - "Show me the full customer profile for this customer ID" → returns all available fields - "Show me the profile and orders for customer X" → `get_customer` for profile, then fan out to transaction tools with `customerId` Example customer support uses: - Customer asking what information is stored about them — look up by ID, return all stored profile fields. Note that customer records only contain profile data — for a complete picture of what's stored, also query the transaction tools with `customerId` to show their purchase history. - Customer wants to update their address, phone number, or email — look up current profile, present what's on file. The merchant can edit the customer record directly in the Checkout Page dashboard. The customer can also update their own details through the customer portal. - Customer says the name on their account is wrong — look up profile, check `name` field. If a `shipping.name` also exists and differs, present both. The merchant can update the name in the Checkout Page dashboard; the customer can update it via the portal. - Customer requesting deletion of their personal data — GDPR/privacy request. Look up the full profile, show what's stored, and explain that data deletion requires human intervention in the Checkout Page dashboard.

get_customer

Retrieve a single event page and its full configuration by ID. Use create_event to create one; pass its returned id here for a direct lookup, or before a partial update with update_event.

get_event

Retrieve a single form by ID from your Checkout Page account. Use this tool when you already know the form ID and want to inspect the current configuration. If the form ID does not exist, returns a 404 error: "Form not found". Example uses: - "Fetch form 6812fe6e9f39b6760576f01c" - "Show me the current settings for form X" - "Check whether this form is draft, published or archived" - "Inspect the fields, files, images, or redirect settings on this form" For create flows, use `create_form`. For a direct lookup after creation, pass the returned page `id` into this tool.

get_form

Retrieve a single invoice by id. Pass livemode: false to read test-mode records. `invoiceUrl` links to the hosted PDF, the document customers usually ask for. Each response signs a new link, safe to share with the buyer, that expires 1 hour after the response. Use `list_invoices` first to discover an id by customer, invoice number, PO number, or the payment it belongs to (`chargeId`). Read-only; use `regenerate_invoice` to rebuild the PDF.

get_invoice

Retrieve a single payment by ID from your Checkout Page account. Pass livemode: false to read test-mode records. Use `list_payments` first if you need to discover a payment ID by customer email, customer name, product title, or order ID. Event bookings are a separate record type — use `list_bookings` for those. If the payment ID does not exist for the authenticated seller, returns a 404 error: "Payment not found". Example uses: - "Fetch payment 6812fe6e9f39b6760576f01c" - "Show me the full details of this payment" - "Was this payment refunded, and how much?" **This tool is read-only.** Refunds and cancellations must be performed in the Checkout Page dashboard.

get_payment

Retrieve a single product by ID, including its prices, variants, stock, tax and file settings. Product IDs come from a page response (`data.product.id` on get_checkout_page). Read-only.

get_product

Retrieve a single form submission by ID from your Checkout Page account. Pass livemode: false to read test-mode records. Returns one submission record directly by ID, without pagination. Use `list_submissions` first if you need to discover a submission ID by customer email, customer name, page, customer ID, or date range. If the submission ID does not exist, returns a 404 error: "Submission not found". Example uses: - "Fetch submission 6812fe6e9f39b6760576f01c" - "Show me the full contents of this submission" - "Check which page this submission came from" - "What billing and shipping details were captured on this form?" **This tool is read-only.** You cannot edit or delete submissions through MCP. For modification requests, show what was submitted and explain that submission management must happen in the Checkout Page dashboard.

get_submission

Retrieve a single subscription by ID from your Checkout Page account. Pass livemode: false to read test-mode records. Use `list_subscriptions` first if you need to discover a subscription ID by customer email, customer name, product title, or order ID. If the subscription ID does not exist for the authenticated seller, returns a 404 error: "Subscription not found". Example uses: - "Fetch subscription 6812fe6e9f39b6760576f01c" - "Show me the full state of this subscription" - "What's the current period end on this subscription?" **This tool is read-only.** Cancellation and refund operations must be performed in the Checkout Page dashboard. For cancellation context, use `prepare_subscription_cancellation` to see eligibility, side effects, and a dashboard link.

get_subscription

Retrieve a single subscription payment by ID — one charge within a subscription's billing cycle, not the subscription itself. Pass livemode: false to read test-mode records. Use `list_subscription_payments` first if you need to discover an ID; filter it by `subscriptionId` to see every payment on one subscription. For the subscription record itself (status, schedule, next billing date), use `get_subscription`. If the ID does not exist for the authenticated seller, returns a 404 error: "Subscription payment not found". **Two independent status fields:** `paymentStatus` is the charge outcome (succeeded, pending, failed, incomplete); `invoiceStatus` is the Stripe invoice lifecycle (draft, open, paid, uncollectible, void). Check both when answering "did this payment go through?". Example uses: - "Why did the March payment on this subscription fail?" - "Was this renewal charge refunded?" - "Show me the invoice PDF for this subscription payment" **This tool is read-only.** Refunds must be performed in the Checkout Page dashboard.

get_subscription_payment

Fetch one theme by id with its design settings (`variables`). Read-only.

get_theme

Fetch one webhook by id - its URL, subscribed events, status and delivery counters. The signing secret is never returned and custom header values are shown as `[hidden]`; headers are viewed and edited at the returned `dashboardUrl`. Use list_webhooks to find the id. Read-only.

get_webhook

Retrieve a paginated list of event bookings processed through your Checkout Page account. Pass livemode: false to read test-mode records. For questions about a customer's full purchase history query the other transaction tools. Example customer support uses: - "Customer wants to know if they're registered - email is X" → `search` by email. Check `status` and `orderStatus` and present the full picture: a refunded or canceled booking may still appear. Do not use `amountPaid > 0` as the test for registration - a complimentary booking is registered with `amountPaid` of 0. Let the merchant interpret whether the registration is still valid. - "Customer asking how much they paid — order 12345" → `orderId` lookup, report `amountPaid` in display currency. If `amountRefunded > 0`, also report the refund amount and net. - "Customer asking about a coupon — order 12345" → `orderId` lookup, check `coupon` object and report the coupon details (code, label, discount amount). - "Customer chasing a refund — order 12345" → `orderId` lookup, check `status` for `refunded` or `partial_refund`. Report `amountRefunded`, `lastRefundAt`, `lastRefundReason`, and `lastRefundReasonNote`. If no refund has been issued, report that and direct to the dashboard. - "Customer says booking keeps failing" → `search` by email, look for `status: failed` / `isAbandoned: true` records alongside any successful booking. Example uses: - "Show me recent bookings" → no filters, or narrow with `createdAfter` - "Show me canceled bookings" → filter by `orderStatus: 'canceled'` - "Find the booking for order 12345" → filter by `orderId` - "Show me abandoned event bookings" → filter by `abandonmentStatus: 'abandoned'` - "Show me complimentary bookings" → filter by `isComplimentary: 'true'` - "Show me archived bookings" → filter by `archived: 'true'` **Money amounts**: All monetary amounts are returned in the smallest currency unit (for example, `10661` USD = `$106.61`, `299` EUR = `€2.99`, `500` JPY = `¥500`). Divide by 100 before displaying amounts to merchants or customers, noting that some currencies such as JPY do not use decimal minor units. **Two independent status fields:** - `status` is the payment status (paid, refunded, failed, etc.). Use for financial questions. - `orderStatus` is the booking lifecycle (active, canceled). Archiving is the separate `archivedAt` field. Whether a booking is canceled depends on `orderStatus`, not `status`. - These are independent: a booking can be `status: paid` + `orderStatus: canceled` (paid then canceled, refund may not yet be issued), or `status: refunded` + `orderStatus: active` (refunded but booking not marked canceled). - Questions about "canceled" bookings sometimes mean financially refunded (`status: refunded`) rather than lifecycle-canceled (`orderStatus: canceled`). If the question is ambiguous, check both and explain what you find. - `isComplimentary` is independent of both: a complimentary booking was issued by the merchant at no charge and is recorded as `status: paid` with `amount` and `amountPaid` of 0, while `complimentaryDiscountAmount` holds the face value forgone. It is a real, valid registration, not an unpaid or failed one. Filter with `isComplimentary: 'true'` for comps only, `'false'` to exclude them. - `archivedAt` is independent of all three: the merchant hid the booking from their default bookings list in the dashboard. Archiving changes nothing else, so an archived booking can still be a valid registration. The list includes archived bookings unless you filter with `archived: 'false'`. **Customer name fields.** There are four places a name can appear: (1) `customerName` — the canonical customer name from the customer entity. This is the primary name field. (2) `billing.name` — from the payment card, may differ from the registration form name. (3) `shipping.name` — from the shipping details, when provided. (4) `fields` array — the name entered on the registration form. These may not all match — e.g. a spouse's card used for someone else's registration. For questions about a name on a booking, `customerName` is the best default; check the other three if there's a discrepancy. **Date filters**: Always use UTC timestamps with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC. **Limit and large response handling:** Use the right `limit` for the task: - **Single-record lookups** (order lookup, registration check, customer search): use `limit: 10` or less. Bookings are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **Data limitations for common support questions:** - Event metadata: Booking records include `eventTitle` (human-friendly event name) but do not include the event date, time, location, or description. Event details beyond the name aren't available through this tool — check the event in the Checkout Page dashboard. - Refund details: `amountRefunded`, `lastRefundAt`, `lastRefundReason`, and `lastRefundReasonNote` are available on refunded/partial_refund records. Limitation: `lastRefundReason` and `lastRefundReasonNote` only reflect the most recent refund action — if multiple partial refunds were issued with different reasons, only the latest is visible. Full refund history (individual refund transactions) requires the Checkout Page dashboard. - Historical refund limitation: for records created before `2026-01-22T06:43:28.000Z`, some refund metadata may be incomplete. A record can show `status: refunded`, `partial_refund`, or sometimes `canceled` while `amountRefunded` remains `0` or refund detail fields are missing. When reviewing older records, treat the refund status as authoritative but only quote an exact refunded amount if the record explicitly includes it. - Cancellation metadata: `canceledBy` and `canceledReason` are only set when a cancellation is performed from the Checkout Page dashboard. For cancellations from other flows, these fields may be empty or null, so cancellation reason analysis is often unavailable. - Email delivery: No tool in the MCP exposes email delivery information — no sent date, no delivery status, no bounce info. A booking can be confirmed (via this tool) but email delivery status cannot be checked. If a customer says they didn't receive a confirmation, verify the email address on file (`customerEmail`, `billing.email`) is correct, confirm the booking exists, and direct to the Checkout Page dashboard where emails can be resent. - Address information: `billing.address` and `shipping.address` are often empty objects, especially for free or low-cost event registrations. - Ticket capacity/inventory: The `capacity` and `ticketGroupCapacity` fields on ticket objects are historical snapshots from booking time — they do NOT reflect current remaining availability. If a ticket object's `capacity` field is missing, that ticket type should be treated as unlimited. If `ticketGroupCapacity` is missing, that ticket group should be treated as unlimited. But an unlimited ticket type can still belong to a ticket group with a limit, and an unlimited ticket group can still sit inside an event with a limit. Total event capacity lives on the event, which is not accessible through any current tool. Do not use booking records alone for inventory calculations. "How many tickets are left?", "Is my event sold out?", and "Can I accept more bookings?" are still unanswerable from this tool alone — you can count tickets sold, but you may not have the governing event or group limit to subtract from. For sold counts, note the inventory logic: canceled bookings release tickets back to inventory, but refunded bookings do not — a refunded ticket still counts against capacity. **Cross-tool routing:** Records do NOT overlap between tools — a transaction only appears in one tool. Payments, bookings, and subscriptions are separate record sets. There is no risk of double-counting when combining results across tools. *Name and event search*: `search` on this tool matches customerName, customerEmail, eventTitle, and orderId. Searching by name (e.g. `search: "Nelson"`) returns all records for customers with that name. Searching by event (e.g. `search: "AI Summit"`) returns all bookings for that event. If you need more customer profile details (company, phone, tax ID), use `list_customers` or `get_customer`. *Order lookup*: If "look up order 12345" returns 0 results here, try `list_payments(orderId: "12345")` and `list_subscriptions(orderId: "12345")` — the order may be a payment or subscription, not a booking. *Full customer history*: For "show me everything this customer has bought," query all three transaction tools (`list_payments`, `list_bookings`, `list_subscriptions`) with the same `customerId` or `search` email and combine results. Do not present results from one tool alone as a complete history. *Customer profile*: For profile data (company, phone, billing email, tax ID), use `list_customers` or `get_customer` — booking records only have `customerEmail` and `billing.name`. **This tool is read-only.** You cannot transfer tickets, change attendee names, cancel bookings, resend confirmations, or issue refunds. For modification requests, show what's currently on file and explain that changes need to be made in the Checkout Page dashboard.

list_bookings

List the checkout pages on the Checkout Page account, newest first, each with its full configuration, product and fields. Archived pages are left out unless you filter by status. Read-only; this is how to find a page id for get_checkout_page and update_checkout_page. Forms and events are separate page types: use list_forms and list_events.

list_checkout_pages

Retrieve a paginated list of discount coupons on your Checkout Page account. This is the only way to discover a coupon ID — take the `id` from here to use `update_coupon`. `search` is a case-insensitive contains match on the coupon's label and code, so it answers "is there already a coupon for X?" before you create a duplicate with `create_coupon`. **Reading a coupon:** the discount is either `percentOff` (a percentage) or `amountOff` (a flat amount in the smallest currency unit, paired with `currency`) — never both. `duration` is `once`, `repeating` (for `durationInMonths`), or `forever`. `timesRedeemed` counts redemptions so far, against `maxRedemptions` when one is set. **Whether a coupon actually works right now** depends on several fields together, and there is no single "active" flag: `deleted: true` means soft deleted and dead; `redeemBy` in the past means expired; `timesRedeemed >= maxRedemptions` means exhausted. Check all three before telling a merchant a coupon is live. Soft-deleted coupons are returned by this tool — they are not filtered out. **Scoping:** `rules` lists where the coupon works and what it discounts, one `{ pageId, appliesTo, priceIds, ticketTypeIds, bumpProductIds }` per rule; with none it discounts the whole order on every checkout page and event. `appliesTo` is `wholeOrder`, `prices` (only the picked prices), `pricesAndBumps` (only when a picked price AND a picked bump are bought, discounting both), `tickets` (only the picked tickets) or `ticketsAndAddOns` (only when a picked ticket AND a picked add-on are bought). An empty `priceIds`, `ticketTypeIds` or `bumpProductIds` means every price, ticket type, bump or add-on on the page. Rules on the same page are combined with OR. `pageIds` and `ticketTypeIds` are deprecated and derived from the rules. These are IDs only: this tool does not resolve them to page, event, product or price names. **No filters beyond search.** There is no way to filter by deleted, expiry, redemption count, or scope server-side. Page through and inspect those fields. Coupons are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **This tool is read-only.** Use `create_coupon` to add one and `update_coupon` to change or soft delete one. A coupon's discount (code, amountOff, percentOff, currency, duration) can never be changed after creation.

list_coupons

Retrieve a paginated list of customers from your Checkout Page account. Customer records are identity and profile data only — no purchase history, no transaction amounts, no subscription status. Use this tool when you need profile data (company, phone, address, tax ID) or when you need a customer ID for filtering. The two-step pattern (search here → take `id` → filter transaction tools with `customerId`) is useful when: - You need to fan out across transaction tools with one consistent ID - The customer has multiple email addresses (searching by `customerId` catches all transactions regardless of email) - You need profile fields that don't exist on transaction records The top-level `address` field is the billing address. The `shipping.address` field is the shipping address. These are separate and often don't match — a customer may have a billing address but no shipping address, or vice versa. When the question doesn't specify which address, present both clearly labelled (e.g. "Billing address: … / Shipping address: …"). Don't return only one when both exist, and don't return the billing address in response to a shipping address question. For modification requests, show what's currently stored, then use `update_customer` with the customer's `id` once the merchant confirms the change. Data deletion and GDPR/privacy requests require human intervention in the dashboard. **No email delivery data in this tool.** No tool in the MCP exposes email delivery information — not on customer records, not on payments, bookings, or subscriptions. You can confirm a purchase exists (via transaction tools) but cannot check email delivery status through this tool. Emails can be resent and email delivery can be verified in the Checkout Page dashboard. **What this tool cannot do:** - No purchase history — customer records contain no transaction data. To see what a customer bought, use their `id` as `customerId` on the transaction tools (see cross-tool routing below). - No aggregation — cannot count customers by country, company, etc. server-side. - `companyName` is not searchable — `search: "Acme Corp"` returns 0 even if a customer has that `companyName`. To find customers by company, you must paginate and inspect records. **Date filters**: Always use UTC timestamps with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC. Customers are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **Cross-tool routing:** Customer records do NOT contain purchase data. To build a complete customer picture, combine this tool with the transaction tools: - `list_payments(customerId: "...")` — one-time purchases, digital products, physical goods, invoices. - `list_bookings(customerId: "...")` — event tickets and registrations. - `list_subscriptions(customerId: "...")` — recurring billing, active and canceled subscriptions. Records do not overlap between transaction tools — a transaction only appears in one tool. No risk of double-counting when combining results. If a merchant gives you an order number rather than a customer name or email, do NOT use this tool — try the transaction tools with the `orderId` filter directly. Example uses: - "How many customers do I have?" → call with `limit: 1`, read `total` - "How many new customers this month?" → use `createdAfter` with the first of the month, `limit: 1`, read `total` - "Find customer jane@example.com" → use `search` - "Show me customers named Sarah" → use `search` (matches name field). Verify the returned records match on name, not just email. - "What has John Smith ordered?" → search here by name, get `id`, then query transaction tools with `customerId` - "Find my customer Acme Corp" → `search` won't match companyName; paginate and inspect `companyName` field Example customer support uses: - "Customer asking what information is stored about them — email is jane@example.com" → `search` to find the customer record. Return all stored profile fields (name, email, phone, addresses, company, tax ID). Note: customer records only contain profile data — for a complete picture of what's stored, also query the transaction tools (`list_payments`, `list_bookings`, `list_subscriptions`) with the `customerId` to show their purchase history. - "Customer wants to update their email address" → look up the customer to confirm current email, then call `update_customer` with their `id` and the new email once the merchant confirms it. The customer can also change their own email through the customer portal. - "Customer says they didn't get their confirmation email" → find customer, then check transaction tools for recent purchases. Confirm the purchase exists but explain that email delivery status cannot be checked through this tool. Email delivery can be verified and emails can be resent from the Checkout Page dashboard. - "Customer wants a full history of what they've bought" → find customer by email/name, then query all transaction tools with `customerId` to compile full purchase history. - "Customer requesting deletion of their personal data" → GDPR/privacy request. Show what's stored and explain that data deletion requires human intervention in the Checkout Page dashboard.

list_customers

List the event pages on the Checkout Page account, newest first, each with its full configuration, event details, ticket groups, ticket types and fields. Archived events are left out unless you filter by status. Read-only; this is how to find an event id for get_event, update_event, list_bookings and list_tickets. Checkout pages and forms are separate page types: use list_checkout_pages and list_forms.

list_events

List the form pages on the Checkout Page account, newest first, each with its full configuration, fields and files. Archived forms are left out unless you filter by status. Read-only; this is how to find a form id for get_form, update_form and list_submissions. Checkout pages and events are separate page types: use list_checkout_pages and list_events.

list_forms

List invoices generated from payments (Charges) on the Checkout Page account. Pass livemode: false to read test-mode records. Each invoice's `invoiceUrl` links to its hosted PDF, the document customers usually ask for. The link is signed, safe to share with the buyer, and expires 1 hour after the response. Read-only; for full purchase history also query list_payments, list_subscriptions, list_subscription_payments and list_bookings.

list_invoices

List the order bumps on a checkout page or event (shown as add-ons on events) in display order, with how each is offered and any reason it cannot be offered right now. Read-only.

list_order_bumps

Retrieve a paginated list of payments processed through your Checkout Page account. Pass livemode: false to read test-mode records. For questions about a customer's full purchase history query the other transaction tools. Example customer support uses: - Customer asking about order status - `orderId` lookup, report `status` and key details (product, amount, date) - Customer unsure if payment went through - `search` by email, identify which records are `paid` vs `failed`. - Customer says they were double-charged - `search` by email, compare all records. Check `status` and `amountPaid` on each. - Customer asking about a coupon - `orderId` lookup, check `coupon` object and report the coupon details (code, label, discount amount). - Customer asking for a receipt - `orderId` lookup, confirm the order details (product, amount, date, payment method). An `invoiceId` on a paid record means an invoice was generated; `get_invoice` returns it with a link to its PDF. Invoices can be resent from the Checkout Page dashboard. - Customer asking about a refund - `orderId` lookup, check `status`. If `refunded`: confirm the full refund, report `amountRefunded` as the refund amount, `lastRefundAt` as the refund date, and `lastRefundReason` as the reason. If `partial_refund`: report `amountRefunded` vs `amountPaid` so the customer knows how much was refunded and how much they retain. `lastRefundReasonNote` may contain a merchant-written explanation. - Customer asking about a download or delivery - `orderId` lookup, confirm the purchase is paid. No download URL or delivery tracking is available on payment records. For digital products, downloads are accessed via the customer portal. The customer should check their purchase confirmation email first; if they can't find it, sharing a link to the customer portal will let them access their downloads. - Customer says checkout keeps failing - `search` by email. Look for records with problem statuses: `failed`, `draft`, `draft_expired`, `created`, `pending`, `unpaid`, or `canceled`. A `draft` or `draft_expired` record may mean the customer didn't complete the checkout form. Check `paymentError` on failed records for a specific error message. - Customer wants full purchase history - this tool only covers payments. Also query the other transaction tools with the same email/customerId to get the full picture. Combine results before presenting. Do not present results from `list_payments` alone as a complete history. - Order lookup returns 0 results - try `list_bookings(orderId: "...")` and `list_subscriptions(orderId: "...")`. The order may be a booking or subscription, not a payment. Always try all tools before reporting an order doesn't exist. Example uses: - "Show me failed payments" - filter by `status: 'failed'` - "Show me payments for checkout page X" - filter by `pageId` - "Show me all payments from customer X" - filter by `search` with their name or email - "Find order ORD-9182" - filter by `orderId` - "Show me abandoned carts" - filter by `abandonmentStatus: 'abandoned'` - "Show me refunds" - filter by `status: 'refunded'` (also check `status: 'partial_refund'` separately - only one status per call). **Money amounts**: All monetary amounts are returned in the smallest currency unit (for example, `10661` USD = `$106.61`, `299` EUR = `€2.99`, `500` JPY = `¥500`). Divide by 100 before displaying amounts to merchants or customers, noting that some currencies such as JPY do not use decimal minor units. **Customer name fields.** There are four places a name can appear: (1) `customerName` - the canonical customer name from the customer entity. This is the primary name field. (2) `billing.name` - from the payment card, may differ from the checkout form name. (3) `shipping.name` - from the shipping details, when provided. (4) `fields` array - the name entered on the checkout form. These may not all match - e.g. a spouse's card used for someone else's order. For questions about a name on an order, `customerName` is the best default; check the other three if there's a discrepancy. **Data limitations for common support questions:** - Receipt/invoice requests: `invoiceId` confirms an invoice was generated. `get_invoice` returns the invoice and a link to its PDF. Resending an invoice is only possible in the Checkout Page dashboard. - Refund details: `amountRefunded`, `lastRefundAt`, `lastRefundReason`, and `lastRefundReasonNote` are available on refunded/partial_refund records. Limitation: these fields only reflect the most recent refund action - earlier reasons are overwritten. Full refund history requires the Checkout Page dashboard. - Historical refund limitation: for records created before `2026-01-22T06:43:28.000Z`, some refund metadata may be incomplete. A record can show `status: refunded`, `partial_refund`, or sometimes `canceled` while `amountRefunded` remains `0` or refund detail fields are missing. When reviewing older records, treat the refund status as authoritative but only quote an exact refunded amount if the record explicitly includes it. - Cancellation metadata: `canceledReason` is only set when a cancellation is performed from the Checkout Page dashboard (`canceledBy` is set) or through the API (`canceledByApiKey` is set). For cancellations from other flows, these fields may be empty or null, so cancellation reason analysis is often unavailable. - Email delivery: No tool in the MCP exposes email delivery information. A purchase can be confirmed (via this tool) but email delivery status cannot be checked through this tool. Email delivery can be verified and emails can be resent from the Checkout Page dashboard. - Download/delivery: No download URL, delivery status, or fulfilment tracking exists on payment records. For digital products, downloads are accessed via the customer portal. - Payment failure reasons: `paymentError` provides the last error message but is not guaranteed to be set. `paymentError` persists even after a successful retry - always check `status` first. - Address information: `billing.address` and `shipping.address` are often empty objects, especially for non-physical products. **Date filters**: Always use UTC timestamps with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC. **Limit and large response handling:** Use the right `limit` for the task: - **Single-record lookups** (order lookup, customer search, "has X paid?"): use `limit: 10` or less. **Tips for common questions:** - For count questions ("how many paid orders?"), filter by the relevant status (e.g. `status: "paid"`) and read `total` from the response. An unfiltered `total` includes all records regardless of status (failed, draft, etc.) - always filter when counting a specific category. - For "who paid?" or "has X paid?", use `search` with the customer's email and check the `status` field. Payments are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **Cross-tool routing:** Records do NOT overlap between tools - a transaction only appears in one tool. Payments, bookings, and subscriptions are separate record sets. There is no risk of double-counting when combining results across tools. *Name search*: `search` on this tool matches customerName, customer email, productTitle, and orderId. Searching by name (e.g. `search: "Nelson"`) returns all records for customers with that name. If you need more customer profile details (company, phone, tax ID), use `list_customers` or `get_customer`. *Order lookup*: If "look up order 12345" returns 0 results here, try `list_bookings(orderId: "12345")` and `list_subscriptions(orderId: "12345")` - the order may be a booking or subscription, not a payment. *Full customer history*: For "show me everything this customer has bought," query all transaction tools with the same `customerId` or `search` email and combine results. *Customer profile*: For profile data (company, phone, billing email, tax ID), use `list_customers` or `get_customer` - payment records have `customerName`, `customerId`, `customerEmail`, `billing.name`, and `shipping.name` but not the full profile fields. **This tool is read-only.** You cannot process refunds, resend receipts, update customer details, change shipping addresses, or resend download links. For these actions, explain what's currently on file. The merchant can manage orders in the Checkout Page dashboard. The customer can access their purchases through the customer portal.

list_payments

Retrieve a paginated list of your products, newest first. Filter with `role: orderbump` to find the products you can offer as order bumps with create_order_bump; page products are also reachable from their page. Read-only.

list_products

Retrieve a paginated list of form submissions processed through your Checkout Page account. Pass livemode: false to read test-mode records. This tool is useful for customer-support and operations questions about what a person submitted on a form, which page a submission came from, and when it was captured. Example uses: - "Show me recent submissions" - "Find submissions from jane@example.com" - "Find submissions for customer 6812fe6e9f39b6760576f01c" - "Show submissions for form X" - "Show submissions for the Lead Capture Form" - "Show failed submissions" - "How many submissions did I get this week?" — apply a date range and read `total` Example support uses: - Customer says they filled in a form but is unsure it went through — search by email and check whether a matching submission exists and whether `status` is `succeeded` or `failed`. - Merchant wants all submissions for a specific person — use `search` with email or name, or `customerId` when known. - Merchant wants submissions from a specific form — use `pageId` when you know the page ID, or `search` with the form title. - Merchant wants the full payload for one result — first call `list_submissions`, then pass a returned `id` into `get_submission`. **Data limitations:** - No tool in the MCP can edit or delete submissions. - Submission records show what was captured, but not downstream fulfillment or email delivery status. **Date filters**: Always use UTC timestamps with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC. Submissions are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **This tool is read-only.** You cannot modify or delete submissions through MCP. For those actions, explain what is on file and direct the merchant to the Checkout Page dashboard.

list_submissions

Retrieve a paginated list of subscription payment records for your Checkout Page account. Each record represents one per-Stripe-invoice charge against a subscription — a billing cycle payment, renewal, or failed attempt. Subscriptions rarely accumulate more than 24–36 payment records (2–3 years of monthly billing), so `limit: 100` typically retrieves the full history for a single subscription in one call. Pass livemode: false to read test-mode records. **Cross-tool routing:** - Per-payment subscription history → this tool (`list_subscription_payments`) - Parent subscription record (status, plan, trial, coupon) → `list_subscriptions` - One-time payment charges → `list_payments` - Event/booking charges → `list_bookings` Records do NOT overlap between tools — a transaction only appears in one tool. No risk of double-counting when combining results. **This tool is read-only.** You cannot process refunds, cancel subscriptions, update payment methods, or retry failed payments. For these actions, explain what is currently on file. The merchant can manage subscription payments in the Checkout Page dashboard. The customer can update their payment method through the customer portal.

list_subscription_payments

Retrieve a paginated list of subscriptions processed through your Checkout Page account. Pass livemode: false to read test-mode records. For questions about a customer's full purchase history query the other transaction tools. Example uses: - "Show me recent subscriptions" — use no filters or narrow with `createdAfter` - "Find the subscription for order ORD-9182" — filter by `orderId` - "Show me subscriptions for checkout page X" — filter by `pageId` - "Find subscriptions for jane@example.com" — use `search` (contains match on email) - "Find subscriptions for Jane Smith" — use `search: "Jane Smith"` (matches `customerName`) - "Show me Galactic Coffee subscriptions" — use `search: "Galactic Coffee"` (matches `productTitle`) - "How many active subscriptions do I have?" — filter by `status: "active"`, read `total`. Note: also query `status: "past_due"` separately — past_due subscriptions are still active but at risk (see status guidance below). - "Show me canceled subscriptions" — filter by `status: "canceled"` - "What's my MRR?" — Tell the merchant they can see their MRR in the Checkout Page dashboard. - "Show me abandoned subscription checkouts" — use `abandonmentStatus: "abandoned"` **Money amounts**: All monetary amounts are returned in the smallest currency unit (for example, `10661` USD = `$106.61`, `299` EUR = `€2.99`, `500` JPY = `¥500`). Divide by 100 before displaying amounts to merchants or customers, noting that some currencies such as JPY do not use decimal minor units. Example customer support uses: - Customer asking if their subscription is active — `search` by email or `orderId` lookup. Check `status`: if `active`, the subscription is healthy. If `past_due`, the subscription is still active but the payment method is failing — tell the customer to update their payment method through the customer portal. If `canceled`, report when it was canceled (`canceledAt`). - Customer asking when their next payment is — check `currentPeriodEnd` for the next billing date, `amount` for the charge amount, `interval` and `intervalCount` for the billing frequency (e.g. interval: "year", intervalCount: 1 = annual billing). Note: if the subscription has a coupon, the actual charge may be less than `amount` — check `couponSnapshot` for discount details. - Customer saying their payment keeps failing — `search` by email. Check `status` for `past_due` or `failed`. Check the `paymentError` field for a specific error message. Note: the troubleshooting depends on context — if this is the first payment to activate the subscription, the customer may need to retry with a different payment method. If it's a recurring payment failing, the customer should update their payment method through the customer portal. If the customer has multiple subscriptions, only some may be failing — distinguish them clearly. - Customer wanting to cancel — `orderId` or email lookup, confirm what's on file (status, billing details, current period end). Subscription cancellation can be done by the merchant in the Checkout Page dashboard or by the customer through the customer portal. - Customer claiming they cancelled but are still being charged - check `status` and `canceledAt`. If `status: "canceled"` and `canceledAt` is set, the subscription was indeed canceled on that date. The `currentPeriodEnd` may still be in the future (the customer paid for the period). For the individual charges, use `list_subscription_payments(subscriptionId: ...)`. - Customer asking for a refund on their subscription — confirm the subscription details (status, amount, how long active). If a refund has already been issued, report `lastRefundAt` (date), `lastRefundReason` (reason code), and `lastRefundReasonNote` (merchant notes). Refunds can be processed by the merchant in the Checkout Page dashboard. - Customer asking what plan they're on — check `productTitle` (human-readable product name, e.g. "Galactic Coffee Subscription"), `amount`, `interval`, and `intervalCount`. If the subscription has a coupon, also report the discount. Present the plan name with amount and billing frequency (e.g. "Galactic Coffee Subscription — $100/month"). - Customer asking about their trial — check `trialStart`, `trialEnd`, and `status`. If `status` is `trialing` or `scheduled` and `trialEnd` is in the future, the trial is still active (`trialing` = free trial; `scheduled` = setup fee paid, billing starts later). If `trialEnd` is in the past, the trial has ended (billing should have started at `startDate`). - Customer asking about their total payments - this tool reports the current recurring charge (`amount`), billing frequency (`interval` + `intervalCount`), and how long the subscription has been active (from `createdAt`). For what was actually charged each cycle, use `list_subscription_payments(subscriptionId: ...)` and add up the payments. - Customer asking about a discount on their subscription — check `couponSnapshot` for the coupon code, label, and discount amount (`amountOff` or `percentOff`). Check `couponSnapshot.duration` to see how long the discount lasts (`forever`, `repeating` with `durationInMonths`, or `once`). Setup fee discounts are visible in `setupFeeDiscountAmount`. - Customer saying the name on their subscription is wrong — check `customerName`, `billing.name` (from the payment card), `shipping.name`, and the `fields` array for `customer_name` (from the checkout form). These often don't match. The merchant can update the name in the Checkout Page dashboard; the customer can update it through the portal. **Data limitations for common support questions:** - Charge/payment history: For per-payment history of a subscription (when each charge happened, amount per cycle, refund details), use `list_subscription_payments(subscriptionId: ...)`. - Refund details: `lastRefundAt`, `lastRefundReason`, `lastRefundReasonNote` available but only reflect the most recent refund. Per-refund history requires the dashboard. - Historical refund limitation: for records created before `2026-04-09T08:47:59.000Z`, full subscription refund transaction history may be incomplete. A subscription can still show refund-related fields or a refunded state while older refund history is incomplete or missing. When reviewing older subscription records, only quote exact refund timing or refund details when the record explicitly includes them. - Email delivery: No email delivery data available through this tool. Email delivery can be verified and emails can be resent from the Checkout Page dashboard. - Access/entitlement: No content access or login status data. - Payment method updates: The merchant can update in the dashboard; the customer can update through the portal. - Cancellation metadata: `canceledAt` present on canceled records. `canceledBy` and `reason` are optional. **Date filters**: Always use UTC timestamps with the `Z` suffix (e.g. `2026-03-01T00:00:00Z`). Never use local timezone offsets — dates are stored and compared in UTC. **Limit and large response handling:** Use the right `limit` for the task: - **Single-record lookups** (order lookup, customer search): use `limit: 10` or less. **Tips for common questions:** - For count questions, use the `status` filter and read `total`. Remember: `past_due` subscriptions are still active — include them in "active" counts. - For single-customer lookups, use `search` with email or `orderId`. - A customer may have multiple subscription records (e.g. a failed attempt followed by a successful signup). Always check all returned records, not just the first one. Subscriptions are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10. **Cross-tool routing:** Records do NOT overlap between tools — a transaction only appears in one tool. Payments, bookings, and subscriptions are separate record sets. No risk of double-counting when combining results. *Order lookup*: If "look up order 12345" returns 0 results here, try `list_payments(orderId: "12345")` and `list_bookings(orderId: "12345")`. *Full customer history*: For "show me everything this customer has bought," query `list_payments` and `list_bookings` tools with the same `customerId` or `search` email and combine results. *Customer profile*: For profile data (company, phone, billing email, tax ID), use `list_customers` or `get_customer` — subscription records have `customerName`, `customerId`, `customerEmail`, `billing.name`, and `shipping.name` but not the full profile fields. **This tool is read-only.** You cannot cancel subscriptions, process refunds, update payment methods, change billing details, pause/resume billing, or switch plans. For these actions, explain what's currently on file. The merchant can manage subscriptions in the Checkout Page dashboard by navigating to the subscription record. The customer can manage their subscription through the customer portal.

list_subscriptions

List all fixed tax rates configured for this Checkout Page account. Use this tool to find an existing tax rate before creating a new one or when setting up a page with `tax.mode: "fixed"`. Check whether a suitable rate already exists — avoid creating duplicates. This tool returns all rates — there is no filtering or pagination.

list_tax_rates

List the design and label properties a checkout page, event or form can override, with their value format and allowed values. A property with a fixed default (every label, and a few other properties) lists it; the others follow the page's theme. Read-only, from a fixed list of about 800 properties: narrow it with `group`, `prefix` or a `search` of one or two words, such as `button radius` or `pay button color`, since the whole list, or the whole `elements` group, is too long to read at once. A search lists the properties that match every word or, when none do, those that match any word, best match first, and at most 40 of them: `total` counts every match, and `note` says when to narrow the search or which word matched nothing. `prefix` takes the path of the part of the page you are changing. `elements.product.*` is the product column (`title`, `logo`, `pricing`, `pricePicker` for the price options), `elements.checkout.*` the checkout column (`cards`, `variants`, `ticketGroups`, `pwyw`, `confirmation`), and `elements.checkout.form.*` the form (`fields`, `button`, `priceBreakdown`, `heading`, `discountCode`, `manualPayments`). The `tokens`, `layout` and `labels` groups are small enough to list whole. Set them under `themeOverrides` on create_checkout_page, update_checkout_page, create_event, update_event, create_form and update_form, nested by `path`: `tokens.colorPrimary` is `{ "tokens": { "colorPrimary": { "light": "#1A73E8" } } }`. Keys you leave out keep their value, and `null` resets a property, or everything under a key, to the theme default. Labels are the text customers see, so translate a page by setting them. `hostedLayoutType` (`center`, `double` or `split`) picks the page layout; `layout.*` properties style the layout they name. Value formats by `type`: - color: `{ "light": ..., "dark": ... }`, one color for light and one for dark color mode. The page shows the one for its color mode, `tokens.colors`. Either can be left out. Each is any CSS color value, for example `#1A73E8`, `rgb(26 115 232)`, `hsl(214 82% 51%)` or a named color such as `navy`. The API refuses `;`, `{`, `}`, `<` and `>` but doesn't check that the value is a valid color: an invalid one is stored, and the browser ignores it on the page. - font: a Google Fonts family name, such as `Inter`. - size, fontSize: a number of pixels, or `""` for Auto when `options` lists it. - fontWeight: 100 to 900 in steps of 100. - toggle: `true` or `false`. - image: `{ "file": "<id>" }`, the ID of an image uploaded with upload_file. - text: plain text or inline markdown, no HTML. `customCss` takes CSS instead. - select, shadow, alignment, fontStyle: one of `options`. When a property has `options`, only those values are accepted. `customCss` needs a plan that includes custom CSS, and the Powered by Checkout Page and Powered by Stripe badges can only be changed with a paid subscription. A `null` reset works on any plan.

list_theme_properties

List the themes your pages can use: your own and the built-in ones, sorted by id from highest to lowest, so a theme you create appears before older ones. Built-in themes were installed together, so their order doesn't follow `createdAt`. Use a theme's id as `themeId` on a page, or as `baseThemeId` to create a copy. Read-only.

list_themes

List individual attendee tickets from paid event bookings on the Checkout Page account - one record per attendee, with full check-in history and per-ticket revenue allocation. Pass livemode: false to read test-mode records. Use it for guest lists, door and check-in questions, and locating a named attendee. Each ticket carries `checkInCode`, the opaque check-in credential to encode when rendering the ticket QR code. Read-only; a booking produces several tickets, so for the order or payment behind them query list_bookings by `bookingId`.

list_tickets

List the webhook endpoints registered on this Checkout Page account, newest first, with their subscribed events, status and delivery counters. The signing secret is never returned and custom header values are shown as `[hidden]`; headers are viewed and edited at the returned `dashboardUrl`. This is how to find a webhook `id` for `get_webhook` or `delete_webhook`, and how to check whether a URL is already registered before calling `create_webhook`. Read-only. Webhooks are returned sorted newest-first. Use cursor-based pagination (`starting_after` / `ending_before`) to page through large result sets. `starting_after` and `ending_before` cannot be used simultaneously. Max `limit` is 100, default is 10.

list_webhooks