Checkout Page

get_payment

Read-only

Retrieve a single payment by ID from your Checkout Page account. Pass livemode: false to read test-mode records.

Use list_payments first if you need to discover a payment ID by customer email, customer name, product title, or order ID. Event bookings are a separate record type — use list_bookings for those.

If the payment ID does not exist for the authenticated seller, returns a 404 error: "Payment not found".

Example uses:

"Fetch payment 6812fe6e9f39b6760576f01c"
"Show me the full details of this payment"
"Was this payment refunded, and how much?"

This tool is read-only. Refunds and cancellations must be performed in the Checkout Page dashboard.

Input Schema

Name	Required	Description	Default
`livemode`	No	Set to false to read test-mode records (created while a page was in test mode). Defaults to live records.
`paymentId`	Yes	The ID of the payment to retrieve. Use `list_payments` first if you need to discover the payment ID by email, name, customer, page, product, or date range. Bookings for event pages have their own IDs and are not retrievable here.

Output Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

addedOutput schema / properties / data / properties / canceledByApiKey

Added value: +{
+  "description": "ID of the API key that canceled this, when it was canceled through the seller API. The key may have been deleted since; `canceledByApiKeyName` keeps its name.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / data / properties / canceledByApiKeyName

Added value: +{
+  "description": "Name of the API key that canceled this, as it was at the time. Kept when the key is deleted later.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedOct 29, 2026

addedOutput schema / properties / data / properties / archivedAt

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "When the merchant archived this, hiding it from their default bookings list in the dashboard. Archiving changes nothing else: the payment, tickets and `orderStatus` stay as they were. Absent unless archived.",
+  "type": "string"
+}

addedOutput schema / properties / data / properties / archivedBy

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The userId of the team member who archived this. Absent unless archived.",
+  "type": "string"
+}

Changed2 schema fields changedOct 29, 2026

changedOutput schema / properties / data / properties / orderStatus / anyOf

Previous value: -[
-  {
-    "enum": [
-      "active",
-      "canceled",
-      "archived"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "active",
+      "canceled"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / data / properties / orderStatus / description

Previous value: -"Order lifecycle status. Valid values are active, canceled, archived."New value: +"Order lifecycle status. Valid values are active, canceled."

Changed1 schema field changedOct 28, 2026

addedOutput schema / properties / data / properties / paidAt

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "When the payment was paid in full. For an invoice or cash payment this is when the merchant recorded the payment, which can be long after `createdAt`. Empty until fully paid, including a deposit with a balance still due."
+}

Changed1 schema field changedOct 20, 2026

addedOutput schema / properties / data / properties / processingFeeContribution

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "amount": {
+          "description": "Contribution in the smallest currency unit.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "fixedAmount": {
+          "description": "The fixed part.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "name": {
+          "description": "Name shown on the receipt, frozen at payment.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "percentage": {
+          "description": "Percentage used for the contribution.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "percentageAmount": {
+          "description": "The part from the percentage.",
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "What the customer chose to add to cover the processing fee, worked out on the total with tax. Not one of `fees`."
+}

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / data / properties / fees / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "amount": {
-          "description": "Fee amount in the smallest currency unit.",
-          "type": [
-            "number",
-            "null"
-          ]
-        },
-        "name": {
-          "description": "Fee name.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "percentage": {
-          "description": "Fee percentage when applicable.",
-          "type": [
-            "number",
-            "null"
-          ]
-        }
-      },
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": false,
+      "properties": {
+        "amount": {
+          "description": "Fee amount in the smallest currency unit. For a fee with both a percentage and a fixed amount, the sum of `percentageAmount` and `fixedAmount`.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "fixedAmount": {
+          "description": "The fixed part of `amount`, in the smallest currency unit, already multiplied by quantity or tickets when the fee multiplies. Only set on a fee with both a percentage and a fixed amount.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "name": {
+          "description": "Fee name.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "percentage": {
+          "description": "Fee percentage when applicable.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "percentageAmount": {
+          "description": "The part of `amount` from the percentage, in the smallest currency unit. Only set on a fee with both a percentage and a fixed amount. Can be 0, e.g. when a 100% coupon leaves nothing for the percentage to apply to.",
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

First observedOct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces that with a named side-effect exclusion (refunds/cancellations). Beyond annotations it adds concrete error behavior (404 "Payment not found" when the ID isn't owned by the authenticated seller) and the livemode test-data toggle. It doesn't describe pagination or response shape, but an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and routing in the first two paragraphs, then errors, examples, and constraints. The example-uses block and the livemode sentence are mildly redundant given the schema and output schema, but nothing is bloated or buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Combines a simple 2-param retrieval, a rich schema, and an output schema, and the description still covers the missing pieces an agent needs: cross-sell to list_payments, bookings exclusion, 404 semantics, and read-only scope. Nothing required to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already fully documented, including the livemode test-mode meaning and the paymentId pattern/'list first' hint. The description's "Pass livemode: false to read test-mode records" mostly restates the schema rather than adding new semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Retrieve a single payment by ID") and scopes it to the Checkout Page account. It also explicitly separates itself from list_payments and from event bookings, so an agent can distinguish it from the many get_* siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use routing: "Use list_payments first if you need to discover a payment ID by customer email, customer name, product title, or order ID," and redirects event bookings to list_bookings. It also names what can't be done here (refunds/cancellations) and points to the dashboard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Checkout Page tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?