Skip to main content
Glama
Payware MCP Server

Payware MCP Server

Official
by payware

payware_operations_simulate_callback

Read-onlyIdempotent

Simulate webhook callback scenarios to generate the payload a merchant callbackUrl receives, enabling you to build and test handlers against real callback shapes and retry behavior.

Instructions

[Merchant] Simulate callback scenarios for testing webhook handling.

Generates the payload a merchant's callbackUrl actually receives, so a handler can be built and tested against the real shape. Four properties of that shape are easy to get wrong:

1. Absent means absent, not zero. The payload omits properties with no value rather than sending null or 0. statusMessage, passbackParams, fee, feeFixed and feeRate are all simply missing when they do not apply. A missing fee means the fee is unknown for that transaction - it does not mean the transaction was free. Do not write a handler that reads payload.fee as a number without checking it is there.

2. finalized is absent on EXPIRED. An expired transaction is closed by the platform's expiry sweep, which sets no finalization moment. Every other status carries one.

3. EXPIRED is a non-payment, not a failure. The payer never paid within timeToLive. Release the order or the stock, as you would for a cancellation - do not treat it as an error to retry.

4. Deduplicate on (transactionId, callbackType). payware retries a callback up to 15 times, backing off from about a second to at most 5 minutes between attempts, until the endpoint answers any 2xx. That pair is stable across every retry of the same event, and it is the key payware guarantees. A handler that does not deduplicate will eventually process one payment twice.

Not on this payload: deliveryAddress (removed 2026-08-07 - fetch it from payware_operations_get_transaction_history, which is authenticated and tenant-scoped), producerPartnerId, transactionType and initiatedBy (the last two are carried on TRANSACTION_PROCESSED, which merchants do not receive).

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_simulate_callback"
  }
}

Input Schema

NameRequiredDescriptionDefault
feeNopayware's fee on this transaction plus VAT where it applies, at the currency's smallest payable unit (e.g. '0.29'). The payer's institution transfers it to payware alongside the merchant's payment, and amount is net of it. Not always two decimals - it follows the currency. Pass null to model the anomaly case, where a transaction has no recorded fee and the server OMITS the property entirely; that is deliberately distinguishable from a genuine '0.00'.
poiIdNoSet to simulate a POI sale: the callback then carries the poiId of the POI that created the transaction
amountNoTransaction amount (e.g., '57.60')57.60
feeVatNoThe VAT included in fee (fee minus feeVat is payware's fee excluding VAT), at the same scale; zero when no VAT applies (reverse charge, or a merchant outside the EU). Present exactly when fee is (server TransactionCallbackPayload). Defaults to zero.
statusNoTransaction status to simulateCONFIRMED
feeRateNoVariable rate of the applicable fee configuration, e.g. '0.0150' = 1.5%. Informational, same as feeFixed. Pass null to model a transaction with no fee configuration.0.0150
currencyNoTransaction currencyEUR
feeFixedNoFixed fee component of the applicable fee configuration, e.g. '0.1000'. Informational, for reconciliation. Present on FINALIZED callbacks since 2026-08-21 - before that a merchant got the total fee but not the breakdown that produced it. Pass null to model a transaction with no fee configuration, where it is omitted.0.1000
callbackUrlNoURL where callback would be sent (for simulation only)
paymentMethodNoPayment method chosen by customer. A2A = direct transfer. CARD_FUNDED = card-linked account. BNPL = buy now pay later. INSTANT_CREDIT = credit line.
statusMessageNoCustom status message for the transaction callback
transactionIdYesTransaction ID to simulate callback for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the description does not need to re-establish that it is a safe, non-mutating call — and it correctly does not claim otherwise. It does add substantial context beyond annotations, but that context concerns the simulated payload's semantics (absent fields, EXPIRED, retry/dedup key) rather than the tool's own behavior. Crucially, it never answers the operational question raised by the callbackUrl parameter — whether the simulation merely returns a payload or actually issues a request to that URL — which is the main behavioral ambiguity for a caller.

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-loaded with a one-line purpose, then four numbered, bolded points that each map to a concrete handler bug. The closing "Not on this payload" list is dense but earns its place by naming removed fields and where to get them instead. It runs long for a single-call simulator, and point 4's retry backoff detail is more than a caller strictly needs, keeping it below a 5.

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?

With 12 parameters and no output schema, the description does the heavy lifting on what the returned payload contains and, importantly, what it omits — that is well covered. What is missing is the shape of the tool's own response: whether the payload is returned directly, wrapped with metadata, or actually delivered to callbackUrl. For a simulation tool whose entire value is the artifact it produces, that is a material gap.

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

Parameters4/5

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

Schema coverage is 100%, so per-parameter meaning is already carried by the schema and the baseline is 3. The description still adds cross-parameter semantics the schema only states locally: it groups fee, feeFixed, feeRate and statusMessage as jointly omitted rather than null/zero, and warns that a missing fee means "unknown," not free. That grouping is genuine added meaning beyond reading twelve independent parameter blurbs.

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?

"Simulate callback scenarios for testing webhook handling" names a specific verb (simulate) and resource (callback/webhook payload) and states the artifact produced: "the payload a merchant's callbackUrl actually receives." That framing separates it from payware_operations_process_transaction and create_transaction, which operate on real transactions rather than generating a test payload.

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 is explicit: build and test a handler against the real shape. It also routes the agent elsewhere for a related need, pointing to payware_operations_get_transaction_history for deliveryAddress because it is authenticated and tenant-scoped. It stops short of stating exclusions (e.g. that this does not actually deliver a request or create a real transaction), which keeps it off a 5.

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