Checkout Page

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. 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. 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. Always surface the invoice's `invoiceUrl` (hosted PDF link) in your reply — it is the single most useful field for customers, and this response returns a freshly signed one that expires an hour later. 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. 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. 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. 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 `cancel_subscription` 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. 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 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. 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'` **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, archived). 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. **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:** `pageIds` limits the coupon to specific pages and `ticketTypeIds` to specific ticket types. Empty or absent means the coupon is valid everywhere. These are IDs only — this tool does not resolve them to page or event 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. Always surface each invoice's `invoiceUrl` (hosted PDF link) in your reply - it is the single most useful field for customers and should be included for every invoice you mention. Read-only; for full purchase history also query list_payments, list_subscriptions, list_subscription_payments and list_bookings.

list_invoices

Retrieve a paginated list of payments processed through your Checkout Page account. 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`. Lead with the confirmation or denial before listing details. - 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` field exists on paid records, confirming an invoice was generated, but the invoice itself cannot be retrieved or resent through this tool yet. Provide the order summary as a stopgap. The full invoice can be viewed and 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 but the document cannot be retrieved yet. For now, the key order details from the payment record — product, amount paid, date, payment method — can serve as a summary. The full invoice can be viewed and resent from 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: `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. 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 form submissions processed through your Checkout Page account. 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. **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. 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 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. 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

Regenerate the PDF for an invoice by id. Overwrites the stored billing details on the invoice with the current ones from the source payment and its customer, overwrites the PO number when the payment has one, and fills in the customer email, customer name and product title only where the invoice has none. It then replaces the existing hosted PDF - the previous PDF is not kept. Preserves line items, amounts, taxes, and status. The returned `invoiceUrl` is a fresh signed link.

regenerate_invoice

Update an existing checkout page's content and settings. Supports a subset of create's fields; read current values with get_checkout_page before a partial update. Prices, variants, stock and other product settings are not on the page: use update_product with the page's data.product.id. Custom fields are managed with create_field, update_field and delete_field.

update_checkout_page

Update an existing coupon in your Checkout Page account. Only the fields you supply are changed; omitted fields are left as-is. Send `null` for `maxRedemptions` or `redeemBy` to remove that limit. `pageIds` and `ticketTypeIds` are replaced wholesale rather than merged - send the full list you want, or an empty array to clear it. **What cannot be changed:** the discount itself. `code`, `amountOff`, `percentOff`, `currency`, `duration`, and `durationInMonths` are fixed once a coupon exists, because they are mirrored into Stripe. To change a discount, soft delete this coupon (`deleted: true`) and create a replacement with `create_coupon`. Coupons created before 2025-10-04 cannot be updated at all — their redemption limits are synced with Stripe and the API returns a 400 saying so. Ticket types are scoped through pages, so any `ticketTypeIds` must belong to the `pageIds` sent in the same request — or, when `pageIds` is omitted, to the pages already on the coupon. **This tool modifies live data.** Setting `deleted: true` stops the coupon working at checkout immediately.

update_coupon

Update the editable details of a customer record in your Checkout Page account. Use `list_customers` first if you need to discover the customer ID by name or email. If the customer ID does not exist, returns a 404 error: "Customer not found". Only the fields you supply are changed; omitted fields are left as-is. The `address` and `shipping` subdocuments use patch semantics — supply only the sub-fields you want to change. Send `null` for any optional field (or for a whole subdocument) to clear it. The primary `email` field cannot be cleared. **This tool modifies live data and notifies external systems.** Every successful update sends a `customer.updated` webhook, carrying the full updated customer profile, to each endpoint the merchant has subscribed to that event.

update_customer

Update an existing event page's content and settings. Supports a subset of create's fields; read current values with get_event before a partial update. Custom fields are managed with create_field, update_field and delete_field.

update_event

Update one custom field on a checkout page, form, or event: label, element, type, options, required, hidden, default value, visibility rules and more. Only supplied properties change; options are replaced wholesale. Get field IDs from get_checkout_page, get_form, or get_event. Mutating.

update_field

Update an existing form page's content and settings. Supports a subset of create's fields; read current values with get_form before a partial update. Custom fields are managed with create_field, update_field and delete_field.

update_form

Update an existing product's prices, variants, stock, tax, files and other settings. This is where a page's pricing lives: use it, not update_checkout_page, to change what a page sells. Only the fields you supply change; prices[] and variants[] replace the full list, so read current values with get_product first.

update_product

Update the attendee details (name and email) and metadata held on one event ticket. Use `list_tickets` first to discover the ticket ID by attendee name, email, or ticket short ID. Only supplied fields change, the booking and customer records are untouched, and the booking ticket PDF is regenerated when attendee details change. Metadata operations are per-entry: a value adds or overwrites its key, null deletes it, other entries survive. Mutating - confirm the target ticket before calling.

update_ticket

Update a webhook's name, https URL, subscribed events or status (active/inactive to pause and resume). Only supplied fields change; events are replaced wholesale. Custom headers cannot be set here: they usually hold receiver credentials, so never ask the user for header values and give them the `dashboardUrl` from the response instead, where headers are edited. Existing headers are kept and their values are returned as `[hidden]`. Mutating; use list_webhooks to find the id.

update_webhook

Upload a file into your Checkout Page account from a public URL. Use this tool when you need a Checkout Page file ID to reference elsewhere in the API. The tool fetches the source file from `url`, uploads it to Checkout Page, and returns the stored file record. **Purpose matters:** - `purpose: "image"` uploads a public image asset. Use this for page galleries, product galleries, ticket visuals, logos, hero images, and other media shown on the page. - `purpose: "file"` uploads a private downloadable asset. Use this for digital downloads attached to checkout pages, files restricted to certain product variants, and files delivered after a form submission. **How uploaded files are typically used:** - Page gallery images on checkout pages, events or forms. - Product gallery images and variant-specific images - Ticket types where an image is needed - Downloadable files attached to products or checkout pages after purchase or forms after submission. **Input notes:** - `url` MUST be a public URL. The MCP server will make a http request to directly download the resource. - `filename` is optional and overrides the stored filename. - Images uploaded as `purpose: "image"` must still be a supported image type upstream.

upload_file