Discuss your project
Commerce and AI

Agency commerce and UCP: preparing your catalog and checkout for AI-driven purchases

Agency commerce is not limited to displaying a product flow. To allow an agent to compare and then purchase, the merchant must make each step explicit, verifiable, idempotent, and reversible.

Agency commerce and UCP: preparing your catalog and checkout for AI-driven purchases

Assistants can already search for, compare, and recommend products. The next step is to allow them to prepare or execute certain steps of the purchase. In 2026, the term agentic commerce refers to these journeys in which an agent acts based on a user's intention, interacts with commercial systems, and maintains the context up to the order.

Google presented the Universal Commerce Protocol, or UCP, as an open standard intended to describe commerce capabilities consistently across surfaces and merchants. Reference integrations particularly target conversational experiences. As of August 17, 2026, some functions remain in pilot or subject to eligibility: technical preparation should be distinguished from commercial availability.

Versions, diagrams, drivers, and access conditions evolve; they must be confirmed in the official documentation before any integration.

What a software buyer changes

A human visitor can interpret an imperfect page, open several tabs, understand an ambiguous promotion, or call support. An agent needs more explicit contracts:

  • stable identifiers;
  • structured attributes;
  • dated prices and availability;
  • readable policies;
  • documented transactional steps;
  • typed errors;
  • reversible actions;
  • proof of consent.

Agency-driven commerce therefore pushes e-commerce towards a more API-first architecture. It does not replace the website: it creates an additional surface that must share the same product and transactional truth.

UCP in a few words

UCP describes purchase cycle capabilities and allows a merchant to publish a profile indicating the supported versions and functions. In the integration documented by Google, this profile is exposed at a well-known address, and APIs can then manage discovery, checkout, and other steps according to the chosen mode.

The important principle is not just the format. It is a matter of separating:

  • the surface where the user expresses their need;
  • the agent who orchestrates;
  • the commercial server who remains master of his rules ;
  • identity and payment service providers;
  • control and execution systems.

The merchant retains responsibility for their prices, policies, orders, and customer relations according to the integration model.

Starting with the truth produces

An agent cannot properly recommend an item whose data is poor. The foundation is the PIM, the catalog, or the product database:

  • global identifier and SKU;
  • variants ;
  • standardized attributes;
  • compatibilities;
  • images ;
  • availability;
  • price;
  • promotions;
  • restrictions;
  • deadlines;
  • sellers if marketplace ;
  • return conditions.

Marketing descriptions are not enough. The distinguishing criteria must be structured: dimensions, material, usage, consumption, size, standards, compatible parts, or delivery area.

Freshness is essential. Data extracted the day before may be wrong at the time of checkout.

The nine capacities to make explicit

1. Discovery

Search and filter with business criteria, not just keywords. The result specifies the match, the variants, and the limits.

2. Price

Calculate a deterministic price according to currency, customer, quantity, promotion, tax, and date. The agent must know the validity period.

3. Stock

Distinguish between availability information and booking. Concurrent conflicts must produce a usable error.

4. Delivery

Calculate options, deadlines, costs, relay points, restrictions, and footprint if available, from a validated address.

5. Identity

Manage guest, existing account, consents, loyalty, and preferences without exposing more data than necessary.

6. Checkout

Create a versioned session containing lines, prices, taxes, delivery, policies, and expiration. Any changes must be visible.

7. Payment

Use appropriate tokenization, authentication, and confirmation. The agent does not receive raw card data.

8. Order

Confirm only once, provide an identifier, disclose the status, and manage cancellation or modification according to the rules.

9. After-sales

Make support, returns, refunds, warranty, disputes, and proof of purchase accessible.

Architecture linking an agent and a commerce server to catalog, pricing, inventory, checkout, payment, order, and customer service systems.

Design an idempotent checkout

Agents and networks can retry. A repeated request must not create two orders. Each write operation uses an idempotency key, a session version, and an explicit state.

Example of a cycle:

  1. session creation;
  2. addition or validation of lines;
  3. price calculation;
  4. delivery selection;
  5. confirmation of policies;
  6. payment authorization;
  7. final validation;
  8. order creation;
  9. issuance of the confirmation.

If the price or stock changes, the server returns a structured difference. The agent requests a new confirmation instead of proceeding silently.

Keep humans in sensitive decisions

A “buy me the cheapest” mandate is insufficient if significant constraints exist. The interface must clarify:

  • maximum budget;
  • exact or substitutable product;
  • quantity;
  • address;
  • deadline;
  • seller;
  • guarantees;
  • return conditions;
  • frequency for a subscription.

A final confirmation is necessary when the mandate is not precise enough, the price changes, or the transaction involves a risk. Independent actions remain limited to explicit policies.

Manage identity without creating an opaque profile

Identity linking can connect a user account to the merchant via mechanisms like OAuth. The scopes must be minimal and revocable. The user knows what information is shared and for what purpose.

Avoid turning the agent into an uncontrolled aggregator of preferences. Personalization must distinguish between data necessary for ordering and optional profiling.

For B2B, the identity includes company, role, purchasing rights, cost center, limit, approver, and contractual terms.

Payment and verifiable mandate

Payment security relies on the PSP and existing regulatory mechanisms. Agentic protocols can add proof of intent: amount, merchant, scope, duration, and authorized products.

The system keeps:

  • initial request;
  • options presented;
  • consent;
  • version of the conditions;
  • authorization;
  • result;
  • possible cancellation.

This traceability protects both the user and the merchant without unnecessarily recording sensitive payment method data.

Secure the agent interface

The risks include:

  • false merchant identity;
  • catalog handling;
  • prompt injection in a product sheet;
  • redirect hijacking;
  • double order;
  • price change;
  • return fraud;
  • data leak;
  • promotion abuse;
  • API saturation.

The controls include signature, TLS, mutual authentication depending on the context, limits, schema validation, isolation of untrusted content, capability list, logs, fraud detection, and human confirmation.

A product description should never be interpreted as a system instruction by the agent.

Prepare the support and the feedback

Commerce does not stop at payment. An agent must be able to retrieve the order with the user's authorization, explain its status, initiate a compliant return, and forward it to support.

Policies must be structured and consistent with the displayed legal text. The merchant remains reachable through clear means. Automation must not obscure a right to human recourse.

Measure something other than conversion

Follow:

  • relevant discovery rate;
  • price or stock errors;
  • session creation;
  • requests for reconfirmation;
  • double avoided calls;
  • payment failures;
  • cancellations;
  • returns;
  • disputes;
  • time until human assistance;
  • margin;
  • satisfaction.

An increase in conversion accompanied by a high return rate may indicate that the agent is choosing poorly.

A realistic roadmap

Step 1: make the data reliable

Identifiers, attributes, prices, stock, policies, and quality of feeds.

Step 2: decouple the capabilities

Create stable read APIs before write operations.

Step 3: industrialize the checkout session

Version, expiration, idempotence, errors and recalculation.

Step 4: integrate identity and payment

Permissions, consent, confirmation, fraud, and audit.

Step 5: display order and after-sales

Articles of association, support, feedback, and reversibility.

Step 6: add a protocol

Implement UCP or another interface when the channel and conditions justify it, without coupling the core business to a single surface.

A useful preparation even without an immediate channel

The required upgrade for agency commerce is already improving the site, applications, marketplaces, and partners: clean catalog, deterministic pricing, robust checkout, idempotent APIs, and connected customer service.

Partitech can audit the catalog and the funnel, design the APIs, integrate the payment and order systems, and then add agent interfaces. The goal is to make commerce interpretable and safe for new channels without losing control of the transaction or the customer relationship.

Let's talk about your project

Evaluate the readiness of your e-commerce platform for agentic commerce with Partitech. Contact Partitech.

Share this article