Skip to main content
Glama
Sign In
Payware MCP Server

Payware MCP Server

Official
by payware
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

payware_operations_process_transaction

Destructive

Process a customer-created PEER transaction to accept a QR or barcode payment as a merchant. Provide the transaction ID, amount, currency, and reason to complete the charge.

Instructions

[Merchant] Process a PEER transaction (for merchants accepting payments by scanning customer QR/barcode).

Use Case: Merchant scans customer's payware QR code or barcode to accept payment. Note: Only PEER transactions (created by customers) can be processed by merchants. Flow: Customer creates transaction → Merchant scans QR/barcode → Merchant processes transaction

API Request Structure:

{
  "shop": "...",
  "account": "...", 
  "friendlyName": "...",
  "callbackUrl": "...",
  "passbackParams": "...",
  "trData": {
    "amount": "25.50",    // REQUIRED for processing
    "currency": "EUR",    // REQUIRED for processing
    "reasonL1": "...",    // REQUIRED for processing
    "reasonL2": "..."
  },
  "trOptions": {
    "timeToLive": 300     // Overwrites original transaction TTL
  }
}

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>",
      "amount": "<amount>",
      "currency": "<currency>",
      "reasonL1": "<reasonL1>"
    },
    "name": "payware_operations_process_transaction"
  }
}

Input Schema

NameRequiredDescriptionDefault
shopNoShop code (optional - uses default if not provided)
amountYesAmount as currency value to process (e.g., 25.50 for €25.50). Must be positive
accountNoAccount identifier (optional - uses default if not provided)
currencyYesTransaction currency (ISO 3-character code)EUR
reasonL1YesTransaction grounds description (required)
reasonL2NoTransaction grounds description continuation (optional)
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.
timeToLiveNoTime allowed for transaction processing in seconds
useSandboxNoUse sandbox environment for testing
callbackUrlNoURL to receive transaction status callbacks
friendlyNameNoAccount holder recognizable name (optional)
transactionIdYesTransaction ID to process: 'pw' (standard), 'pr' (product), 'pl' (placement: pays as its product, and the payment is attributed to the placement), 'ps' (soundbite). Up to 32 characters (identifiers may grow beyond today's 10).
idempotencyKeyNoOptional. Sent as the Idempotency-Key header. Use one value per payment (a UUID is typical) and the same value on every retry of it: a retry with the same key and body within 24 hours returns the transaction the first call created instead of a new one, and the result reports replayed: true. The same key with a different body is refused (422 ERR_IDEMPOTENCY_KEY_REUSED); a retry while the first call still runs gets 409 ERR_IDEMPOTENCY_KEY_IN_PROGRESS.
passbackParamsNoParameters passed back through callback

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds useful context — the three-step flow, that timeToLive overwrites the original transaction TTL, and that callbackUrl/passbackParams feed status callbacks — but says nothing about what success returns, when callbacks fire, or retry semantics. The idempotencyKey column documents 24-hour replay behavior in the schema while annotations say idempotentHint=false; this is a nuance the description leaves unaddressed rather than a true contradiction.

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?

The opening sentence, Use Case, Note and Flow are front-loaded and earn their place. The API Request Structure block is mostly redundant with a fully documented schema, which is the main source of bloat.

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

Completeness3/5

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

For a 15-parameter payment-capture tool with no output schema, the description covers the happy-path flow and required fields but leaves an agent without knowledge of the response shape, callback payloads, or failure handling. Adequate to initiate a call, not complete enough to handle its outcome.

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 every parameter is already documented, and the description only restates that amount, currency and reasonL1 are REQUIRED and explains the timeToLive override. The embedded JSON request sketch adds no field meaning beyond the schema and omits several parameters (transactionId, idempotencyKey, partnerId, useSandbox) entirely.

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

Purpose4/5

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

States a specific verb and resource ('Process a PEER transaction') plus the concrete physical scenario (merchant scanning a customer QR/barcode), which clearly separates it from create_transaction and get_transaction_status. It stops short of naming the sibling to use when the transaction does not yet exist.

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

Usage Guidelines4/5

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

The Use Case and Flow lines give clear context for when to invoke: the customer has already created a PEER transaction and the merchant is now scanning it. The note 'Only PEER transactions (created by customers) can be processed by merchants' is an effective exclusion, but no alternative tool is named for the create step or for status polling.

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