Skip to content
Commerce360

Agent-ready commerce

Ready for AI shopping assistants

When a buyer asks an AI assistant to reorder supplies, the assistant needs a safe way to shop with you. Commerce360 lets outside assistants browse your catalog, get contract-priced quotes, and check out with your store — under rules you control. Here is what works today and what is still a pilot. Open “Technical detail” under any section for the specifics.

  1. 01

    An assistant connects

    With a credential you issue, tied to your store.

  2. 02

    It sees only its tools

    Just the tools its permissions allow.

  3. 03

    It quotes at contract prices

    Searches, checks stock, and builds a priced cart.

  4. 04

    It checks out within limits

    Under a spending limit a person set — or the buyer confirms.

  5. 05

    Every call is recorded

    In your audit trail, for your team to review.

An assistant connects with a credential you issue; it sees only the tools it is allowed; it quotes at contract prices; it checks out within a person-issued spending limit or with the buyer’s confirmation; every call is recorded.

MCP server

Available on request · pilot

A menu of commerce tools for AI assistants

Model Context Protocol (MCP) is a common way for AI assistants to use outside tools. Our MCP server gives an assistant your catalog, quotes, cart, checkout, orders, and returns — as a buyer would use them.

  • 57 tools in one catalog: 31 for buying and 25 back-office tools that only your staff’s credentials can see.
  • Each tool needs its own permission. An assistant only sees the tools it has been granted.
  • An assistant acting for one buyer can’t see or order for another buyer.
  • The server runs in production today. We issue credentials for outside assistants per customer, on request; none have been issued yet.
See every tool
Technical detail
  • Remote MCP over Streamable HTTP (stateless).
  • Credentials: OAuth 2.1 bearer tokens from a configured issuer (verified against its JWKS, asymmetric algorithms only; RFC 9728 protected-resource metadata), or tenant-bound API keys stored as SHA-256 digests and compared in constant time.
  • Every credential is bound to one tenant, an actor (operator, buyer, or agent), and scopes. The tenant always comes from the credential, never from tool arguments.
  • Per-tool scopes: tools/list shows only callable tools, and tools/call re-checks. Back-office scopes are dropped from buyer and agent credentials.
  • Per-call delegation: for each gateway call the edge mints a 60-second token carrying tenant, actor, subject, buyer, and scopes; the gateway verifies it and rejects a tenant mismatch.
  • Buyer pinning at the edge and at the gateway.

UCP checkout

Pilot live for a demo store

Checkout through the Universal Commerce Protocol

The Universal Commerce Protocol (UCP) is an open standard that lets an AI assistant check out with a store. A buyer links their business account with their consent; the assistant can then search, check out on contract prices, and follow the order.

  • Live today as a pilot on a demo store.
  • Passes the public UCP conformance suite: 53 tests passed, 0 open defects.
  • Our B2B extension adds purchase-order numbers, cost centers, tax exemption, and purchase approvals.
  • Google’s agentic checkout enrollment is pending, so it is not yet available inside Google’s assistant.
Read the UCP B2B extension
Technical detail
  • UCP version 2026-08-25: checkout, cart, fulfillment (rate-shopped carrier options), discount, and order capabilities.
  • Platform requests are verified with RFC 9421 HTTP message signatures; order webhooks follow Standard Webhooks with signed payloads.
  • Production defaults: checkout needs a linked business account; 120 requests per minute per platform.
  • Cards arrive only as Google Pay / Stripe tokens — raw card numbers are never accepted.
  • Conformance: 53 passed · 13 not applicable · 11 skipped (optional fixtures), run 2026-09-25 (docs/UCP_CONFORMANCE.md).

Spending limits

Available on request, with the MCP server

The assistant can only spend what a person allows

Before an assistant can place an order through the MCP server, a person — the buyer or your staff — gives it a spending limit with a cap. The assistant can only spend under that cap.

  • An assistant can never create its own spending limit.
  • The order total is checked against the cap when the order is placed. An order that comes out above the cap is voided.
  • A limit is held while a checkout runs, so it can’t be spent twice at once — and it is only used up if an order is actually created.
  • Today a limit caps the amount. Limiting it to certain items or quantities is on the roadmap.
  • In UCP checkout, orders are placed on the buyer’s own linked account; spending limits are not part of UCP checkout yet.
Technical detail
  • AP2-style intent mandates: issue_purchase_mandate is human-only (mandate:issue is rejected for agent credentials, stripped from OAuth tokens, and re-enforced by the gateway).
  • The gateway stamps the issuer on each mandate and lets an agent spend only a mandate a person issued whose subject names that agent.
  • Placement by an agent (place_quoted_order / place_basket_order / authorize_checkout) requires a mandate; concurrent spend returns mandate_in_use; the mandate is consumed only when an order is created and released otherwise.
  • Not yet enforced on spend: the mandate’s sku/quantity scope and audience.

Security

Built into the MCP server

Security, in plain words

An outside assistant gets the same checks as everyone else — and a few more.

  • Each credential belongs to one store and can only reach that store’s data.
  • Every tool call is recorded in your audit trail: who called, which tool, and the result. We keep a fingerprint of the inputs, not the inputs themselves.
  • Each credential has a rate limit, so a runaway assistant is slowed down.
  • Errors come back as plain codes, without internal details.
Technical detail
  • Audit of every tools/call: tenant, actor, subject, credential, tool, SHA-256 of the canonicalised arguments, outcome (ok / error / denied / rate_limited), and latency — written to the operator audit trail.
  • Per-credential token-bucket rate limiting, checked before other per-request work; oversized JSON-RPC batches are refused.
  • Stable error codes with fixed messages; only allow-listed machine reasons pass through.
  • Fail-safe startup: the server refuses to start in production with insecure settings or without a delegation secret.

How our own assistant works: How our AI works. Agents that run your back office: Agents for your back office. Every order channel: Channels.

Join the AI-assistant pilot

Tell us which assistants your buyers use. We’ll set up credentials for your store and walk through the checks with your team.

Book a demo