Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_operations_get_transaction_status

Read-onlyIdempotent

Checks the status of an ACTIVE transaction by ID so you can poll in-progress payments; use transaction history for completed or expired transactions.

Instructions

[Merchant] Get status of an ACTIVE transaction by ID (for completed/expired transactions use transaction history tool).

Endpoint: GET /transactions/{transactionId} Use Case: Check status of ACTIVE transactions only. This endpoint only returns transactions with ACTIVE status. Note: For transactions with final statuses (CONFIRMED, DECLINED, FAILED, EXPIRED, CANCELLED), use 'payware_operations_get_transaction_history' instead.

ā³ ACTIVE can outlast timeToLive. Never infer EXPIRED from the clock. Once the payer's institution has started the payment (it locks the transaction immediately before the money moves, which you do not see), the transaction stays ACTIVE past timeToLive until the money has moved: seconds for an instant or internal transfer, days for a deferred one (a transaction created with deferredAllowed: true). Its timeToLive then stops at the value it had when the payment started. Keep polling, or wait for the callback: a transaction is EXPIRED only when payware says so, in the callback or in transaction history, and one that is no longer returned here has a final status there.

šŸ›ļø Product-originated transactions carry a nested product object. Since 2026-07-22 the presentation fields are grouped under product rather than sitting flat on the response - the old top-level imageUrl is gone. Discriminate a product-originated transaction by the presence of the object, not by probing individual fields:

{ "transactionId": "pw7e4rCToG", "amount": "57.60", "currency": "EUR",
  "product": { "productId": "pr7e4rCToG", "type": "ITEM", "name": "Cotton T-shirt, black",
               "shortDescription": "...", "longDescription": "...",
               "imageUrl": "https://...", "imageDigest": "9f86d081...", "imageContentType": "image/png",
               "imageBytes": 20480, "termsUrl": "https://...", "termsText": "...",
               "regularPrice": "63.36", "shippable": false, "quickPay": true, "shopName": "My shop" } }

Three things about that object:

  • imageDigest is an obligation, not decoration. It is the SHA-256 payware pinned for the image at imageUrl. Fetch the image, verify its bytes against this digest before rendering it to a payer, and fall back to a neutral placeholder on mismatch. Present only when imageUrl is the product's own image.

  • regularPrice is display-only, and appears only when there is a genuine saving - i.e. when it is higher than the transaction amount. The top-level amount and currency are authoritative and are what the payer pays; the object does not repeat them.

  • Availability follows the merchant's plan. imageUrl and termsUrl are Standard and above; termsText and the descriptions are universal. A missing field is a plan boundary, not an error.

For a pr/ps product identifier the values are resolved live; for the resulting pw transaction they are the snapshot frozen at creation, so the response always reflects what the payer could have been shown at scan time.

šŸ’° Amounts follow the currency, not a fixed two decimals. amount, fee, payerAmount and payeeAmount are decimal strings at the smallest unit their own currency can be paid in - none for JPY, two for EUR, eight for BTC. Parse them with a decimal type; never compare them as strings, and never assume two places. feeRate carries up to six decimals and feeFixed full stored precision: both are informational, and recomputing the fee from them and submitting that at finalize is rejected with ERR_FEE_MISMATCH. Echo fee back unchanged instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "transactionId": "<transactionId>"
    },
    "name": "payware_operations_get_transaction_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
partnerIdNoPartner ID from payware dashboard. Can use PAYWARE_PARTNER_ID env var as default.partner_12345
privateKeyNoRSA private key for JWT token creation. Can use PAYWARE_PRIVATE_KEY_PATH env var as default.
useSandboxNoUse sandbox environment for testing
transactionIdYesTransaction ID to check status for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context the agent could not otherwise know: a transaction can remain ACTIVE past timeToLive, expiry is only authoritative via callback or history, product-originated responses nest a `product` object, and plan tiers gate certain fields. It also warns that recomputing fees from feeRate/feeFixed causes ERR_FEE_MISMATCH, a concrete failure mode.

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

Conciseness3/5

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

The critical routing information is front-loaded in the first three lines, which is good structure, but the body balloons into a large JSON example and extensive response-handling guidance (image digest verification, currency decimals) that is tangential to selecting and invoking a status lookup. Much of it is useful context but delivered at disproportionate length.

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

Completeness4/5

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

With no output schema, the description reasonably compensates by explaining the nested product object, amount formatting, and plan-gated fields, so the agent can interpret the response. Nothing critical about invocation is missing; the only gap is that the volume of response detail crowds the operational guidance.

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 coverage is 100%, so partnerId, privateKey, useSandbox and transactionId are already documented in the schema. The description only implies that transactionId is a transaction identifier; it adds no format, source, or constraint details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get status of an ACTIVE transaction by ID') and immediately distinguishes itself from the sibling history tool in the first sentence. An agent can pick this over payware_operations_get_transaction_history without opening either 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?

Explicitly scopes usage to ACTIVE transactions and names the alternative, payware_operations_get_transaction_history, with the exact statuses (CONFIRMED, DECLINED, FAILED, EXPIRED, CANCELLED) that route elsewhere. It also tells the agent to keep polling or wait for the callback rather than inferring EXPIRED, which is actionable when-to-use guidance.

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

Deploy Server

Other Tools