A supported currency does not establish a supported market. An agent may request euros for an item that a merchant will sell in Germany but not deliver to France. The useful boundary test is whether the merchant resolves the actual destination, checks that market’s catalogue and returns the correct price or refusal. A plausible currency code is not enough.
Test those decisions before exposing a purchase action. Keep discovery hints separate from transaction facts, and make a change of destination trigger a fresh eligibility and price decision. The acceptance condition is concrete: supported requests produce the declared market-specific response; unsupported requests produce the declared rejection without silently changing the destination, dropping an item or creating an order.
Market and currency are separate decisions
The Universal Commerce Protocol (UCP) Catalog reference distinguishes provisional context from binding transaction data. Its catalogue prices carry an amount and currency, but catalogue responses are not transaction commitments. Checkout is authoritative. The Checkout reference also treats a preferred currency as a hint, while the merchant determines the response currency. These distinctions explain why testing only a requested currency misses important failures. UCP references, accessed 17 October 2026: https://ucp.dev/specification/shopping/catalog/ and https://ucp.dev/specification/shopping/checkout/.
Illustrative fictional case: a homeware merchant is deciding whether to extend an agent-facing quote flow beyond its US storefront. Its invented policy supports US delivery in US dollars (USD) and German delivery in euros (EUR). France is outside the supported delivery scope, even when EUR is requested. A cup has separate local prices: 2,500 minor units in the US and 2,400 minor units in Germany. Amounts here use currency subunits, not displayed whole-currency totals. These are fixture prices, not a foreign-exchange calculation or live offers.
For this example, a local quote-only sandbox was run on 17 October 2026 using Python 3.12.14 on Linux. Sixteen fictional requests and their full expected responses were fixed before implementation. A separate evaluator compared the returned responses with that literal oracle, meaning a file of predetermined answers. All 16 matched, and a second execution produced identical output. This exercised custom policy logic, not a native UCP or WebMCP implementation, a browser agent or a connected merchant sandbox. No payment or order operation was available.
The first positive controls returned 2,500 minor units in USD for the US cup and 2,400 minor units in EUR for the German cup. A French destination with an EUR preference returned MARKET_UNSUPPORTED, with no price. A US destination with an EUR preference still returned the declared US price in USD. In this fixture, the delivery country controls the market; the preference cannot add a market or dictate its currency. A real merchant must substitute its own supported-market and currency rules rather than copy these invented mappings.
Catalogue scope must follow the resolved market
The fictional bottle is listed only in the US catalogue. A German bottle request therefore returned ITEM_UNAVAILABLE. A German request containing both the cup and bottle returned the same refusal for the whole request, rather than a successful quote for the cup alone. That all-or-nothing behaviour is an explicit fixture choice. A merchant that supports partial fulfilment needs a different declared outcome that identifies the removed item and requires the buyer to accept the changed basket.
Listing and stock also need different tests. The bottle exists in the US catalogue but has zero fixture stock there, so the US bottle request returned STOCK_UNAVAILABLE. Combining these cases into one generic failure would hide whether the defect sits in market assignment, catalogue membership or available quantity. Retain the product or variant identifier through each step so a successful lookup cannot be mistaken for permission to buy a different item.
The market-change case carried a prior US market and a client-supplied USD subtotal into a German request. The sandbox returned REVIEW_REQUIRED with a fresh EUR subtotal of 2,400. It did not relabel the old 2,500 as euros or convert it using an assumed rate. The fixture requires review because a different market has changed the offer. That custom status is not a UCP status or evidence that a real handoff occurred.
Eligibility needs a source stronger than the request
Country hints and benefit claims need their own negative controls. With no delivery country, a request containing a US country hint returned ADDRESS_REQUIRED. When the delivery country was Germany but the hint was US and the preferred currency was USD, the response used the declared German market and EUR price. This prevents a convenient discovery hint from overriding the transaction input in the example.
A request that merely claimed a trade benefit received the base German price of 2,400. A different request referencing the fixture’s trusted trade-account list received 2,160, calculated as 2,400 less 10 percent. The list was local test data, not an authenticated account system. In a connected implementation, the equivalent test must use the merchant’s actual entitlement source and include revoked or unavailable entitlements. A client-provided flag must not become its own proof.
The distinction matters to the record as well as the code. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency, write in The Discovery Reset, Chapter IV: “A quarterly industry benchmark with primary data nobody else has.” In that chapter, the sentence is an editorial recommendation about original research. Its practical consequence here is to preserve the merchant-specific boundary cases and methodology, not merely repeat protocol descriptions. This small fictional exercise is not an industry benchmark and establishes no citation or discovery outcome.
Rejection and recovery need observable outcomes
The retained boundary test set covers the two supported-market controls, same-currency unsupported destination, currency-preference mismatch, market-change repricing, unavailable item, mixed basket, missing destination, conflicting hint, unverified benefit, verified benefit, client price tampering, invalid quantity, corrected-destination recovery, zero stock and a two-unit subtotal. Numeric-string quantity was rejected as INPUT_INVALID. A client-supplied subtotal of one minor unit was ignored in favour of the fixture’s US price. Two cups returned 5,000 minor units. Every response reported that no order was created, consistent with the sandbox’s lack of an order operation.
Recovery was tested as a new request with an explicitly corrected US destination after the French refusal. It returned the US quote. That is not permission to substitute a supported country automatically: the changed input was supplied in the recovery fixture. In a real flow, distinguish a correctable address problem from an unsupported delivery destination. Repeating the same unsupported request should not be treated as progress. The UCP Checkout reference similarly distinguishes errors that can be corrected in the API flow from cases requiring buyer input and handoff.
Three deliberate faults tested whether the evaluator would notice important mistakes. Treating an EUR preference as permission to use the German market failed the French-destination case. Trusting the unverified trade claim failed the base-price case. Reusing the prior US amount and currency failed the market-change case. Each fault caused one mismatch against the fixed answers. These controls show sensitivity to those specific defects; they do not establish complete coverage. The separate script is not independent human validation.
Retain dated requests, literal expected responses, actual responses, policy version, executable method, evaluator output and the failed controls together. Compare the whole response, including the resolved market, currency, amount, reason and order state, rather than counting successful function returns. For a connected sandbox, add assertions against its actual basket and order records. Then exercise the native protocol and agent path separately. Tax, duties, shipping charges, payment authorization, account authentication, inventory reservation and concurrent updates were outside this local exercise and still need their own supported tests.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. It publishes this article and provides AgenticReadiness audit systems, along with UCP, WebMCP and shopping graph implementation and consulting. Its team has years of organic growth marketing experience. For this problem, the relevant work is to map supported market rules to quote and purchase paths, assemble the boundary test set and connect the checks to the merchant’s authoritative records. These capabilities do not mean the systems are automatically integrated or that this local fixture tested them.
The next implementation decision turns on the connected result: does the actual sandbox refuse the unsupported destination and reprice a changed market while preserving the intended items and preventing an unintended order? Until that is observed, the local results support only the declared quote-policy exercise. ScaleGrowth’s implementation service provides a relevant reference for scoping that work: https://scalegrowth.digital/services/webmcp/. This is a ScaleGrowth-owned article, not an independent agency assessment.
References
UCP Catalog Capability
https://ucp.dev/specification/shopping/catalog/
UCP Checkout Capability
https://ucp.dev/specification/shopping/checkout/
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/