Retrieve a paginated list of payments processed through your Checkout Page account. Pass livemode: false to read test-mode records.

For questions about a customer's full purchase history query the other transaction tools.

Example customer support uses:

• Customer asking about order status - orderId lookup, report status and key details (product, amount, date)

• Customer unsure if payment went through - search by email, identify which records are paid vs failed.

• Customer says they were double-charged - search by email, compare all records. Check status and amountPaid on each.

• Customer asking about a coupon - orderId lookup, check coupon object and report the coupon details (code, label, discount amount).

• Customer asking for a receipt - orderId lookup, confirm the order details (product, amount, date, payment method). An invoiceId on a paid record means an invoice was generated; get_invoice returns it with a link to its PDF. Invoices can be resent from the Checkout Page dashboard.

• Customer asking about a refund - orderId lookup, check status. If refunded: confirm the full refund, report amountRefunded as the refund amount, lastRefundAt as the refund date, and lastRefundReason as the reason. If partial_refund: report amountRefunded vs amountPaid so the customer knows how much was refunded and how much they retain. lastRefundReasonNote may contain a merchant-written explanation.

• Customer asking about a download or delivery - orderId lookup, confirm the purchase is paid. No download URL or delivery tracking is available on payment records. For digital products, downloads are accessed via the customer portal. The customer should check their purchase confirmation email first; if they can't find it, sharing a link to the customer portal will let them access their downloads.

• Customer says checkout keeps failing - search by email. Look for records with problem statuses: failed, draft, draft_expired, created, pending, unpaid, or canceled. A draft or draft_expired record may mean the customer didn't complete the checkout form. Check paymentError on failed records for a specific error message.

• Customer wants full purchase history - this tool only covers payments. Also query the other transaction tools with the same email/customerId to get the full picture. Combine results before presenting. Do not present results from list_payments alone as a complete history.

• Order lookup returns 0 results - try list_bookings(orderId: "...") and list_subscriptions(orderId: "..."). The order may be a booking or subscription, not a payment. Always try all tools before reporting an order doesn't exist.

Example uses:

• "Show me failed payments" - filter by status: 'failed'

• "Show me payments for checkout page X" - filter by pageId

• "Show me all payments from customer X" - filter by search with their name or email

• "Find order ORD-9182" - filter by orderId

• "Show me abandoned carts" - filter by abandonmentStatus: 'abandoned'

• "Show me refunds" - filter by status: 'refunded' (also check status: 'partial_refund' separately - only one status per call).

Money amounts: All monetary amounts are returned in the smallest currency unit (for example, 10661 USD = $106.61, 299 EUR = €2.99, 500 JPY = ¥500). Divide by 100 before displaying amounts to merchants or customers, noting that some currencies such as JPY do not use decimal minor units.

Customer name fields. There are four places a name can appear: (1) customerName - the canonical customer name from the customer entity. This is the primary name field. (2) billing.name - from the payment card, may differ from the checkout form name. (3) shipping.name - from the shipping details, when provided. (4) fields array - the name entered on the checkout form. These may not all match - e.g. a spouse's card used for someone else's order. For questions about a name on an order, customerName is the best default; check the other three if there's a discrepancy.

Data limitations for common support questions:

• Receipt/invoice requests: invoiceId confirms an invoice was generated. get_invoice returns the invoice and a link to its PDF. Resending an invoice is only possible in the Checkout Page dashboard.

• Refund details: amountRefunded, lastRefundAt, lastRefundReason, and lastRefundReasonNote are available on refunded/partial_refund records. Limitation: these fields only reflect the most recent refund action - earlier reasons are overwritten. Full refund history requires the Checkout Page dashboard.

• Historical refund limitation: for records created before 2026-01-22T06:43:28.000Z, some refund metadata may be incomplete. A record can show status: refunded, partial_refund, or sometimes canceled while amountRefunded remains 0 or refund detail fields are missing. When reviewing older records, treat the refund status as authoritative but only quote an exact refunded amount if the record explicitly includes it.

• Cancellation metadata: canceledReason is only set when a cancellation is performed from the Checkout Page dashboard (canceledBy is set) or through the API (canceledByApiKey is set). For cancellations from other flows, these fields may be empty or null, so cancellation reason analysis is often unavailable.

• Email delivery: No tool in the MCP exposes email delivery information. A purchase can be confirmed (via this tool) but email delivery status cannot be checked through this tool. Email delivery can be verified and emails can be resent from the Checkout Page dashboard.

• Download/delivery: No download URL, delivery status, or fulfilment tracking exists on payment records. For digital products, downloads are accessed via the customer portal.

• Payment failure reasons: paymentError provides the last error message but is not guaranteed to be set. paymentError persists even after a successful retry - always check status first.

• Address information: billing.address and shipping.address are often empty objects, especially for non-physical products.

Date filters: Always use UTC timestamps with the Z suffix (e.g. 2026-03-01T00:00:00Z). Never use local timezone offsets — dates are stored and compared in UTC.

Limit and large response handling:

Use the right limit for the task:

• Single-record lookups (order lookup, customer search, "has X paid?"): use limit: 10 or less.

Tips for common questions:

• For count questions ("how many paid orders?"), filter by the relevant status (e.g. status: "paid") and read total from the response. An unfiltered total includes all records regardless of status (failed, draft, etc.) - always filter when counting a specific category.

• For "who paid?" or "has X paid?", use search with the customer's email and check the status field.

Payments are returned sorted newest-first. Use cursor-based pagination (starting_after / ending_before) to page through large result sets. starting_after and ending_before cannot be used simultaneously. Max limit is 100, default is 10.

Cross-tool routing:

Records do NOT overlap between tools - a transaction only appears in one tool. Payments, bookings, and subscriptions are separate record sets. There is no risk of double-counting when combining results across tools.

Name search: search on this tool matches customerName, customer email, productTitle, and orderId. Searching by name (e.g. search: "Nelson") returns all records for customers with that name. If you need more customer profile details (company, phone, tax ID), use list_customers or get_customer.

Order lookup: If "look up order 12345" returns 0 results here, try list_bookings(orderId: "12345") and list_subscriptions(orderId: "12345") - the order may be a booking or subscription, not a payment.

Full customer history: For "show me everything this customer has bought," query all transaction tools with the same customerId or search email and combine results.

Customer profile: For profile data (company, phone, billing email, tax ID), use list_customers or get_customer - payment records have customerName, customerId, customerEmail, billing.name, and shipping.name but not the full profile fields.

This tool is read-only. You cannot process refunds, resend receipts, update customer details, change shipping addresses, or resend download links. For these actions, explain what's currently on file. The merchant can manage orders in the Checkout Page dashboard. The customer can access their purchases through the customer portal.