ADI
ADI Blog Agent commerce 3 min read

How the merchant trust catalog works

A merchant agent can sell from the merchant shop, but ADI needs an independent trust reference for what that agent is allowed to sell. The merchant catalog in ADI is that reference: a canonical product whitelist used to validate agent commerce before money moves.

ADI does not replace the merchant shop or force the merchant agent to use ADI as its storefront.

The ADI product list is the merchant-approved trust reference used during AP2 cart and payment validation.

This prevents invented SKUs, stale offers, silent price drift, and agent promises that the merchant never approved.

The misunderstanding to avoid

The product list inside ADI is not meant to become the merchant agent's whole operating environment. The merchant agent can still live in Shopify, WooCommerce, a custom shop, a marketplace tool, or the merchant's own commerce stack.

ADI plays a different role. It holds the merchant-approved reference that can be checked when an agent sale turns into an accountable transaction.

Two catalogs, two jobs

The merchant shop catalog is operational: it powers storefronts, search, merchandising, promotions, stock workflows, and fulfillment.

The ADI trust catalog is evidential: it records which products the merchant has approved for governed agent commerce.

The merchant agent may use the shop catalog to talk to customers, but the final AP2 cart must still match the ADI trust catalog before ADI treats it as payable.

What happens during an agent sale

Merchant agent sale with ADI trust validation

The merchant agent sells in the merchant environment. ADI validates the resulting cart against the merchant-approved catalog before payment authorization.

sequenceDiagram
    participant Buyer as Buyer Agent
    participant MerchantAgent as Merchant Agent
    participant Shop as Merchant Shop
    participant ADI as ADI Trust Layer
    participant Issuing as Prepaid Issuing Card

    Buyer->>MerchantAgent: Ask for product or offer
    MerchantAgent->>Shop: Read operational catalog and stock
    Shop-->>MerchantAgent: Offer details
    MerchantAgent-->>Buyer: Proposed cart
    Buyer->>ADI: Submit AP2 cart and payment mandate
    ADI->>ADI: Match SKU, merchant, active state, price, and stock reference
    alt Cart matches trust catalog and wallet/card policy
        ADI->>Issuing: Authorize prepaid virtual card spend
        Issuing-->>ADI: Authorization and transaction events
        ADI-->>Buyer: Receipt and audit trail
    else Cart does not match trust catalog
        ADI-->>Buyer: Decline with evidence
    end

What ADI verifies

The payee is tied to a known merchant organization.

Each cart item carries a SKU that exists in the merchant-approved ADI catalog.

The product is active and belongs to that merchant organization.

The quantity is within the available trusted stock reference.

The payable amount is calculated from the trusted catalog reference instead of blindly trusting the selling agent.

What this protects against

Without a separate trust catalog, a merchant agent can accidentally or maliciously offer products that no longer exist, prices that the merchant did not approve, or bundles that cannot be fulfilled. A buyer agent would see a plausible conversation but no independent proof that the commercial object is legitimate.

With ADI in the loop, the final payable cart is no longer just a text claim from an agent. It becomes a checked object bound to a merchant, a catalog entry, a mandate, a wallet/card policy, and an audit trail.

The hardening path

Catalog entries should become versioned so receipts can prove exactly which approved product state was used.

Price and currency checks should be explicit at mandate time so the agent cannot smuggle a different payable amount.

Catalog changes should be auditable because changing a trusted product is a governance event, not just content editing.

High-value commerce can add signed catalog snapshots so the merchant-approved offer is cryptographically bound to the transaction evidence.

CONTINUE READING

More articles from the technical reading layer.

OPEN AGENT TRUST Agent interoperability

How external agents verify an ADI merchant agent

A buyer agent does not have to live inside ADI to trust an ADI merchant agent. It needs public discovery, a resolvable agent identity, signed credentials, and a clear payment mandate path. This article shows how those pieces fit together.

A2A discovery makes the merchant agent reachable.

ADI trust discovery makes the merchant agent accountable.

AP2 VALIDATION Agent commerce

How ADI validates what a merchant agent sells

A merchant agent can describe an offer, but ADI should not pay from description alone. ADI validates the AP2 mandates, the merchant organization, the product SKU, the trusted catalog entry, the buyer wallet, and the virtual-card policy before the transaction becomes authorized.

Conversation creates intent.

AP2 creates structured mandates.

INTEGRATIONS Agent commerce

Why shop integrations are trust inputs, not the trust layer

Shopify, WooCommerce, CSV, custom APIs, and marketplace connectors help ADI import merchant product state. They are not the trust layer by themselves. The trust layer begins when ADI normalizes that product state, binds it to a merchant organization, and uses it in mandate and payment checks.

Integration is ingestion.

Catalog governance is trust.

INTEGRATION MODES Agent integration

Three ways to connect an external agent to the ADI trust layer

An external agent does not need to run inside ADI to be governed by ADI. The practical question is how the relying system authenticates that agent and when it asks ADI for trust, delegation, and certificate state.

Standard mode: API key or agent token plus online trust lookup

Enterprise mode: OIDC plus trust lookup

TRUST FOUNDATIONS Agent trust

Why agents need a trust layer

An API token only tells you whether a request is authenticated. A trust layer tells you which agent is acting, on whose behalf, which proofs are valid, and whether that agent can be stopped.

When OAuth stops being enough

Which questions a trust layer must answer

ARCHITECTURE System architecture

Separating A2A, trust, and AP2

The key architectural principle is separating the layers. A2A is communication. Trust is governance. AP2 is payment behavior.

What A2A actually standardizes

When trust is additionally required

PRODUCT ADI stack

How ADI works as an agent trust stack

ADI is not a single interface. It is an operational layer that connects discovery, identity, trust, and payment flows for agentic systems.

The platform’s four layers

Where A2A, MCP, and AP2 meet

A2A EXPLAINED A2A fundamentals

What A2A is and what it is not

A2A gives agents a shared way to describe themselves, exchange messages, and execute tasks. It does not automatically solve identity binding, delegated authority, auditability, or payment control.

A2A standardizes discovery, messages, tasks, and declared security capabilities.

A2A does not by itself answer who the agent represents or what it is permitted to do.

AP2 FOUNDATIONS AP2 payments

What AP2 solves for agent commerce

AP2 gives agent commerce a structured model for intent, cart, payment authorization, and receipts. Without that model, every agent-payment integration invents its own fragile semantics.

AP2 introduces a common vocabulary for agent payment flows.

Mandates separate scope, intent, and final payment authorization.

TRUST FOUNDATIONS Agent trust

What agent trust actually means

Agent trust is not a brand claim. It is the operational ability to prove who an agent is, on whose behalf it acts, what it is allowed to do, and how that authority can be revoked or audited.

Trust begins where authentication alone stops.

A real trust layer must support revocation, inspection, and evidence.

PRODUCT EXPLAINER ADI stack

What ADI does in an agent stack

ADI is the trust and control layer that sits between agent interoperability and real business action. It helps organizations let agents act without treating those agents like ungoverned black boxes.

ADI is where governance enters the agent stack.

The platform connects external agents, enterprise controls, and transaction policies.

SIGNATURES AND SEALS Trust services

Human signatures vs organization eSeals

A human signature proves the will or approval of a natural person. An organization eSeal proves that a trust object was issued or sealed by a legal entity. In enterprise agent systems, those are different jobs and they should not be collapsed into one.

Human signatures answer: who personally approved this?

Organization eSeals answer: which legal entity issued or stands behind this artifact?