Checkout Page helps merchants create and update checkout pages, event registration pages, and forms; manage customer and booking records; and review payments, subscriptions, and invoices. It also supports coupons, fixed tax rates, uploaded assets, and webhook configuration. Subscription cancellation is prepared for completion in the dashboard.
booking.paid webhook fires, and an invoice may be generated. There is no undo through this API: cancellations, refunds and ticket transfers must be done in the Checkout Page dashboard. Confirm the event, the ticket quantities and the customer's email with the merchant before calling it. Not idempotent - never retry blindly. Every call creates a new booking, so calling again after a timeout or an unclear error can issue duplicate tickets and send a second confirmation email. If the outcome of a call is uncertain, check list_bookings (search by the customer's email) before trying again. No card payment is collected. There are two booking strategies, and exactly one of them must be supplied: - paymentOption.manualType records the booking as unpaid with the full amount as its balance due, settled outside checkout by invoice (invoice) or on arrival (cash_on_delivery); a free booking simply has nothing due. Use it for box-office and phone bookings, invoiced corporate registrations, and migrating bookings in. - complimentary: true records the booking as paid with amount, amountPaid and amountDue of 0 and isComplimentary: true. The ticket lines keep their face value and a matching complimentaryDiscountAmount brings the total to 0, so the forgone revenue stays visible on the booking and its invoice. Use it for comped guests, speakers, staff and press. No coupon can be applied. Neither strategy takes a card payment: that belongs on the event's own checkout. The storefront guards still apply, exactly as they would for a buyer checking out: - 409 — the ticket type or its ticket group is sold out, or the requested quantity exceeds remaining capacity. - 409 - tickets are not on sale: the sale window has not opened or has closed, or the ticket type or its ticket group is disabled. A disabled ticket cannot be booked by any strategy, complimentary included. - 403 — the event's registration limit has been reached. - 400 — a required field is missing, a required address sub-field is missing, or the email value is not a valid address. - 400 — the seller account is not connected to Stripe. - 429 - the store has reached its daily limit on added bookings. - 400 - both paymentOption and complimentary: true were supplied, or neither was. Exactly one is required. - 400 - a couponId was supplied on a complimentary booking. A comp is already at zero, so no coupon can be applied. Example uses: - "Comp two VIP tickets for jane@example.com on the Summer Gala" → complimentary: true - "Register Acme Corp for 10 standard tickets to the conference and invoice them" → paymentOption: { manualType: 'invoice' } - "Add a walk-in booking for the Tuesday workshop, paying cash on arrival" → paymentOption: { manualType: 'cash_on_delivery' }fields to get the defaults: Name, Email address, and a required billing Address. - If you pass fields, include at least one email element with type: "email" and required: true, or the request fails. - When tax is off and nothing is shipped, pass fields with just a name and a required email field so customers are not asked for an address. - To collect an address, prefer a single element: "address" field with collect: "billing" (or "billing_and_shipping" when you also need a shipping address). It renders a grouped address with country selector. The flat-field types (address-line1, shipping-address-line1, etc.) still work for niche cases but should not be the default. Tax settings: - Tax is enabled by default with mode: "stripe". Omit tax entirely unless the merchant explicitly asks to change tax behaviour. - Three modes are available via tax.mode: - "stripe" — Stripe Tax calculates tax automatically based on the customer's address. Requires an address field on the page (use element: "address") and Stripe Tax configured in the merchant's account. - "fixed" — A fixed tax rate is applied. Call list_tax_rates first to find an existing rate. Pass its id as productData.fixedTaxRateIds, or omit it to use the account's default rate. If no suitable rate exists, use create_tax_rate to create one first. - "none" — No tax is collected. Set tax.enabled: false and tax.mode: "none" (or just tax.enabled: false). - If the merchant sells B2B, add a Tax ID field such as a VAT number. Payment options: - Only these enabled combinations are supported: full, invoice, partial, cash_on_delivery, full + invoice, full + partial, or full + cash_on_delivery. Example uses: - "Create a checkout page for my $49 online course" — set name, productData.title, price.amount: 4900, price.currency: "usd" - "Create a monthly subscription at $29/month" — set price.amount: 2900, price.currency: "usd", price.recurring: { interval: "month", intervalCount: 1 } - "Create a 3-payment plan of $100 each" — set price.amount: 10000, price.currency: "usd", price.paymentPlan: { interval: "month", intervalCount: 1, planIterations: 3 } - "Create a pay-what-you-want page with a $5 minimum" — set price.amount: 500, price.payWhatYouWant: true - "Create a checkout page with a one-time price and a monthly subscription option" — set productData.prices: [{ billingType: "one_time", amount: 4900, currency: "usd", label: "One-time" }, { billingType: "recurring", amount: 1000, currency: "usd", label: "Monthly", recurring: { interval: "month", intervalCount: 1 } }] - "Create a checkout page with annual and monthly plans" — set productData.prices: [{ billingType: "recurring", amount: 9900, currency: "usd", label: "Annual", recurring: { interval: "year", intervalCount: 1 } }, { billingType: "recurring", amount: 1000, currency: "usd", label: "Monthly", recurring: { interval: "month", intervalCount: 1 } }] After creation, return: - data.id: the checkout page ID - data.name: the internal page name - data.hostedUrl: the live checkout page URL - data.dashboardUrl: the dashboard edit URLpageIds and ticketTypeIds to create a coupon that is usable on all checkout pages and events. - Set pageIds to restrict the coupon to one or more specific pages. - ticketTypeIds are narrower than pageIds: they restrict the coupon to specific ticket types within an event. - If the page is an event, you must first restrict the coupon to that event by including the event page ID in pageIds, and only then can you narrow it to certain tickets from that event with ticketTypeIds. - Do not pass ticketTypeIds by themselves. Every ticket type must belong to one of the pageIds provided, or the request fails. How discount types work: - amountOff is a fixed amount discount. It requires currency. - percentOff is a percentage discount applied to the eligible checkout total. - Set exactly one of amountOff or percentOff, never both.themeOverrides and hostedLayoutType; list_theme_properties lists what can be set. Set themeId (from list_themes) to use a theme. After creation, return: - data.id: the event ID - data.name: the internal event name - data.hostedUrl: the live event URL - data.dashboardUrl: the dashboard edit URLthemeOverrides and hostedLayoutType; list_theme_properties lists what can be set. Set themeId (from list_themes) to use a theme. After creation, return: - data.id: the form page ID - data.name: the internal page name - data.hostedUrl: the live form URL - data.dashboardUrl: the dashboard edit URLtax.mode: "fixed". Inclusive vs exclusive: - Exclusive (inclusive: false) — tax is added on top of the price. A $100 product with 20% tax costs the customer $120. - Inclusive (inclusive: true) — tax is already included in the price. A $100 product with 20% inclusive tax means $83.33 + $16.67 tax. Default rate: - Set default: true to make this the account's default tax rate. Pages with tax.mode: "fixed" and no explicit fixedTaxRateIds will use the default rate automatically. - Only one tax rate can be the default at a time. Setting a new default replaces the previous one. This is not Stripe Tax. Fixed tax rates apply a flat percentage regardless of customer location. To calculate tax dynamically by address, use tax.mode: "stripe" on the page instead (no tax rate needed).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.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.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.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.create_checkout_page. For a direct lookup after creation, pass the returned page id into this tool.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.create_form. For a direct lookup after creation, pass the returned page id into this tool.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.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.data.product.id on get_checkout_page). Read-only.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.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.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.variables). Read-only.[hidden]; headers are viewed and edited at the returned dashboardUrl. Use list_webhooks to find the id. Read-only.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 searc…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.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@exam…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.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 com…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.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.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.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 …tax.mode: "fixed". Check whether a suitable rate already exists — avoid creating duplicates. This tool returns all rates — there is no filtering or pagination.prefix or search, since the whole list, or the whole elements group, is too long to read at once. 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, paymentDetails, 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. 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.createdAt. Use a theme's id as themeId on a page, or as baseThemeId to create a copy. Read-only.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.[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.guidance.eligible - whether cancellation can proceed (false for already-canceled or expired subscriptions). - guidance.options.timing - available timing choices (immediately, at_period_end, custom_date). Fixed-term plans (planIterations > 0) only support immediately. - guidance.options.currentPeriodEnd - the end of the current billing period, useful when choosing at_period_end. - guidance.sideEffects - plain-language consequences of canceling (the Stripe subscription ends and no further invoices generate; whether a cancellation is already scheduled). Use list_subscriptions first to find a subscription ID, or get_subscription to view the full record without the cancellation guidance overlay. Example uses: - "I want to cancel this customer's subscription - what should I know first?" - "Can subscription 6812fe6e9f39b6760576f01c still be canceled at the end of the period?" - "What changes if I cancel this subscription now?"invoiceUrl is a fresh signed link.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. Every change applies to live checkouts at once. There is no undo, because the previous values are not kept. Setting deleted: true stops the coupon working at checkout immediately.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.themeOverrides and hostedLayoutType; list_theme_properties lists what can be set. Set themeId (from list_themes) to use a theme; changing it replaces the page's own theme settings.themeOverrides and hostedLayoutType; list_theme_properties lists what can be set. Set themeId (from list_themes) to use a theme; changing it replaces the page's own theme settings.variables keep their value; null resets. Built-in themes are read-only: copy one with create_theme and baseThemeId.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.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.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.Click any prompt to copy it.
App Stats
63
Tools
3
Prompts
ChatGPT
Platforms
Category
Payments and TransfersWorks with
Data refreshed daily
