A product catalog can tell an agent what exists without giving it any ability to buy.
That boundary is easy to miss when discovery documents, action names, and a chat interface appear in the same integration. “The agent can search products” is a capability statement. “The agent can complete checkout” is a much stronger contract involving order creation, payment authorization, confirmation, and outcome handling.
What the recorded QA run showed
A recorded QA run of our gateway discovered five store actions: product search, order listing, order retrieval, order cancellation, and order return. It did not discover an order-creation or checkout action. The UCP discovery document advertised catalog search only and reported no payment handlers.
The inventory supports a narrow conclusion: the connected surface exposed catalog discovery and selected operations over existing orders. It does not prove that purchases or payments are possible, impossible everywhere, or safe to add without further design. The internal store chat could not be certified because the server required an AI model configuration. That blocked chat certification; it did not turn the discovery inventory into a checkout test.
This distinction is also why capability discovery should be read as an allowlist, not as a promise inferred from product language. If checkout is absent, an agent should not improvise a create-order call, treat an existing order endpoint as a purchase flow, or claim that payment completed.
Define the contract at the boundary
A checkout contract needs more than a product lookup. It should specify cart construction, price and availability freshness, taxes and shipping where applicable, customer and delivery details, payment method selection, user confirmation, authorization, idempotency, and the possible outcomes of the downstream processor. It should say which steps are merely proposals and which perform an external write.
Discovery should make these distinctions machine-readable. Separate read capabilities from mutation capabilities. Name checkout and payment actions explicitly, publish their schemas and required approvals, and expose payment handlers only when a supported payment path actually exists. A catalog response should never be interpreted as permission to purchase. HTTP's safe-method semantics likewise distinguish read-only intent from requested changes; a successful read is not evidence of a completed purchase.
The application should enforce the same boundary server-side. A client guessing an unadvertised action should receive a clear unsupported-capability response, not a partially executed workflow. If a future checkout flow is added, bind confirmation to the reviewed cart, current prices, recipient, currency, and payment terms. Do not use a catalog search result as the final amount.
A sanitized illustrative capability summary might read:
Available: search catalog; view existing orders.
Not available: create order; authorize payment; complete checkout.
That is an example of explicit disclosure, not a report of a new interface.
Test discovery and behavior independently
First test discovery: required actions, schemas, links, payment declarations, and versioning. Then test each advertised action with authorized and negative cases. Separately test that absent capabilities cannot be invoked by guessing names or paths. For a checkout-capable system, add tests for stale prices, duplicate submissions, changed carts, declined payment, uncertain processor responses, and confirmation of the final order state.
Do not report checkout coverage because a catalog call succeeded. The evidence for a purchase must include a deliberately authorized end-to-end flow and a confirmed outcome, with test or simulated payment clearly distinguished from real funds.
Limits
This observation is a discovery inventory and integration boundary, not a claim that no purchase system exists elsewhere. It does not certify the store chat, payment processing, shipping, or real customer transactions. The general lesson is simple: an advertised read capability describes what can be read; it is not a checkout contract.
Disclosure: This article is published by the Allowfy team and generated autonomously by AI from recorded Allowfy QA evidence and technical references, then checked for consistency with those records. It is not a production case study; the underlying work was performed in a sandbox, not against production.
