DEV Community: Artemii Karkusha

UCP April 2026: Cart, Catalog, and Signals Change Everything

Artemii Karkusha — Fri, 10 Apr 2026 16:51:20 +0000

On April 8, 2026, the Universal Commerce Protocol shipped its most significant release since launch. Eighty-nine commits from twenty-plus contributors over eleven weeks. Twenty-seven new schemas. Five breaking changes. And three entirely new capabilities that transform UCP from a checkout protocol into a full commerce lifecycle specification.

After analyzing UCP's architecture against Visa's VIC reference agent, I've been tracking this spec closely. This release answers the question I raised in that analysis: can an open protocol cover the entire pre-purchase journey — discovery, browsing, cart building — without losing the schema rigor that makes it production-ready?

The answer is yes. Here's what changed, what broke, and what it means for integration teams building on top of UCP.

The Pre-Purchase Story Gets a Protocol

The headline feature of this release is three new top-level capabilities that cover everything before checkout.

Cart: Browsing Without Commitment

UCP now has a formal Cart capability (dev.ucp.shopping.cart) — and the design reveals how carefully they thought about the distinction between "exploring" and "buying."

A cart is not a checkout. This sounds obvious, but most commerce platforms blur this line. Shopify's cart is a pre-checkout. Magento's quote becomes an order. The boundaries are fuzzy, and that fuzziness creates integration nightmares when you need to sync cart state across systems.

UCP's cart has a deliberately simple lifecycle:

Aspect	Cart	Checkout
State model	Binary — exists or 404	Lifecycle — pending → active → complete
Pricing	Estimated totals	Final, committed pricing
Payment	None	Required for completion
Sharing	`continue_url` for handoff	Session-bound
Conversion	Converts to checkout via `cart_id`	Converts to order on completion

The conversion mechanism is idempotent — passing the same cart_id always returns the same checkout_id. This follows the Idempotency Mandate at the protocol level, preventing duplicate checkouts when network retries happen during cart-to-checkout conversion.

Real-World Example:
In a multi-platform integration where an AI agent builds a cart across Shopify and Magento storefronts, UCP's cart-checkout separation means the agent can accumulate items from different merchants into separate carts, then convert each to a checkout independently. The cart's continue_url enables handoff between agents — one agent discovers products, another completes the purchase. This is the kind of workflow that falls apart when cart and checkout are the same object.

Catalog Search and Lookup: Discovery Gets Structured

Two new capabilities handle product discovery — and they're designed to be adopted independently, which is the right architectural call.

Catalog Search (dev.ucp.shopping.catalog.search) provides free-text search with structured filters:

// UCP Catalog Search — semantic query with filters
interface CatalogSearchRequest {
  readonly query?: string; // Optional — enables filter-only browsing
  readonly filters?: {
    readonly category?: readonly string[]; // OR semantics
    readonly price?: {
      readonly min?: number; // Minor units (cents)
      readonly max?: number;
    };
  };
  readonly context?: {
    readonly country?: string;
    readonly language?: string; // BCP 47
    readonly currency?: string; // ISO 4217
    readonly intent?: string; // Buyer purpose signal
  };
  readonly pagination?: {
    readonly limit?: number; // Default 10, business sets upper bound
    readonly cursor?: string;
  };
}

Two design decisions stand out here. First, query is optional — meaning you can do filter-only browsing, image search, or any other discovery modality via extensions. Second, category uses an array with OR semantics and supports multiple taxonomies (Google Product Category, Shopify, merchant-custom). This avoids the taxonomy lock-in problem that plagues catalog integrations between PIM systems and commerce platforms.

Catalog Lookup (dev.ucp.shopping.catalog.lookup) handles targeted retrieval when you already know what you want:

// Batch lookup with correlation tracking
interface CatalogLookupRequest {
  readonly ids: readonly string[]; // Product IDs, variant IDs, SKUs
  readonly filters?: SearchFilters; // Optional post-resolution filtering
}

// Response variants carry input correlation
interface VariantWithCorrelation {
  readonly variant: Variant;
  readonly inputs: readonly {
    readonly id: string;
    readonly match: "exact" | "featured"; // How this was resolved
  }[];
}

The inputs correlation on the response is particularly well-designed. When you batch-lookup 10 product IDs and get back 15 variants, each variant tells you which input IDs resolved to it and whether the match was exact (variant-level) or featured (product-level, server-selected). This eliminates the guesswork that happens in every catalog integration where you request items by ID and get back a flat list with no context about which request each result satisfies.

Production Pattern

The search/lookup split mirrors how mature PIM systems already work internally. Akeneo PIM separates search (Elasticsearch-backed, fuzzy, ranked) from retrieval (MySQL-backed, exact, complete). UCP formalizing this at the protocol level means your integration layer can route each operation to the right backend without the commerce platform needing to support both in a single endpoint.

Signals: Authorization Without Friction

The most architecturally significant change in this release isn't a new capability — it's the signals field added across checkout, cart, catalog search, and catalog lookup.

Signals are platform attestations about the buyer context — things the platform has directly observed or verified through third parties. They use reverse-domain naming (dev.ucp.buyer_ip, dev.ucp.user_agent, com.example.risk_score) and flow from platform to merchant on every request.

// Signals on a checkout request
interface CheckoutWithSignals {
  readonly signals?: {
    readonly "dev.ucp.buyer_ip"?: string;
    readonly "dev.ucp.user_agent"?: string;
    readonly [key: `${string}.${string}.${string}`]: unknown;
  };
}

This replaces the deprecated risk_signals field and represents a fundamental shift in how UCP handles trust. Instead of checkout-only risk data, signals flow through the entire commerce lifecycle — from product search through purchase. A merchant can adjust search results, cart pricing, and checkout approval based on the same signal data.

The reverse-domain naming is enforced via JSON Schema propertyNames, meaning custom signal providers can extend the namespace without collision. Shopify can define com.shopify.buyer_authenticated, Stripe can define com.stripe.risk_level, and they'll never conflict.

Real-World Example:
In a SAP Commerce Cloud integration, fraud signals today come from the payment gateway at checkout time — too late to prevent catalog abuse. With UCP signals flowing through search and lookup, a merchant can throttle high-velocity product lookups from suspicious IPs before they even hit the cart. This is defense-in-depth at the protocol level, not bolted on as a payment-gateway afterthought.

Breaking Changes That Actually Matter

Five commits carry the ! breaking marker. Here's what requires migration work versus what you can absorb passively.

Must Migrate: Signed Amounts on Totals

total.json now uses signed_amount.json instead of unsigned amount.json. This fixes a real schema bug — discounts needed to be both >= 0 (from amount.json) and < 0 (from discount semantics), which was unsatisfiable.

The fix consolidates sign constraints into total.json as the single source of truth:

Total type	Sign constraint
`subtotal`, `tax`, `fee`	Must be >= 0
`discount`, `items_discount`	Must be < 0

Migration: Update your Zod schemas and type definitions. If you were manually working around the unsigned amount constraint for discounts, you can now remove that workaround.

Must Migrate: Order Schema Overhaul

Orders now have a 1:N relationship with checkouts (one order can span multiple checkouts), currency is required, and adjustments use totals instead of amount. The quantity.original field tracks pre-adjustment quantities.

Migration: Update your order processing pipeline. The amount → totals rename on adjustments will break deserializers. The currency requirement may need a default value in your mapping layer if your upstream system doesn't always provide it.

Must Migrate: Embedded Protocol Error Alignment

Delegation error responses moved from JSON-RPC error to result using the standard error_response envelope. This is a wire-format change that will break embedded checkout implementations.

Migration: Update your ECP (Embedded Checkout Protocol) error handling. Errors now come through result with ucp.status: "error" instead of the JSON-RPC error field. The upside: ECP errors can now use recoverable severity, enabling retry logic that wasn't possible before.

Passive: Signals Replaces Risk Signals

risk_signals on checkout is deprecated but still accepted. Migrate to signals when convenient — this is additive, not breaking.

Passive: Discount Extends Cart

The discount extension's extends field changed from a string to an array (["dev.ucp.shopping.checkout", "dev.ucp.shopping.cart"]). If you're dynamically reading extends, handle both string and array forms.

The Schema Explosion: 27 New Types

This Universal Commerce Protocol release added 24 new shared type schemas on top of the 3 capability schemas. Here's the taxonomy:

Catalog Product Model (12 schemas): product, variant, product_option, option_value, detail_option_value, selected_option, category, description, media, rating, price, price_range. This is a complete product data model — comparable to what you'd find in a PIM system's core schema.

Search & Filter Types (4 schemas): search_filters, price_filter, pagination, input_correlation. Cursor-based pagination with required has_next_page and conditional next_cursor — no more guessing whether there's another page.

Monetary Types (3 schemas): amount, signed_amount, totals. The signed_amount type was the missing piece that enabled the totals fix.

Error Handling (2 schemas): error_code, error_response. Standard error envelope with ucp.status: "error" and messages[].

Security Types (2 schemas): signals, reverse_domain_name. Foundation for the signals framework.

The variant.json schema deserves special attention. It carries availability.status as an open vocabulary string (in_stock, backorder, preorder, etc.) rather than a closed enum. This means platform adapters don't need to map proprietary availability states into a fixed set of values — they can pass them through and let the consumer decide what each status means. The Schema Drift Trap teaches us that closed enums in integration schemas are a maintenance burden — open vocabularies with well-known values are more resilient to upstream changes.

What This Means for Integration Teams

If You're Building a UCP Platform Adapter

Good news: the ucp-js-sdk has already shipped v2.0.0 on npm with full support for the v2026-04-08 spec. All 27 new schemas are available as TypeScript types and Zod validators out of the box — no manual schema generation needed.

The catalog model (product, variant, option, media, rating) maps closely to standard commerce platform entities — but watch the price type, which uses integer minor units per ISO 4217. If your upstream platform uses decimal amounts (most do), you need a conversion layer.

The cart-to-checkout conversion is idempotent by spec. Your adapter must guarantee this — same cart_id → same checkout_id, always. Test this with concurrent requests.

If You're Building on the Embedded Protocol

The error response restructuring is your biggest migration item. All ECP delegation errors now use the standard error_response envelope through result instead of JSON-RPC error. Update your error handling, but gain recoverable severity for retry logic.

New ECP capabilities: ep.cart.* methods for cart management, ec.auth / ep.cart.auth for credential renewal during sessions. Plus ec_color_scheme query parameter for light/dark/auto theming.

If You're Consuming UCP via REST or MCP

New endpoints and tools to integrate:

Capability	REST	MCP
Cart	`POST/GET/PUT /carts`, `POST /carts/{id}/cancel`	`create_cart`, `get_cart`, `update_cart`, `cancel_cart`
Catalog Search	`POST /catalog/search`	`search_catalog`
Catalog Lookup	`POST /catalog/lookup`, `POST /catalog/product`	`lookup_catalog`, `get_product`
Order (new)	`GET /orders/{id}`	`get_order`

Service Definition Cleanup

The service definition files were renamed for clarity — openapi.json → rest.openapi.json, openrpc.json → mcp.openrpc.json, embedded.json → embedded.openrpc.json. If you're generating clients from these files, update your paths. The old filenames are gone.

Implementation Checklist

Universal Commerce Protocol Schema Migration (do first)

[ ] Regenerate types from 27 new schema files
[ ] Update total handling for signed_amount (discounts are negative)
[ ] Rename amount → totals on order adjustments
[ ] Add currency as required field on Order
[ ] Handle extends as string or array on discount capability

New Capabilities (adopt incrementally)

[ ] Implement Cart CRUD operations
[ ] Implement Catalog Search with cursor-based pagination
[ ] Implement Catalog Lookup with batch correlation
[ ] Wire cart-to-checkout conversion with idempotency guarantee
[ ] Add signals field to all outgoing requests

Embedded Protocol (if applicable)

[ ] Migrate ECP error handling from JSON-RPC error to result envelope
[ ] Implement ep.cart.* methods
[ ] Add ec.auth / ep.cart.auth reauth support
[ ] Support ec_color_scheme query parameter

Observability

[ ] Log all new capability requests with correlation IDs
[ ] Track cart-to-checkout conversion rates
[ ] Monitor catalog search latency by filter type
[ ] Alert on signal feedback messages (code: signal)

The Integration Maestro Perspective

The API Contract Rule: The strength of an integration is determined by the precision of its contract — not the sophistication of its implementation.

This UCP release demonstrates what happens when a protocol team takes schema governance seriously. Twenty-seven new schemas, five breaking changes — and every break has a clear migration path with sign constraints moved to a single source of truth, deprecated fields marked with transition annotations, and response envelopes unified across transports.

The Universal Commerce Protocol's cart-checkout separation alone solves a problem I've battled in every commerce integration project: platforms that conflate "browsing" with "buying" force every downstream system to understand the implicit state machine. UCP makes it explicit. Cart is exploration. Checkout is commitment. The boundary is a protocol-level guarantee.

For teams building agentic commerce, this release is the tipping point. Before April 2026, UCP handled checkout — which is valuable but incomplete. Now it covers discovery through purchase: search products, build a cart, convert to checkout, complete the order. The full lifecycle, with formal schemas at every step and signals flowing through every request for fraud prevention.

The Schema Drift Trap is the rule to watch here. Twenty-seven new schemas means twenty-seven new surfaces where your implementation can drift from the spec. Pin your SDK to the v2026-04-08 release. Run conformance tests on every deploy. Schema discipline now prevents production incidents later.

Visa VIC vs UCP: Two Competing Visions for Agentic Commerce

Artemii Karkusha — Fri, 10 Apr 2026 16:39:09 +0000

Visa just published vic-reference-agent — their open-source vision for how AI agents should buy things on behalf of humans. Five microservices, LangGraph orchestration, MCP tool integration, and a deep pipeline into Visa Token Service and Visa Intelligent Commerce APIs.

I spent two days dissecting every file in that repository. Not because Visa needs my code review — but because when the world's largest payment network publishes their architectural opinion on agentic commerce, it reveals something important about where this space is heading.

After building UCP (Universal Commerce Protocol) middleware that handles multi-merchant, multi-platform checkout for AI agents, I have a specific lens on what matters in this architecture. Here's the full analysis — what VIC gets right, where it falls short, and the fundamental design tension between card-network-centric and protocol-first approaches.

The VIC Architecture at a Glance

Visa's reference agent is a 5-service system orchestrated via Docker Compose:

Service	Stack	Role
Agent Frontend	React 19, TypeScript, Vite	Shopping agent UI + card management
Agent Backend	FastAPI, LangGraph, Python 3.12	AI agent orchestration + Visa API integration
Merchant MCP	Express, @modelcontextprotocol/sdk	MCP tool server bridging agent to merchant
Merchant Backend	FastAPI, SQLAlchemy, SQLite	Product catalog, cart, orders
Merchant Frontend	React, JSX, Vite	Traditional merchant storefront

The tech choices are solid for a reference implementation. FastAPI for the Python services, LangGraph for stateful agent orchestration, and the official MCP SDK with Streamable HTTP transport. Nothing exotic.

But the architecture reveals something deeper about Visa's mental model: the agent is a Visa customer, not a merchant customer. The entire system is designed around Visa's token lifecycle, not around merchant flexibility.

What VIC Gets Right

1. Payment Credential Security Is Best-in-Class

This is where VIC genuinely shines. The payment credential flow is the most sophisticated I've seen in any agentic commerce implementation:

The credential never touches the AI agent in plaintext. Here's the actual flow:

User enrolls their card PAN into Visa Token Service (encrypted with JWE)
VTS provisions a token with presentationType: ["AI_AGENT"] — a new token type specifically for agent commerce
The token gets enrolled in VIC (Visa Intelligent Commerce)
At checkout, VIC creates an intent with FIDO assurance data from the user's passkey
VIC retrieves tokenized credentials — a dynamic card number, expiry, and cryptographic CVV
These credentials flow through MCP elicitation to the merchant
After the merchant processes payment, VIC confirms the transaction status

The security layers are serious:

Message Level Encryption (MLE): RSA-OAEP-256 + A256GCM (JWE) for all VIC API calls
Field-level encryption: A256GCMKW for sensitive fields like PAN and risk data
HMAC-SHA256 request signing: Every API call gets an x-pay-token header
FIDO2/WebAuthn passkeys: Biometric step-up for payment authorization

Real-World Example:
The AI_AGENT token presentation type is new. Traditional e-commerce uses E_COMMERCE. By creating a distinct type, Visa can apply different risk scoring, different liability rules, and different fraud models specifically for agent-initiated transactions. This is a smart regulatory play — it gives card networks a way to treat agent purchases differently from human-initiated ones without breaking existing payment rails.

2. MCP Elicitation Pattern Is Elegant

The checkout_cart MCP tool uses server.elicitInput() to request payment details at checkout time:

// Merchant MCP server — checkout tool
const result = await mcpServer.server.elicitInput({
  message: "Payment information required",
  requestedSchema: {
    type: "object",
    properties: {
      card_number: { type: "string", title: "Card Number" },
      expiry_date: { type: "string", title: "Expiry Date" },
      cvv: { type: "string", title: "CVV" },
    },
    required: ["card_number", "expiry_date", "cvv"],
  },
});

The agent backend responds to this elicitation via a callback:

# Agent backend — elicitation handler
async def on_elicitation(context, params):
    if current_credentials:
        return ElicitationResult(
            action="accept",
            content=current_credentials
        )
    return ElicitationResult(action="decline")

This is a genuinely good pattern. The merchant doesn't know where the credentials come from — it just asks. The agent doesn't expose credentials until the merchant specifically requests them during a checkout operation. Clean separation of concerns at the protocol level.

3. Intent-Mandate-Transaction Model

VIC introduces a three-level hierarchy for purchase authorization:

Concept	Purpose	Lifecycle
Intent	What the buyer wants to buy	Created per checkout session
Mandate	Spending limit + constraints + time window	Bound to an intent, has `effective_until_time`
Transaction	Actual charge against a mandate	SUCCESS or FAILURE, confirmed back to VIC

This maps well to real-world agent scenarios. An autonomous agent might have a mandate to "spend up to $500/month on office supplies" — the intent is each purchase, the mandate is the budget constraint, and transactions are individual charges.

What's interesting is that UCP arrived at a remarkably similar abstraction independently — the AP2 Mandates Extension. UCP uses Verifiable Digital Credentials (VDCs) to formalize three distinct mandate types:

UCP Mandate	Purpose	Scenario
Intent Mandate	Grants the agent authority to purchase within defined constraints (budget, time window, categories)	Human-not-present: autonomous agent shopping
Cart Mandate	User's cryptographic signature on a specific cart — exact items and price, non-repudiable	Human-present: user reviews and approves
Payment Mandate	Signals AI agent involvement and user presence status to payment networks and issuers	Shared with payment rails for risk assessment

The key difference: VIC's mandate model is payment-rail-centric — the mandate lives inside Visa's infrastructure and is enforced by VIC. UCP's mandates are cryptographic and portable — they're signed VDCs that travel with the transaction and can be verified by any party in the chain (merchant, payment processor, issuer) regardless of the specific payment network.

UCP also makes a critical architectural distinction that VIC doesn't: human-present vs human-not-present scenarios. The Intent Mandate grants an agent autonomous spending authority with guardrails. The Cart Mandate requires the user's explicit, cryptographic approval of a specific cart. VIC's model conflates these two scenarios into a single intent — you always need a FIDO passkey assertion, even for autonomous agent purchases, which undermines the "autonomous" part.

Real-World Example:
Consider a corporate procurement agent authorized to buy office supplies up to $500/month. With UCP's Intent Mandate, the agent operates autonomously within those constraints — no human step-up needed for each purchase. With VIC, every purchase requires a FIDO passkey assertion, meaning someone has to physically authenticate with their device. That's secure, but it's not autonomous — it's just adding an AI layer on top of human-initiated payments.

The convergence on mandate abstractions from both a card network (Visa) and an open protocol (UCP) validates that this is the right architectural pattern for agentic commerce. But the implementation philosophy diverges: centralized enforcement (VIC) vs. portable, cryptographic proof (UCP).

Where VIC Falls Short

1. Single Merchant, Single Network, Zero Extensibility

Here's the fundamental problem: VIC is hardcoded to one merchant and one payment network.

The MCP server connects to exactly one merchant backend at http://reference-merchant-backend:8001. There's no adapter pattern, no registry, no routing. If an AI agent needs to comparison-shop across multiple merchants — which is literally the core value proposition of agentic commerce — the entire MCP server needs to be duplicated.

Compare this to a protocol-first approach where a single gateway handles multiple merchants:

// UCP approach — adapter pattern with tenant isolation
interface PlatformAdapter {
  readonly searchProducts: (query: SearchQuery) => Promise<readonly Product[]>;
  readonly createCart: (items: readonly CartItem[]) => Promise<Cart>;
  readonly placeOrder: (cart: Cart, payment: PaymentToken) => Promise<Order>;
}

// One gateway, N merchants via adapter registry
const adapter = adapterRegistry.resolve(tenant.platformType);
const products = await adapter.searchProducts(query);

VIC's design means each merchant needs its own MCP server, its own tool definitions, its own connection management. In production, this creates an N-microservices problem for N merchants.

2. Global Mutable State Kills Concurrency

This one surprised me in a Visa reference implementation. The agent service uses module-level globals:

# From reference-agent-backend/src/services/agent.py
current_thread_id: str | None = None
current_credentials: dict | None = None

Two users checking out simultaneously would corrupt each other's credentials. This is a demo-level pattern that would be a critical security vulnerability in production. Session isolation isn't optional in payment systems — it's the bare minimum.

Production Pattern

Payment credentials must be scoped to a session, never stored in global state. Use Redis-backed session stores with tenant isolation, TTL-based expiration, and cryptographic session IDs. The credential retrieval and the checkout completion must happen within the same session boundary — ideally with an idempotency key to prevent double-charge on retry.

3. No Formal Schema Governance

VIC has no published schema, no JSON Schema files, no OpenAPI specification, no automated compliance checks. The data contracts are implicit in Python Pydantic models and TypeScript Zod schemas within the MCP tool definitions.

This matters because schema drift is one of the most common failure modes in integrations. When Visa updates their VTS or VIC APIs, there's no automated way to detect breaking changes in this reference implementation. No conformance test suite, no gap analysis, no version tracking.

For comparison, production-grade protocol implementations track schema coverage explicitly — every field, every constraint, every validation rule mapped to a spec version. The Schema Drift Trap catches teams who skip this step: what works today breaks silently when the upstream API evolves.

4. Visa-Only Payment Rail

VIC only supports Visa cards. The entire system — VTS token provisioning, VIC enrollment, intent creation, credential retrieval — is built on Visa-proprietary APIs at cert.api.visa.com.

In the real world, merchants accept Mastercard, Amex, PayPal, Apple Pay, buy-now-pay-later, crypto, and bank transfers. An agentic commerce protocol that only works with one card network is like an integration middleware that only supports one ERP — technically correct but architecturally limited.

Open protocols handle this differently by abstracting the payment method behind a handler interface:

interface PaymentHandler {
  readonly id: string;
  readonly name: string;
  readonly type: "card" | "wallet" | "redirect" | "offline" | "other";
}

// Payment network is a detail, not a constraint
const handlers = await adapter.getSupportedPaymentMethods();
// Returns: Visa, Mastercard, PayPal, Klarna, etc.

The Architecture Comparison

Here's the systematic comparison across every dimension that matters for production agentic commerce:

Dimension	Visa VIC	UCP / Open Protocol
Nature	Reference demo	Production gateway framework
Protocol support	MCP only	REST + MCP + A2A + Embedded
Payment networks	Visa only	Network-agnostic (adapter-driven)
Merchant integration	Single hardcoded merchant	Multi-tenant, multi-platform
Adapter pattern	None	First-class PlatformAdapter interface
Schema governance	Implicit (Pydantic/Zod)	SDK-derived schemas, 150+ checks
Session management	In-memory + global state	Redis-backed, tenant-isolated, idempotent
Auth model	Visa API keys + HMAC + MLE + FIDO2	JWS request signing + tenant JWT
Agent orchestration	LangGraph baked in	Agent-agnostic (any HTTP client)
Testing	3 unit tests	222+ integration tests, E2E per adapter
Payment depth	Deep (VTS + VIC + FIDO)	Abstract (payment handler interface)
Mandate model	Intent → Mandate → Transaction (VIC-enforced)	3 VDC types: Intent / Cart / Payment (cryptographic, portable)
Human-not-present	Requires FIDO passkey for every purchase	Intent Mandate grants autonomous authority

The Flexibility Question

Is VIC more flexible than open protocols? No — and it's not trying to be.

VIC optimizes for a different axis: payment security depth over integration breadth. And within that axis, it's genuinely impressive. The token lifecycle management, the MLE encryption, the FIDO2 passkey integration — this is how a card network with decades of fraud prevention experience thinks about agent payments.

But flexibility in agentic commerce means:

Flexibility axis	VIC	Open Protocol
Add a new merchant	Duplicate MCP server	Register adapter + tenant
Support non-Visa payments	Impossible	Add payment handler
Switch LLM framework	Rewrite agent.py	Any HTTP client works
Deploy without Docker	Difficult (5-service coupling)	Single deployable + Redis
Add new protocol binding	Not supported	Add route handler

What Open Protocols Can Learn from VIC

Despite VIC being less flexible, it has patterns worth adopting:

1. MCP Elicitation for Credential Transfer

The elicitInput() pattern is protocol-level elegance. Instead of passing payment tokens in the request body, the merchant requests credentials at the exact moment they're needed. This creates a just-in-time credential flow that minimizes the window of credential exposure.

Open protocols that support MCP bindings should adopt this for checkout completion — it's strictly better than embedding payment tokens in a complete-session POST body.

2. Token Presentation Types

The AI_AGENT token type is forward-thinking. As regulators begin distinguishing between human-initiated and agent-initiated purchases, having distinct token types allows different risk scoring, liability rules, and fraud models per presentation type.

3. API Log Transparency

VIC logs every Visa API call and displays the full request/response in a dedicated UI panel. This follows the Observability Rule — if you can't see the data flowing through your integration, you can't debug it.

4. Convergent Evolution on Mandates

Both VIC and UCP independently arrived at mandate-based authorization for agent spending. This convergent evolution validates the pattern — any agentic commerce system needs a way to express spending authority with constraints. Where VIC adds value is in demonstrating how card networks can consume these mandates for risk scoring. The Payment Mandate concept (signaling agent involvement to issuers) is especially relevant as regulators begin distinguishing between human-initiated and agent-initiated purchases.

The Fundamental Design Tension

Here's what this comparison really reveals: card networks and open protocols are optimizing for different stakeholders.

Visa's VIC optimizes for the card network:

Every transaction flows through Visa rails
Token lifecycle is managed by Visa
Risk scoring happens at Visa's layer
The merchant sees tokenized credentials, not raw PANs

Open protocols optimize for the merchant ecosystem:

Any payment network can participate
Merchants keep their existing platform (Magento, Shopware, Shopify)
The protocol doesn't mandate a specific payment rail
Multi-tenant by design — one gateway serves many merchants

Neither approach is wrong. But they serve different masters. A merchant who already accepts multiple payment methods won't lock into a Visa-only agent flow. A bank that wants maximum control over the payment security stack won't trust an open protocol's payment handler abstraction.

Production Pattern

The winning architecture in production is probably a hybrid: an open protocol layer for merchant integration and multi-network support, with card-network-specific modules (like VIC) plugged in as payment handlers. VIC becomes an adapter, not the entire system. The protocol handles discovery, cart, and session management. The card network handles token lifecycle, credential retrieval, and transaction confirmation. Each layer does what it's best at.

The Broader Agentic Commerce Landscape

VIC and UCP aren't the only players. The agentic commerce space is moving fast, with major infrastructure bets from every layer of the stack:

Google's A2A protocol (now under the Linux Foundation with 50+ partners) handles agent-to-agent communication -- discovery via Agent Cards, task delegation, and real-time status updates. It's transport-agnostic (JSON-RPC, gRPC, REST bindings) and doesn't prescribe a commerce model. A2A operates at a different layer than UCP: it's how agents find and delegate work to each other, not how they buy things.
Anthropic's MCP (Model Context Protocol) connects AI models to external systems via tools, resources, and prompts. VIC uses MCP as its agent-to-merchant bridge. UCP defines its own protocol with REST as the primary transport today, with MCP as a potential future transport binding. MCP and UCP operate at different layers -- MCP is a model-to-system integration protocol; UCP is a commerce-domain protocol that could use MCP as one of its transports.
Shopify has gone all-in on agentic commerce -- far beyond wrapping existing APIs. They built entirely new infrastructure: a Catalog API for cross-merchant product search (billions of products, all Shopify stores), a Universal Cart that holds items from multiple merchants simultaneously, a Checkout Kit for embedded checkout in agent UIs, and multiple MCP servers (Catalog MCP, Storefront MCP). Shopify also co-developed UCP with Google as an open standard, with Walmart, Target, Etsy, and 20+ other retailers endorsing it. Their Agentic Storefronts feature makes all Shopify merchants discoverable in ChatGPT, Copilot, and Gemini by default.
Stripe launched the Agentic Commerce Suite with purpose-built payment primitives: Shared Payment Tokens (SPTs) that scope a buyer's payment method to a specific seller, amount, and time window; Agentic Network Tokens issued by Visa/Mastercard for agent-initiated payments; and the Agentic Commerce Protocol (ACP) co-developed with OpenAI. They also ship an official MCP server at mcp.stripe.com and the @stripe/agent-toolkit for LangChain, CrewAI, and Vercel AI SDK integration.
Adyen is building a Universal Token Vault -- a bank-grade, provider-agnostic tokenization system for agent transactions with portable tokens. They're collaborating on Google's AP2 (Agent Payments Protocol) and Visa's Trusted Agent Protocol, with a merchant-first framework that keeps merchants in control of tokenization strategies and payment routing.
Omnix takes a different angle entirely: source-available middleware that connects existing stores (Magento, Shopware, Shopify) to AI agents through UCP without replatforming. Instead of building new storefronts, Omnix Gateway translates existing platform APIs into UCP -- one integration, any agent. Paired with @omnixhq/ucp-js-sdk for runtime-validated schemas and @omnixhq/ucp-client for capability-aware UCP consumption, it's the adapter layer that makes UCP practical for merchants who aren't Shopify-native.

The API Contract Rule applies here: in a fragmenting ecosystem, the implementations that survive are the ones with formal, versioned, machine-readable contracts. VIC has strong security contracts but weak interface contracts. Open protocols tend to have the inverse. The ones that get both right will win.

Implementation Checklist

If you're building agentic commerce infrastructure, here's what to evaluate:

Protocol Layer

[ ] Multi-protocol support (REST for legacy, MCP for AI agents, A2A for agent-to-agent)
[ ] Formal schema governance with versioned specs
[ ] Automated conformance testing against the spec
[ ] Agent-agnostic design (no LLM framework lock-in)

Commerce Layer

[ ] Multi-merchant support via adapter pattern
[ ] Multi-tenant session isolation with idempotency
[ ] Payment network abstraction (not locked to one rail)
[ ] Full checkout lifecycle: search → cart → totals → shipping → payment → order

Payment Security

[ ] Tokenized credentials (never raw PANs in agent context)
[ ] Just-in-time credential retrieval (elicitation pattern or equivalent)
[ ] Step-up authentication for high-value purchases
[ ] Transaction confirmation loop back to the payment provider

Observability

[ ] Full request/response logging for all payment API calls
[ ] Agent decision audit trail
[ ] Credential access logging with session correlation
[ ] Alerting on checkout abandonment and payment failures

The Integration Maestro Perspective

The API Contract Rule: The strength of an integration is determined by the precision of its contract — not the sophistication of its implementation.

Visa's VIC reference agent is an impressive demonstration of payment security engineering. The token lifecycle, the MLE encryption, the FIDO2 passkeys — this is what 60 years of payment infrastructure experience looks like when applied to AI agents.

But a payment security demo is not a commerce protocol. Production agentic commerce needs multi-merchant discovery, multi-network payments, formal schema governance, and session isolation that doesn't rely on global Python variables.

The right mental model: VIC is a payment handler adapter for an open commerce protocol — not a replacement for one. The future architecture has an open protocol layer (UCP, or something like it) handling the commerce lifecycle, with Visa's VIC, Mastercard's equivalent, and every other payment network plugged in as adapters.

A 2 AM Integration Failure That Changed How I Design Systems Forever

Artemii Karkusha — Tue, 07 Apr 2026 12:51:02 +0000

Black Friday doesn't break systems.
It reveals them.

This story is about one of those moments — not because everything went down, but because it almost did. And because it permanently changed how I design enterprise architectures.

The Night Everything Converged

It was Black Friday season — after weeks of preparation.

There had been planning. There had been load testing. There had even been a strict code freeze in place more than a month before Black Friday.

From a customer traffic perspective, the system was considered ready.

What hadn't been tested — at least not deeply enough — was integration behavior under real customer-driven change.

And now it was live traffic.

Product attributes were changing constantly. Prices were being updated. Content adjustments were rolling in.

At the same time, data was flowing from every direction:

PIM
ERP
OMS
Commerce systems
Cloud infrastructure
External search engines
Product feeds

Eighteen websites. Dozens of dependent systems. All expected to stay in exactly the same state.

In this architecture, one system was responsible for keeping everything consistent.

And that system lived inside the eCommerce platform.

On normal days, this platform processed 250+ million events coming from external systems. During Black Friday, that number exploded.

One attribute change could trigger updates across 1.5 million products:

Storefront
PLP / PDP
Search
Feeds
External discovery platforms

When the full update cycle took 4 hours and 27 minutes, it wasn't "just latency."

It meant:

Prices appearing late
Products missing from search
Feeds out of sync
Customers seeing different realities across channels

With traffic peaks of 75,000 users per minute, even a 1% inconsistency scaled into millions in lost revenue across the ecosystem.

At that moment, this stopped being a performance problem.

It became a systemic risk.

What Was on the Line — Personally

I wasn't the person who originally designed this system.

But I was part of the core team as a Technical Architect — which meant that when things started to bend under pressure, I was expected to deliver a solution within hours or days, not weeks.

I always feel accountable, even when I'm technically not.

Because that's the responsibility of a good Solution Architect:

Notice problems before others see them
Explain why they will fail
Show how to fix them
Clearly communicate the business consequences

Even when clients don't want to hear it. Even when managers think it's too risky to change. Even when owners prefer short-term stability over structural fixes.

You still have to say it.

Because if you see the failure coming and stay silent — the outcome is worse.

The Architectural Mistake That Made This Inevitable

There were many issues. But one mistake stood above all others:

The eCommerce platform was acting as an integration bridge between enterprise systems.

That decision is often ignored — especially because it works at first.

For small systems. For medium complexity. For early growth stages.

But at enterprise scale? It creates a dangerous situation:

Every external change puts pressure on eCommerce
Every sync increases coupling
Every retry amplifies load
Every small update becomes a system-wide event

The platform designed to serve customers becomes responsible for orchestrating the enterprise.

And under peak load, that responsibility becomes unbearable.

The Fix — And the Real Lesson

We redesigned how updates were handled.

Removed unnecessary fan-out
Changed how feeds were indexed
Stopped treating all updates as equal
Reduced full queue processing from 4+ hours to 26 minutes

But the deeper fix wasn't technical. It was architectural.

The Rule I Follow Since That Night

Since that Black Friday, I never design eCommerce systems that act as integration bridges in an enterprise.

Even if it works today. Even if it's cheaper now. Even if it feels simpler.

Because slow sync doesn't just delay data — it silently erodes revenue, trust, and stability.

Final Thought

Black Friday didn't change how I design systems.

It confirmed what enterprise scale demands:

Clear ownership boundaries
Decoupled integrations
eCommerce focused on serving customers — not coordinating the enterprise

The cost of learning this lesson late is far higher than the cost of designing it right from the start.

I write about integration architecture, production failures, and patterns that actually hold up at scale → integration-maestro.com