@payware/mcp-server 1.5.0 → 1.5.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@payware/mcp-server",
-  "version": "1.5.0",
+  "version": "1.5.1",
   "mcpName": "io.github.payware/mcp-server",
   "description": "Official MCP server for payware payment API integration",
   "main": "src/index.js",

package/src/isv/transactions/create-transaction.js

@@ -171,11 +171,13 @@ now returns 403, check the merchant's plan first.
 answers **403 ERR_SHOP_NOT_IN_SCOPE**, and \`payware_shops_list\` returns only the in-scope ones.
 Omitting \`shop\` uses the merchant's default shop, which may itself be out of scope.
 
-ℹ️ **Producer attribution does not apply here.** \`producerPartnerId\` / \`terminalId\` /
-\`terminalManufacturer\` are accepted on direct merchant calls only. Whoever made the API call owns the
-sale, so an ISV call is an ISV sale even when the ISV's software is running on a hardware producer's
-terminal. Do not try to pass them through - use \`payware_operations_create_transaction\` from the
-merchant role if the terminal producer is meant to be attributed.
+ℹ️ **Producer attribution does not apply here.** Whoever made the API call owns the sale, so an ISV
+call is an ISV sale even when the ISV's software is running on a hardware producer's terminal, and the
+producer earns nothing from it. This tool therefore does not send \`producerPartnerId\` /
+\`terminalId\` / \`terminalManufacturer\`. The server does accept them on an ISV call - it checks
+them (an unrecognised producer is a 400) and records them for provenance - but they never move the
+sale to the producer. Use \`payware_operations_create_transaction\` from the merchant role if the
+terminal producer is meant to be attributed.
 
 **Transaction Types:**
 - PLAIN: Basic transaction without visual codes

package/src/merchant/transactions/create-transaction.js

@@ -258,7 +258,9 @@ agreement with payware. Three fields, all optional:
   characters. payware records it and never interprets it: no format, no uniqueness enforcement, and
   nothing about pricing or attribution depends on it.
 - \`terminalManufacturer\` - device manufacturer as the terminal reports it. Max 64 chars, no control
-  characters. Recorded for provenance; a mismatch is surfaced in settlement review, never blocked.
+  characters. Recorded for provenance. payware's internal attribution review counts each producer's
+  sales by reported manufacturer, so a build running on another vendor's hardware stands out; it is
+  never blocked.
 
 Two things worth knowing:
 1. **It never changes what the merchant is charged.** The producer's share comes out of payware's own