DEV Community: Peter

UCP v2026-08-25 Breaks Quietly: 4 Changes That Still Pass Validation

Peter — Sat, 29 Aug 2026 12:58:57 +0000

On August 25, 2026, the Universal Commerce Protocol shipped v2026-08-25. It is the first
new spec version in four and a half months, and it is a big one: a multi-vertical refactor
laying groundwork for Food and Lodging, grocery and location capabilities, 3D Secure via a
new Actions primitive, split payments and installment terms, a loyalty extension, and Web
Bot Auth interop.

The release notes carry a clearly labelled "Breaking Changes" section. Good.

The problem is that the most dangerous changes in it are not the ones that break loudly.
They are the ones where your profile still parses, still validates against a naive checker,
and agents quietly stop working.

I know, because our own validator got this exactly wrong. More on that below.

Why this release breaks quietly

Look at source/schemas/profile.json at tag v2026-08-25. The base definition ends like this:

{
  "type": "object",
  "required": ["ucp"],
  "properties": {
    "ucp": { "$ref": "ucp.json#/$defs/base" },
    "keys": {
      "type": "array",
      "items": { "$ref": "#/$defs/jwk_public_key" }
    }
  },
  "additionalProperties": true
}

Two things matter here.

required is ["ucp"] and nothing else. And additionalProperties is true.

That combination means a profile carrying removed fields is not invalid. It parses. It
validates. It just contains members that nothing reads any more. When a spec renames a field
under additionalProperties: true, the old name does not become an error. It becomes
decoration.

That is the failure mode to hunt for in this release. Not "my profile is rejected" but "my
profile is accepted and ignored".

Silent breaker 1: `signing_keys` became `keys`

This is the big one, and it is the cleanest example of the pattern.

Before v2026-08-25, a profile published its signing keys in a root-level signing_keys
array. As of this release, signing_keys is gone from profile.json entirely and keys
is the sole canonical field. The schema is blunt about it:

When a profile publishes signing keys, they MUST appear here; this is where every UCP
verifier reads them.

So:

// Before - v2026-04-08
{
  "ucp": { "version": "2026-04-08", "...": "..." },
  "signing_keys": [
    { "kty": "EC", "kid": "key-1", "crv": "P-256", "x": "...", "y": "..." }
  ]
}

// After - v2026-08-25
{
  "ucp": { "version": "2026-08-25", "...": "..." },
  "keys": [
    { "kty": "EC", "kid": "key-1", "crv": "P-256", "x": "...", "y": "..." }
  ]
}

The array contents do not change. It is the same JWK Set under a different name.

Now put that next to additionalProperties: true. If you bump your version to
2026-08-25 and leave signing_keys where it is, your profile is still schema-valid.
Nothing rejects it. But no verifier looks at signing_keys any more, so signature
verification fails against a profile in which nothing looks wrong. You will be debugging
your signing code, not your field names.

The fix is a rename. The hard part is knowing you need it.

We got this wrong in the opposite direction

Worth being straight about this, because it is the same trap from the other side.

Our validator hard-required signing_keys and had no concept of keys at all. So when the
spec moved, we started emitting a hard error on profiles that were correctly migrated. A
merchant who did the right thing got told their profile was broken.

It got worse. Our pipeline skips rules and network validation whenever structural validation
reports an error. So the bogus error did not just add noise, it suppressed every real check
behind it. One false error, and no actual analysis.

We shipped the fix on August 29. Both spellings are now accepted, keys is treated as
canonical from 2026-08-25, and a leftover signing_keys on a new-version profile raises a
warning that tells you it will be ignored rather than an error claiming it is invalid.

The lesson generalises past our bug: a validator that hard-codes a field name is a
validator that will eventually fail correct input. If you have written any internal UCP
checking, go look at how it resolves keys today.

Silent breaker 2: fulfillment config lost its `allows_` prefix and changed shape

The file was renamed from merchant_fulfillment_config.json to
business_fulfillment_config.json, and two properties were renamed. But this is not just a
rename, and that is what makes it dangerous. multi_destination also changed type.

// Before - v2026-04-08: a map of method -> boolean
"allows_multi_destination": {
  "shipping": true,
  "pickup": false
}

// After - v2026-08-25: an array of objects, listing = permitting
"multi_destination": [
  { "method": "shipping" }
]

Now trace what happens if you skip this migration. The old schema set
additionalProperties: false, so a stray key there used to be a hard error. The new
business_fulfillment_config does not, so allows_multi_destination is now simply an
unrecognised member that nothing reads. And the new field's own rule is explicit:

Listing a method permits it; an omitted method does not.

So your untouched config does not fail. It resolves to an empty permission set. You silently
stop allowing split shipping across addresses, and nothing anywhere says so. That is a
capability you believe you advertise quietly turning off.

method_combinations kept its array-of-arrays shape, but its enum restriction to
["shipping", "pickup"] was removed in favour of an open vocabulary with those as
well-known values. That one is a loosening, so it will not break you.

While you are in these files: fulfillment_option.description was upgraded from a flat
string to a structured object (it now $refs common/types/description.json). That one
does change type on a required-ish field, so it is more likely to fail loudly, which
honestly makes it the safer of the two.

Silent breaker 3: buyer consent went from booleans to a reverse-DNS map

This one changes shape rather than just names.

// Before - v2026-04-08: four fixed booleans
"consent": {
  "analytics": true,
  "marketing": false,
  "preferences": true,
  "sale_of_data": false
}

In v2026-08-25, consent is a dynamic map keyed by reverse-DNS identifiers, where each
purpose is an object requiring granted, source, and description:

// After - v2026-08-25
"consent": {
  "dev.ucp.consent.marketing": {
    "granted": false,
    "source": "platform",
    "description": "Promotional communications across all channels",
    "segments": {
      "dev.ucp.consent.marketing.email": {
        "granted": true,
        "source": "platform",
        "description": "Email marketing only"
      }
    }
  }
}

The source field is the interesting addition: it distinguishes a business default
("business") from an explicit buyer decision captured by the platform ("platform"). If
you are handling consent for compliance reasons, that distinction is probably one you have
been reconstructing by hand. Now it is in the protocol. Segments let you scope a decision to
a channel without inventing your own convention, and UCP predefines
dev.ucp.consent.marketing.email and .sms.

Silent breaker 4: payment extensions moved namespace

Payment extensions migrated out of the shopping vertical:

dev.ucp.shopping.split_payments becomes dev.ucp.common.payment.split_payments
the same move applies to payment_terms and ap2_mandates

Related, and easy to miss: shared primitive schemas (amount.json, price.json,
line_item.json) moved under common/types/, which changes their $id URLs. If you
pin, cache, or fetch those schemas by URL anywhere, those references are now stale.

This is the change most likely to bite tooling rather than merchants. Anything that walks
capability extension chains by prefix will read migrated extensions as orphaned.

The migration checklist

Rename signing_keys to keys at the profile root. Delete the old key. Do not keep both - two sources of truth for signing keys drifting apart is precisely the failure this change was made to eliminate.
Move to business_fulfillment_config.json, drop the allows_ prefix, and convert multi_destination from a method-keyed boolean map to an array of { "method": "..." } objects. Do not just rename it - an unconverted map reads as "nothing permitted".
Convert fulfillment_option.description from a flat string to the structured common/types/description.json object.
Restructure buyer consent into the reverse-DNS map with granted / source / description.
Repoint payment extensions to dev.ucp.common.payment.*.
Update any pinned $id URLs for amount, price, and line_item to common/types/.
Bump version to 2026-08-25 last, after the above. The version field is the part agents read to decide how to interpret everything else.

Then re-validate. And validate with something that actually knows about 2026-08-25 - a
checker still targeting an older version will happily tell you a half-migrated profile is
fine.

The broader point

Date-based protocol versions make it easy to think of a spec bump as a number you increment.
This release is a good argument against that. The changes that will cost you time are not in
the "Breaking Changes" heading you read once. They are in the gap between "my JSON is valid"
and "an agent can actually transact with me", and additionalProperties: true is exactly
where that gap lives.

If you maintain UCP tooling, the practical takeaway is narrower: stop hard-coding field
names, and make your validator report which layout it detected rather than silently
assuming one.

UCP is an open standard co-developed by Google and Shopify. UCPtools is an independent
community tool and is not affiliated with either company. Every schema detail above was read
from the published specification at tag v2026-08-25 in the
Universal-Commerce-Protocol/ucp
repository, not from the release notes.

You can check a profile against v2026-08-25 with the free validator at
ucptools.dev, or run it in CI with the
UCP validate GitHub Action.

Is Your UCP Validator Lying to You About Cart and Catalog?

Peter — Wed, 29 Jul 2026 10:06:16 +0000

Is Your UCP Validator Lying to You About Cart and Catalog?

You ran validation. Your store got a "FAIL" on Cart and Catalog capabilities. The report says your catalog endpoint returns an invalid response shape. You spend an afternoon debugging endpoints that look fine when you test them manually.

The problem isn't your store. It's your validator. Here's why.

The draft-spec trap nobody talks about

The Universal Commerce Protocol isn't static. As of the April 2026 release:

Identity Linking is stable. The spec is finalized. Agents expect a specific response shape, and that shape won't change without a new protocol version.
Cart and Catalog are draft. The endpoints exist and work. Agents interact with them in production. But the schema, response shapes, and exact field names are still evolving. The spec explicitly says they "MAY version independently when breaking changes are required."

When a validator doesn't distinguish between stable and draft capabilities, here's what happens:

Your Catalog endpoint returns products correctly. An AI agent asks "show me hiking boots under $200" and your store responds with actual products. But the response includes an optional metadata field that the draft spec didn't mention six months ago, or it nests variant data differently than the current draft expects.

A spec-unaware validator flags this mismatch as a failure. Hard stop. Red X. "Catalog validation failed."

The agent, meanwhile, browses your catalog just fine. It reads the products that matter, ignores the extra fields, and builds a cart. Your store works in practice. But your validator says it doesn't.

What a hard-fail actually costs you

False negatives aren't just annoying - they steer you toward the wrong work.

When your validator says Cart validation failed, you investigate. You compare your endpoint response to the draft schema. You spend hours figuring out whether the mismatch is on your side or the spec's. You might even modify your endpoint to match a draft schema that changes next month.

Meanwhile, the actual problems - signing keys that rotated, a CDN that changed how it serves .well-known/ucp, payment handlers referencing an old gateway endpoint - go unnoticed. These are genuine, production-breaking failures that get buried under draft-spec noise.

The validator that flags everything with equal severity trains you to ignore all of it.

The fix: draft-aware validation

As of July 2026, UCPtools handles draft capabilities differently:

Stable spec requirements: checked as before. If your Cart endpoint returns a 4xx, if your Catalog doesn't serve JSON, if a required stable-spec field is missing - those are real failures.
Draft-spec mismatches: produce warnings, not failures. If your response shape doesn't match the current draft schema, you get a clear warning explaining what's different - not a red X that blocks everything else.

You still see the mismatch. You still know something changed. But you're not punished for a moving target.

Three things to check in your current validation workflow

1. Does your tool report spec status for each capability?

If every failure looks the same - same severity, same color, same urgency - you can't tell a broken endpoint from a draft-spec evolution.

2. Does a Cart/Catalog failure block your entire validation run?

A genuine signing_keys failure and a draft-spec Catalog warning are not the same problem. If your tool treats them identically, you're spending time on the wrong one.

3. When was your tool last updated against the current UCP spec?

The April 2026 update was the largest spec release since January. If your validator hasn't been updated since then, it's validating against a version of the protocol that no longer reflects what agents expect.

The spec is moving. Your validation should move with it.

Google shipped the April 2026 update with Cart, Catalog, and Signals. Shopify Editions Spring '26 made UCP the default on every store. The protocol is in active development - and that's a good thing. It means agentic commerce is real enough that the spec keeps improving.

But point-in-time validation tools that don't distinguish between draft and stable create more noise than signal. You end up debugging spec evolution instead of fixing what actually breaks agent interactions.

Check if your validation handles draft specs correctly: Validate your UCP profile - free, no account needed.

Running validation across multiple domains? Start a free 7-day trial for monitoring and multi-domain dashboards. No credit card required.

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

Peter — Mon, 20 Jul 2026 10:05:06 +0000

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

OpenAI shipped the Agentic Commerce Protocol (ACP) and ChatGPT's shopping agent is live. Target, Sephora, Nordstrom, Best Buy, and Home Depot are already integrated. When a user asks ChatGPT to find them a product, those stores show up.

If your store isn't ACP-visible, ChatGPT users can't find you. Period.

Here's the thing most e-commerce developers don't realize: your store might already be ACP-compatible and you just haven't checked. If you're on Shopify with Stripe, HTTPS, and proper policy pages, you could be one product feed away from ChatGPT discoverability.

What ACP Actually Checks

ACP is the open standard (Apache 2.0) that OpenAI and Stripe built for AI commerce. It's not proprietary and it's not Stripe-only - Adyen shipped "Adyen Agentic" and PayPal announced ACP support for 2026.

The protocol checks four things on your store:

Platform (25 pts) - Shopify/Etsy auto-eligible path, or custom integration needed
Payment infrastructure (30 pts) - Stripe is the easiest path (Shared Payment Token), but seller-backed instruments (gift cards, store credit) also work
Policy pages (25 pts) - Terms, privacy, and return policy are required by spec. Agents need these.
Security (20 pts) - HTTPS with modern TLS. Hard requirement.

You get a 0-100 score with letter grades (A through F) and finding codes for every failure - not "you failed," but exactly what to fix.

ACP vs UCP: Don't Confuse Them

Two protocols, two AI agent ecosystems:

Protocol	ACP (OpenAI + Stripe)	UCP (Google + Shopify)
Primary agents	ChatGPT	Google AI Mode, Gemini, Copilot
Discovery	`/.well-known/acp.json` + product feed	`/.well-known/ucp` manifest
Checkout	Stripe delegated tokens or merchant app	Merchant-hosted endpoints
Focus	Payment + discovery	Full commerce (browse, cart, checkout)

Microsoft Copilot already consumes both. checkout.com data shows dual-protocol stores capture 40% more agentic traffic. The recommendation for 2026: implement both if you can. But start by checking what you already have.

The March 2026 Pivot (And Why ACP Matters More, Not Less)

OpenAI deprioritized in-ChatGPT checkout in March 2026. Users browsed but didn't buy in-chat. Purchases moved to merchant storefronts.

But here's what most people missed: the ACP spec had its biggest release after that pivot. April 17, 2026 brought public product feeds, Cart capability, delegate authentication with 3DS2, and mandatory idempotency keys.

The takeaway: ACP now governs discovery inside ChatGPT. If your products aren't ACP-surfaced, ChatGPT users never see them. The purchase completes on your site, but the discovery happens inside the agent. And discovery requires ACP readiness.

The Numbers

McKinsey: up to $1T in US agentic commerce by 2030
Morgan Stanley: 126M AI shopping-agent users by 2030
Shopify: 13x YoY growth in AI search orders

The retailers showing up today didn't wait. They integrated early. Every week your store isn't checked is a week ChatGPT users buy from someone else.

Test It in 30 Seconds

I built a free ACP Readiness Checker that scans your domain and gives you a 0-100 score across all four categories. No account required.

Run the ACP check on your store →

If you score A, you're ChatGPT-ready. If not, you get specific finding codes and fix recommendations for every failing category.

Your products should show up wherever customers shop. In 2026, that includes ChatGPT.

Also published on ucptools.dev

Run UCP + ACP Validation in Your CI/CD Pipeline

Peter — Fri, 10 Jul 2026 05:26:39 +0000

You deploy a change to your storefront. The JSON still parses. The linter is happy. Tests pass.

Two weeks later you notice AI agents have been silently skipping your store, because a capability schema endpoint started returning a 404 and nothing anywhere told you.

This is the failure mode of agentic commerce readiness: it degrades quietly. There is no 500 page, no error rate spike, no angry customer email. Agents just move on to a merchant whose profile resolves.

The fix is the same as for every other class of quality problem in software. Stop checking it by hand. Put it in CI.

What actually breaks

UCP profiles are not simple documents. They carry namespace bindings, HTTPS requirements, signing keys, and extension chains that reference capabilities elsewhere in the file. A profile can be perfectly valid JSON and still be broken in ways that matter:

UCP_NS_ORIGIN_MISMATCH - your declared namespace does not match the origin serving it
UCP_ENDPOINT_NOT_HTTPS - agents require HTTPS, without exception
UCP_MISSING_SIGNING_KEYS - required before order and fulfillment capabilities will be trusted
UCP_SCHEMA_FETCH_FAILED - a capability schema URL returns an error
UCP_ORPHANED_EXTENSION - an extension points at a capability that no longer exists

Every one of these survives JSON.parse(). Every one of these makes you invisible to some agent. And the last two are exactly the kind of thing a refactor breaks without touching the profile file at all, because the breakage lives at the other end of a URL.

That is the argument for CI. Not "validate once at launch" - validate on every push, against the environment you are about to ship.

The GitHub Action

If you are on GitHub, this is four lines of YAML:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'yourstore.com'
    fail-on-grade: 'C'

The action runs four-level validation (structural, rules, network, SDK compliance) against the live domain and scores AI readiness. fail-on-grade fails the build at that grade or worse; fail-on-score does the same against a 0-100 number. Use whichever matches how your team talks about quality.

It exposes score, grade, ucp-found, passed, and result-json as outputs, so you can branch on the result rather than just pass or fail:

- uses: Nolpak14/ucp-validate-action@v1
  id: ucp
  with:
    domain: 'yourstore.com'

- run: echo "UCP score: ${{ steps.ucp.outputs.score }}"

- if: steps.ucp.outputs.ucp-found == 'false'
  run: echo "::warning::No UCP profile at /.well-known/ucp"

On pull requests it posts a comment with the score, a category breakdown, and any validation issues with their error codes, updating in place rather than piling up duplicates. Set comment: 'false' if you would rather have step summaries only.

The pattern that actually pays: gate the deploy

Validating on push is useful. Gating the deploy on it is what stops a broken profile reaching production:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  validate-ucp:
    runs-on: ubuntu-latest
    steps:
      - uses: Nolpak14/ucp-validate-action@v1
        with:
          domain: 'staging.yourstore.com'
          fail-on-grade: 'C'

  deploy:
    needs: validate-ucp   # deploy only runs if validation passed
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production..."

Point it at staging. If staging's profile does not clear your bar, the deploy job never runs. You catch the regression before customers see it, and before agents quietly reroute around you.

Not on GitHub? Use the CLI

The validator ships as an npm package, so it drops into any runner with Node.js 20+. It exits non-zero when validation fails, which is all a CI system needs.

GitLab CI:

ucp-validation:
  image: node:20-alpine
  script:
    - npx -p @ucptools/validator ucp-validate validate --remote yourstore.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

CircleCI:

jobs:
  ucp-validation:
    docker:
      - image: cimg/node:20.11
    steps:
      - run:
          name: Validate UCP profile
          command: npx -p @ucptools/validator ucp-validate validate --remote yourstore.com

Or wire it into your test suite so it runs wherever your tests already run - Jenkins, Bitbucket Pipelines, a Makefile, a pre-commit hook:

npm install --save-dev @ucptools/validator

{
  "scripts": {
    "test:ucp": "ucp-validate validate --remote yourstore.com"
  }
}

You can also validate the file before it ever ships, which is faster and catches structural errors without a network round trip:

npx -p @ucptools/validator ucp-validate validate --file ./public/.well-known/ucp

The other protocol: ACP readiness

UCP is not the only spec agents care about. The Agentic Commerce Protocol - OpenAI and Stripe's standard, the one behind checkout inside ChatGPT - has its own readiness surface: platform detection, payment integration, policy endpoints, security posture.

Worth being precise about how this runs, because it is different: the GitHub Action and the CLI check UCP. ACP readiness is a public REST endpoint. No key, no install, so it works in any CI that has curl and jq.

curl -sX POST https://ucptools.dev/api/acp-check \
  -H 'Content-Type: application/json' \
  -d '{"domain":"yourstore.com"}' > acp.json

SCORE=$(jq -r '.score' acp.json)
GRADE=$(jq -r '.grade' acp.json)
echo "ACP readiness: $GRADE ($SCORE/100)"

[ "$SCORE" -ge 70 ] || {
  jq -r '.recommendations[]? | "[\(.priority)] \(.title) - \(.action)"' acp.json
  exit 1
}

One trap worth knowing: the endpoint answers 200 OK even when a domain fails, with "ok": false in the body. A reflexive curl --fail gate would pass every grade, including an F. Read .score or .grade from the response, not the HTTP status.

The response also carries score_breakdown across platform, payment, policies, and security, plus recommendations as structured objects with priority, title, description, and action - which is why the snippet above prints something a developer can act on rather than a wall of JSON.

Where to set the bar

Resist the urge to start at fail-on-grade: 'A'. You will spend a week fighting your own pipeline and then disable the check, which is worse than never adding it.

Start where you are. Run the validator once, take the grade it gives you, and set the threshold one notch below. Now the build fails only on regression, which is the thing you actually care about. Ratchet the bar upward as you fix the backlog. A gate that fires on real regressions and stays quiet otherwise is a gate people keep.

For ACP, 70 is a reasonable opening threshold. For UCP, fail-on-grade: 'C' catches the profile-level breakage without blocking on Schema.org polish.

Getting started

Add the action, or the npx one-liner, to a workflow you already run
Point it at staging, not production
Set a threshold one notch below your current grade
Add the ACP curl step if you care about ChatGPT checkout
Make the deploy job needs: the validation job

Copy-paste recipes for GitHub Actions, GitLab CI, CircleCI, npx, and the ACP endpoint live at ucptools.dev/ci. If you would rather call validation from your own code than from a CI step, the API and npm reference covers the public REST endpoints and the typed package.

The point is not the score. The point is that a profile which silently stopped resolving should break your build, not your revenue.

UCPtools is an independent community tool. UCP is an open standard by Google and Shopify; ACP is an open standard by OpenAI and Stripe. We are not affiliated with any of them.

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

Peter — Mon, 06 Jul 2026 10:07:25 +0000

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

Three infrastructure changes in the last 30 days turned agentic commerce from a spec to a live channel:

Mastercard backed UCP. Their Agent Pay network now runs on Google's Universal Commerce Protocol. The payment layer converged on the discovery layer.
Shopify shipped Agentic Storefronts in Summer '26 Editions. Every Shopify merchant now has an AI shopping channel, active by default, manageable from the admin.
Google AI Mode is in production. Gemini browses stores via UCP. ChatGPT shops through Shopify's agentic storefronts.

The stack is live: Discovery (Google AI Mode, Gemini, ChatGPT) + Storefront (Shopify, BigCommerce) + Payment (Mastercard Agent Pay, Visa Intelligent Commerce, Adyen Agentic).

If your store doesn't have a valid UCP profile, you are invisible to every layer. Not "less visible." Invisible. The agents read protocols, not websites.

Here's the 5-item checklist to fix that. Each step takes 10-30 minutes.

1. Validate at All 4 Levels

A structural JSON check tells you the manifest parses. It doesn't tell you whether an AI agent can actually shop.

You need all four:

Structural - valid JSON, required fields, schema compliance
Rules - capability consistency, namespace/origin match, business logic
Network - HTTPS on all endpoints, live response codes, reachability
SDK/Simulation - end-to-end agent interaction (browse, cart, checkout, pay)

Most free checkers stop at Level 1. The failures that make your store invisible live at Levels 3 and 4.

Run a free 4-level validation

2. Run the AI Agent Simulator

Validation says your manifest is correct. Simulation says whether an agent can actually use it.

The simulator sends real agent-style requests: browse catalog, add to cart, initiate checkout. Failures it catches that validators miss:

Payment handlers declared but unreachable (302 redirect, CORS block)
Identity Linking endpoints that return 200 but fail cross-domain
Cart where add works but remove doesn't
Signing keys present but cryptographically invalid

Run the AI agent simulator

3. Fix the Top 3 Failures

Production scan data shows three issues cause most agent-visible failures:

Missing signing_keys - Without them, agents can't verify your manifest. They walk. This is the single most common failure.

Namespace/origin mismatch - Your manifest says origin: "store.example.com" but the agent requested from www.store.example.com. The agent sees a contradiction and aborts.

Broken payment_handlers - The manifest declares checkout but doesn't tell agents what payment methods exist, or lists handlers that don't work. Cart fills, purchase fails.

4. Set Up Monitoring

Your UCP profile will break. Not because you made a mistake - because infrastructure changes:

TLS certs rotate and the new CA isn't trusted
Your platform ships an update that changes the manifest shape
Payment gateway config drifts from what the manifest declares
A caching plugin starts serving /.well-known/ucp as text/html

When this happens, you won't get an error. You'll just stop appearing in AI shopping results. Silent, invisible failure.

Monitoring re-validates on a schedule, compares to baseline, and alerts on regression. Same principle as uptime monitoring - but for AI agent discoverability.

Set up monitoring

5. Test All Three Layers

The stack works as a chain. Break any link and it fails:

Discovery - Can Google AI Mode find your store? Search your products in AI Mode.
Storefront - Is your Shopify Agentic Storefront active? Check admin under Sales Channels.
Payment - Can Mastercard Agent Pay process a payment through your store? Test the handler endpoints.

Why This Matters

Shopify reported 13x year-over-year growth in AI search orders before Agentic Storefronts shipped. Cloudflare reports bots have surpassed human traffic. McKinsey projects up to $1T in US agentic commerce by 2030.

The protocol war is effectively settled. UCP has the discovery layer, the storefront layer, and now the payment layer. Implementing it isn't a competitive advantage - it's table stakes.

Five steps. One afternoon. The difference between being visible to the agentic commerce stack and being invisible to it.

Start your free validation - no account required.

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Peter — Fri, 26 Jun 2026 15:53:12 +0000

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

The AI commerce landscape is rapidly standardizing around two open protocols: Google's Universal Commerce Protocol (UCP) and OpenAI's Agentic Commerce Protocol (ACP). By holiday 2026, Visa and Mastercard will enable all US cardholders for agent transactions, while Shopify's 4.8M merchants are discoverable via UCP and Stripe's 1.5M merchants can accept ACP payments with one line of code.

For developers building AI shopping agents, this creates a critical challenge: should you implement UCP, ACP, or both?

In this step-by-step tutorial, you'll learn how to build a dual-protocol checkout system using the Agorio SDK — the only open-source toolkit that supports both UCP and ACP with auto-detection. We'll walk through setting up a TypeScript project, discovering merchants via UCP, managing checkout sessions via ACP, and assembling a full-featured shopping agent.

Why Dual-Protocol Support Matters

UCP and ACP solve different problems:

Protocol	Lead Developers	Primary Use Case	Discovery Method	Payment Model
UCP	Google, Shopify, 25+ partners	Full commerce lifecycle (discovery, cart, checkout, order tracking)	Decentralized (`/.well-known/ucp`)	Multiple handlers (Google Pay, Shop Pay, tokenization)
ACP	OpenAI, Stripe	Checkout-focused, delegated payment	Centralized (merchant application)	Any PSP via delegated payment (Stripe first)

Merchants are adopting both. If your agent only supports one protocol, you'll miss transactions on the other. The smart solution: support both, but avoid writing twice the code.

What Agorio Provides

Agorio abstracts the protocol differences behind a unified API:

UcpClient – Discovers merchants via /.well-known/ucp, normalizes capability formats, handles REST/MCP/A2A transports.
AcpClient – Manages ACP checkout sessions (create, get, update, complete, cancel) with Bearer auth and request tracing.
ShoppingAgent – 17 built‑in tools that work across both protocols via automatic detection.
MockMerchant – A full UCP‑compliant test server, plus ACP‑only and MCP‑only variants.
LLM adapters – Gemini, Claude, OpenAI, Ollama — swap without changing your agent logic.

With Agorio, you write commerce logic once; the SDK adapts to the merchant's supported protocol.

Step 1: Project Setup

Start a new TypeScript project and install Agorio:

npm init -y
npm install typescript ts-node @types/node --save-dev
npm install @agorio/sdk

Create a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "esModuleInterop": true,
    "outDir": "./dist",
    "strict": true
  }
}

Step 2: Discover a Merchant via UCP

First, let's discover a merchant's capabilities using the UcpClient. The client automatically fetches the /.well-known/ucp manifest and normalizes the capability format.

import { UcpClient } from '@agorio/sdk';

const client = new UcpClient();

async function discoverMerchant(domain: string) {
  try {
    const result = await client.discover(domain);
    console.log(`Merchant ${domain} supports:`);
    result.capabilities.forEach(cap => {
      console.log(`  - ${cap.name} (${cap.version})`);
    });
    return result;
  } catch (error) {
    console.error(`Discovery failed:`, error);
    return null;
  }
}

// Example: discover a UCP-enabled merchant
await discoverMerchant('shop.example.com');

The result object contains normalized services, payment handlers, and transport bindings. You can now invoke any UCP capability (catalog, cart, checkout) using the client's REST or MCP transport.

Step 3: Create an ACP Checkout Session

For merchants that support ACP (like Stripe‑enabled stores), you'll manage checkout sessions via the AcpClient. ACP uses delegated payment: the user's payment method stays with their PSP (Stripe, PayPal), and the agent acts as an operator.

import { AcpClient } from '@agorio/sdk';

const acp = new AcpClient({
  baseUrl: 'https://api.stripe.com/acp/v1', // Replace with merchant's ACP endpoint
  apiKey: process.env.STRIPE_API_KEY!,
});

async function createAcpCheckout(productId: string, quantity: number) {
  const session = await acp.createCheckout({
    lineItems: [{
      productId,
      quantity,
      price: {
        amount: 2999, // $29.99 in minor units (cents)
        currency: 'USD',
      },
    }],
    merchantDomain: 'shop.example.com',
  });

  console.log(`ACP checkout session ${session.id} created`);
  console.log(`Status: ${session.status}`); // "not_ready_for_payment"
  return session;
}

const session = await createAcpCheckout('prod_123', SB_1);

The AcpClient handles all required headers (Authorization, API‑Version, Idempotency‑Key, Request‑Id) and validates responses against the ACP schema.

Step 4: Build a Dual-Protocol Shopping Agent

Now combine both clients into a single ShoppingAgent. The agent automatically detects whether a merchant speaks UCP or ACP and uses the appropriate client.

import { ShoppingAgent, GeminiAdapter } from '@agorio/sdk';

const agent = new ShoppingAgent({
  llm: new GeminiAdapter({ apiKey: process.env.GEMINI_API_KEY! }),
  verbose: true,
  // ShoppingAgent automatically instantiates UcpClient and AcpClient
});

async function runShoppingTask(task: string) {
  const result = await agent.run(task);

  console.log(result.answer);           // Natural language summary
  console.log(result.checkout?.orderId); // Order ID if purchase completed
  console.log(result.usage?.totalTokens); // LLM token usage

  return result;
}

// This single command works for both UCP and ACP merchants:
await runShoppingTask('Go to shop.example.com and buy wireless headphones');

The agent's 17 built‑in tools handle the entire flow: merchant discovery, product search, adding to cart, submitting shipping and payment, and order tracking. You can extend with custom tools via plugins.

Step 5: Test with Mock Merchants

Before hitting real merchants, test with Agorio's mock servers. MockMerchant provides a full UCP‑compliant server; MockAcpMerchant provides an ACP‑only server.

import { MockMerchant, MockAcpMerchant } from '@agorio/sdk';

// Start a UCP merchant
const ucpMerchant = new MockMerchant();
await ucpMerchant.start();
console.log(`UCP mock merchant running at ${ucpMerchant.domain}`);

// Start an ACP merchant
const acpMerchant = new MockAcpMerchant();
await acpMerchant.start();
console.log(`ACP mock merchant running at ${acpMerchant.domain}`);

// Test your agent against the mock
const result = await agent.run(`Go to ${ucpMerchant.domain} and buy a laptop`);
console.log(`Order placed:`, result.checkout?.orderId);

// Clean up
await ucpMerchant.stop();
await acpMerchant.stop();

Both mocks simulate realistic latency, support configurable error rates for chaos testing, and provide structured product catalogs (10 products by default).

Step 6: Deployment Considerations

When moving to production, keep these points in mind:

LLM cost control – Set maxIterations in AgentOptions to limit agent loops.
Observability – Use the onLog callback to stream logs to your monitoring system, or integrate with Agorio Cloud for full tracing.
Session storage – Swap MemorySessionStorage for FileSessionStorage or @agorio/session-redis in multi‑process deployments.
Idempotency – Always pass idempotencyKey on completeCheckout to prevent duplicate charges.
Compliance – If you handle EU users, enable the built‑in EU AI Act compliance export (GET /api/compliance/export).

Conclusion: Why Agorio is the Right Choice

Building dual‑protocol AI commerce agents from scratch requires deep knowledge of both UCP and ACP specs, plus months of implementation work. Agorio gives you:

Protocol agnosticism – Write once, run on UCP, ACP, or both.
Production‑ready tooling – Mock merchants, LLM adapters, observability, CLI.
Enterprise hardening – RBAC, audit logs, compliance exports, security posture.

The SDK is open‑source (MIT), has zero runtime fees, and already powers agents handling real purchases.

Get started today:

npm: npm install @agorio/sdk
GitHub: github.com/Nolpak14/agorio
Docs: agorio.dev/docs
Playground: agorio.dev/playground

If you're building AI commerce agents, join the 10+ GitHub stars and 46+ weekly npm downloaders who've chosen Agorio as their foundation. Ship your agent in 20 lines, not 20 weeks.

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

Peter — Mon, 22 Jun 2026 10:04:50 +0000

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

Three weeks ago, I noticed something strange in our referrer logs.

A user from chatgpt.com had landed on our validator page, browsed our documentation, and — crucially — triggered tool events. Not a human clicking around. An AI agent. ChatGPT had crawled our site, loaded our tool, and used it.

That was one agent. One week. A curiosity.

This week: five.

What showed up (and what they did)

The full lineup of AI agents that visited ucptools.dev in the last month:

ChatGPT (chatgpt.com) — 4 visits this week alone. Most active of the bunch. Browsed documentation pages and the free UCP validator. Triggered actual tool events — someone asked ChatGPT about UCP validation, and it came to us to answer.

Gemini (gemini.google.com) — 1 visit this week. First time we've seen Gemini in our logs. Shorter session than ChatGPT, but it hit the same pages: validator, compare page, docs.

Perplexity (perplexity.ai) — First spotted in May. Here's the wild part: every Perplexity-referred session in May resulted in a tool user. 100% conversion rate. Someone asked Perplexity "how do I validate my UCP profile?" and Perplexity sent them straight to our tool, already knowing what to do.

Claude (claude.ai) — Returned June 14 after a multi-week gap. Browsed our UCP protocol documentation and the agent simulator page. Not using tools yet — but it's building a map.

NotebookLM (notebooklm.google.com) — Newcomer. Discovered us June 7. Google's research assistant found our site and ingested content. We don't know what question triggered it, but something in our content matched a user's research query.

Trend line: 1 → 1 → 5. Not a spike. A ramp.

This isn't about SEO as you know it

If you work in developer tools or e-commerce infrastructure, you've probably spent the last 6 months hearing about UCP, ACP, AI shopping agents, and "agentic commerce readiness." The conversation has been about protocols — can an AI agent parse your UCP manifest? Can it call your payment handlers? Can it add items to a cart?

That's the protocol layer. And it matters.

But here's what the referral data shows: AI agents are indexing your entire web presence, not just your UCP endpoint.

When ChatGPT crawled our validator tool, it wasn't reading a .well-known/ucp manifest. It was reading our documentation, our compare page, our blog posts. It was building a knowledge graph of "what tool exists for checking UCP profiles" that it can retrieve when a user asks.

When Perplexity sent us a user with a 100% tool completion rate, it had already decided — before the human ever saw our site — that UCPtools was the right answer to their question.

This is a new kind of discoverability. Not search ranking. Knowledge base ranking. The question isn't "do I rank #1 for 'UCP validator'?" — it's "when an AI agent needs to answer a UCP question, does it know I exist?"

What this means for developer tools and e-commerce platforms

Five different agents found us without us doing anything to attract them. No agent-specific SEO. No structured data markup for AI crawlers. Just a website with clear, specific content about a niche protocol.

The implication: AI agents are actively hunting for authoritative sources in specialized domains. If you build something in the UCP/ACP/agentic commerce space, the agents will find you — but only if your content is in their corpus.

Three patterns we can already see:

Agents prefer documentation over marketing. Every agent that visited us hit our docs and tools. None touched our pricing page. None visited our blog homepage. They went straight for substance.
Tool usage is the strongest signal. Perplexity's 100% tool-user rate tells us the agent pre-qualified the user — it already knew our tool was the answer. The human didn't browse; they executed.
Multi-agent coverage compounds. One agent finding you is luck. Five agents finding you means your content is propagating across knowledge bases. ChatGPT, Gemini, Perplexity, Claude, and NotebookLM use different indexes and different retrieval strategies. If you're in all five, you're discoverable regardless of which agent a user chooses.

The protocol layer matters too — here's how they connect

We built UCPtools to validate UCP profiles. The core insight was: an AI shopping agent needs a valid UCP manifest to buy from your store. But the protocol layer and the knowledge layer are connected in ways that aren't obvious yet.

Consider this sequence:

A developer asks ChatGPT: "How do I set up UCP for my Shopify store?"
ChatGPT searches its knowledge base, finds our documentation (because we're in its corpus), and recommends our validator.
The developer uses the free validator, finds 3 broken endpoints, and fixes them.
Now their store is both UCP-valid (protocol layer) AND indexed by the agents that will send them customers (knowledge layer).

Without step 2, the developer might never find the validator. Without step 3, their UCP profile stays broken and AI shopping agents can't transact.

You need both. A valid UCP profile that no AI agent knows about is useless. And an AI agent that knows about your store but can't transact because your payment handlers are broken is equally useless.

How to check if AI agents can find you (and transact with you)

There's no all-in-one dashboard for this yet. But here's what you can do right now:

Check your referrer logs for these domains:

chatgpt.com / chat.openai.com
gemini.google.com
perplexity.ai
claude.ai
notebooklm.google.com

If you see any of them, AI agents are already building knowledge about your site.

Check your UCP profile — because being discoverable is pointless if agents can't transact. Our free validator runs 4 levels of checks: structural, rules, network, and an AI agent simulator that actually tests whether an agent can complete a purchase flow.

Run the free UCP validator →

Check your robots.txt. Most AI crawlers respect robots.txt. If you're blocking GPTBot, ClaudeBot, or Google-Extended, you're opting out of AI discoverability. That might be intentional — but it's worth knowing what you're blocking.

One thing I'm still figuring out

The data is real but the sample is small. Five agents, a handful of visits, one site. This isn't a research paper — it's an observation from our referrer logs that I think matters for anyone building in this space.

What I don't know yet:

How frequently agents re-crawl and refresh their knowledge
Whether agent referral traffic converts differently than organic search
Whether NotebookLM ingestion leads to downstream discoverability in other Google products

If you're seeing AI agents in your own referrer logs, I'd love to compare notes. Drop a comment — especially if you're seeing patterns I haven't mentioned.

The one thing I'm confident about: the agents are here, they're indexing, and they're already making decisions about which tools and services to recommend. The question isn't whether to care about AI discoverability. It's whether you're already invisible.

Google's Universal Cart Is Live. Here's the Checklist to Make Sure Agents Can Actually Check Out on Your Store

Peter — Sat, 13 Jun 2026 13:35:37 +0000

At Google Marketing Live on May 20, 2026, Universal Cart stopped being a demo. Google announced that shoppers can now save products across retailers and check out - with Google Pay or the retailer's own flow - directly inside Search, AI Mode, the Gemini app, and YouTube shopping ads. The launch list is not a pilot: Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants like Fenty and Steve Madden, with Affirm and Klarna wired in for financing and hotels and food delivery slated next.

The plumbing under all of it is UCP (Universal Commerce Protocol) - the open standard that gives an AI agent a machine-readable entry point to a store at /.well-known/ucp. (Quick disclaimer: UCP is owned and maintained by Google and Shopify. UCPtools, which I work on, is an independent community tool - not affiliated with either.)

Here is the part that matters for everyone not named in that launch list: the agent decides in milliseconds whether your store can transact. There is no "almost." Either your UCP profile answers the questions the agent asks, or the agent moves on to a merchant whose profile does. No bounce shows up in your analytics. You just quietly stop existing in the one shopping surface that is about to matter most.

So this is the readiness checklist. It maps to the four things a validator actually checks, in the order an agent hits them.

Level 1: Structure - does the profile parse at all?

Before anything semantic, the profile has to be a well-formed UCP document served correctly. This is where most "it's there but it doesn't work" failures live.

[ ] /.well-known/ucp returns 200 with Content-Type: application/json - not text/html, not a redirect to a marketing page.
[ ] The root ucp object exists. Missing it is UCP_MISSING_ROOT and the agent has nothing to read.
[ ] A version field is present and formatted YYYY-MM-DD. A stray semver string trips UCP_INVALID_VERSION_FORMAT.
[ ] The JSON is valid - no trailing commas, no CDN error page wrapped around it.

Sounds trivial. It is the single most common break, because the file is served by a platform or a CDN that nobody is watching, and a caching plugin or a security challenge can turn a clean profile into an HTML error page overnight.

Level 2: Rules - is it actually UCP-compliant?

A parseable profile can still be semantically wrong in ways that make an agent distrust it. Level 2 is the UCP compliance layer.

[ ] Namespace and origin match. The namespace your capabilities declare has to bind to the origin serving the profile. A mismatch is UCP_NS_ORIGIN_MISMATCH - a classic copy-paste-from-staging bug.
[ ] Every endpoint is HTTPS, no trailing slash. UCP_ENDPOINT_NOT_HTTPS and UCP_ENDPOINT_TRAILING_SLASH are both hard stops; agents will not POST a payment intent over http:// or to a sloppy URL.
[ ] No orphaned extensions. Every extension has to chain back to a capability that declares it. A dangling one is UCP_ORPHANED_EXTENSION and signals a profile that was hand-edited and never re-validated.
[ ] Signing keys are present. UCP_MISSING_SIGNING_KEYS is the one that quietly kills checkout: without published keys, the agent cannot verify that the offer and the payment handler are really yours. It will browse and then refuse to transact.

That last one is the difference between showing up in Universal Cart's discovery layer and actually completing a purchase in it. Discovery without signing keys gets you window-shopped, not bought.

Level 3: Network - do your references actually resolve?

Your profile points outward - to capability schemas and handler endpoints. Level 3 fetches them, the way an agent would, from outside your network.

[ ] Every referenced capability schema is reachable and self-describing. A schema host that 404s or times out is UCP_SCHEMA_FETCH_FAILED, and it is someone else's outage becoming your broken profile.
[ ] Handler endpoints respond from the public internet, not just from inside your VPC. A check that runs on your own infra can hit a warm cache and report healthy while real agents get a connection error.
[ ] TLS is valid across every edge, not just your origin. Certs renew and propagate unevenly; one stale CDN edge is enough to fail the agent that lands on it.

You cannot fully test Level 3 from a unit test, because the failures are environmental and external. This is the level that needs to be checked against your live domain, from outside.

Level 4: SDK - does it pass the official compliance pass?

The top level runs your profile through @ucp-js/sdk, the official UCP compliance kit. This is the closest a check gets to "would Google's own agent accept this?" - the same library the ecosystem builds against, applied to your live profile. Passing Levels 1 through 3 and failing here usually means a subtle shape mismatch the schema rules did not catch. If you only automate one gate, make it this one, because it is the one that tracks the spec as it evolves.

Run the whole checklist in one call

You do not have to eyeball any of this. UCPtools exposes a remote endpoint that fetches your live profile and runs all four levels server-side, the way an agent sees it:

curl -sS -X POST https://ucptools.dev/v1/profiles/validate-remote \
  -H "Content-Type: application/json" \
  -d '{"domain":"mystore.com"}' | jq

{
  "ok": false,
  "profile_url": "https://mystore.com/.well-known/ucp",
  "score": 72,
  "grade": "C",
  "issues": [
    { "severity": "error", "code": "UCP_MISSING_SIGNING_KEYS",
      "path": "$.ucp", "message": "No signing keys published",
      "hint": "Publish your Ed25519/ES256 public keys so agents can verify offers." }
  ],
  "validated_at": "2026-06-13T10:00:00Z"
}

Wire that same check into CI with the ucp-validate-action so a regression fails the build before it ships:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'mystore.com'
    min-score: 90

Where each stack tends to break

The checklist is platform-agnostic - it reads the open standard, not platform internals - but the failure that actually bites you tends to cluster by stack:

Shopify: you are largely along for the ride on what the platform serves at the well-known path, which is good until a platform change shifts the manifest shape under you. Validate after every theme or app change, because you do not control that surface directly.
WooCommerce: the usual culprit is a caching or security plugin that starts serving /.well-known/ucp from cache, behind a challenge, or as text/html. That is a Level 1 break (Content-Type) hiding behind a green admin dashboard.
BigCommerce / headless: a frontend deploy moves a handler endpoint the profile still advertises, and Level 3 starts failing while the storefront looks perfect to a human. Storefront-scope mismatches show up here too.
Custom / self-hosted: signing-key drift. The key rotates in your infra but not in the published profile, and UCP_MISSING_SIGNING_KEYS or a verification failure silently downgrades you from "can transact" to "can only be browsed."

In every case the break is invisible to a human visitor and only shows up when something fetches the live profile from outside and runs the checks. That is the entire argument for validating continuously instead of once.

The thing the launch list quietly proves

The brands Google named did not get into Universal Cart by accident. Someone on each of those teams treated the UCP profile as production infrastructure - versioned, validated, and monitored - not as a one-time SEO chore. That is the whole gap. The standard is open and the endpoint is a static file; nothing stops a mid-sized Shopify or WooCommerce store from being exactly as agent-ready as Nike. What stops most of them is that nobody ever validated past "the file exists."

Universal Cart going live is the forcing function. Agents are transacting now, in surfaces real shoppers already use every day. Run the checklist against your store - validate it free at ucptools.dev - and if it passes, set up monitoring so it stays passing at 3am when a cert renews and no one shipped a thing. The merchants who win this transition treat their UCP profile like uptime, because for agentic checkout, that is exactly what it is.

UCP is an open standard by Google and Shopify. UCPtools is an independent community tool.
Built by Peter at UCPtools.

UCP vs ACP: The Battle of AI Commerce Protocols and How to Build for Both

Peter — Thu, 11 Jun 2026 18:49:04 +0000

The AI commerce agent landscape exploded in early 2026 when both Google's Universal Commerce Protocol (UCP) and OpenAI's Agentic Commerce Protocol (ACP) launched within weeks of each other. If you're building an AI shopping agent, you now face a critical choice: which protocol should you implement? Or should you support both?

In this deep-dive, we'll compare UCP and ACP from an implementer's perspective, examine their architectural trade-offs, and show you how to get started with Agorio - the only open-source SDK that implements both with automatic detection.

The Rise of Agentic Commerce

AI agents that can shop on your behalf are no longer science fiction. With 4.8M Shopify merchants discoverable via UCP and 1.5M Stripe merchants ready for ACP, the infrastructure for autonomous commerce is already in place. Visa and Mastercard are enabling all US cardholders for agent transactions by holiday 2026.

But to tap into this ecosystem, your agent needs to speak the right protocol. Let's look at the two contenders.

UCP: Google & Shopify's Decentralized Approach

The Universal Commerce Protocol is an open standard co-developed by Google, Shopify, Etsy, Wayfair, Target, Walmart and endorsed by Stripe, PayPal, Visa, Mastercard.

Key Architecture

Discovery: Merchants publish a JSON manifest at /.well-known/ucp that tells agents what they support - capabilities, endpoints, payment handlers.
Capabilities: Modular capabilities like dev.ucp.shopping.checkout (cart, tax, session handling), dev.ucp.shopping.order (post-purchase), and extensions for fulfillment, discounts, buyer consent.
Payment Architecture: The "trust triangle" separates business, payment credential provider, and platform. Multiple handler types: Google Pay, Shop Pay, Direct Tokenization, AP2 (autonomous agent mandates).
Transport Bindings: REST (OpenAPI), MCP (OpenRPC for LLM tools), and Agent Card (A2A).

// Example .well-known/ucp manifest
{
  "ucpVersion": "2026-01-11",
  "capabilities": [
    {
      "name": "dev.ucp.shopping.checkout",
      "version": "2026-01-11",
      "restEndpoint": "https://api.example.com/ucp/checkout",
      "paymentHandlers": ["google_pay"]
    }
  ]
}

When to Choose UCP

You need decentralized discovery (any merchant can self-host)
Your agents need rich shopping workflows (cart, catalog, order tracking)
You're building for Google's AI Mode or Gemini
You need multiple payment handler types

ACP: OpenAI & Stripe's Delegated Payment Model

The Agentic Commerce Protocol is an open standard (Apache 2.0) by OpenAI and Stripe, primarily powering ChatGPT Instant Checkout.

Key Architecture

Discovery: Centralized - merchants apply at chatgpt.com/merchants and provide product feeds
Payment Model: Delegated payment - any PSP can implement the spec (Stripe first, PayPal second)
Endpoints: 5 REST endpoints for the full checkout lifecycle: create, get, update, complete, cancel
States: not_ready_for_payment → ready_for_payment → completed (with optional authentication steps)

// Example ACP checkout session flow
POST /checkout_sessions
{
  "line_items": [
    {
      "product_id": "prod_123",
      "amount": 2999, // $29.99 in cents
      "quantity": 1
    }
  ],
  "return_url": "https://example.com/return",
  "success_url": "https://example.com/success"
}

When to Choose ACP

You're building for ChatGPT or other OpenAI-agent ecosystems
You prefer a centralized, vetted merchant pool
Your transactions are single-item purchases (current limitation)
You want delegated payment through any PSP

Head-to-Head Comparison

Feature	UCP	ACP
Developers	Google, Shopify, 25+ partners	OpenAI, Stripe
Discovery	Decentralized (`/.well-known/ucp`)	Centralized (merchant application)
Payment	Multiple handlers (Google Pay, Shop Pay, etc.)	Delegated via any PSP
Extensibility	Namespace-based extensions	RFC-based extensions
Transport	REST, MCP, A2A	REST only
Merchant Footprint	4.8M Shopify merchants + any self-hosted	1.5M Stripe merchants + 35M PayPal (coming)
License	Open spec	Apache 2.0
Current Limitations	Complex capability negotiation	US-only, single-item only

Why Choose? Build Both with Agorio

The reality is that most serious commerce agents will need to support both protocols to reach the maximum number of merchants. That's where Agorio comes in.

Agorio is an open-source TypeScript SDK that implements both UCP and ACP with automatic protocol detection. Here's how you can use it:

Example: UCP Client

import { UcpClient } from '@agorio/sdk';

// Discover merchant capabilities
const ucp = new UcpClient('https://api.example.com');
const profile = await ucp.discover();

// Check if they support checkout
if (profile.supportsCheckout()) {
  const session = await ucp.createCheckoutSession({
    cartId: 'cart_123',
    paymentHandler: 'google_pay'
  });
}

Example: ACP Client

import { AcpClient } from '@agorio/sdk';

const acp = new AcpClient({
  apiKey: 'your_stripe_key',
  merchantId: 'merch_123'
});

const session = await acp.createCheckoutSession({
  lineItems: [{ productId: 'prod_123', amount: 2999, quantity: 1 }]
});

The ShoppingAgent: Auto-Detection Magic

Agorio's ShoppingAgent automatically detects which protocol a merchant supports and uses the appropriate client:

import { ShoppingAgent, GeminiAdapter } from '@agorio/sdk';

const agent = new ShoppingAgent({
  llm: new GeminiAdapter({ apiKey: process.env.GEMINI_API_KEY }),
  verbose: true,
});

// Agent automatically handles protocol detection
const result = await agent.run(
  'Go to store.example.com and buy me wireless headphones'
);

// Works with both UCP and ACP merchants
console.log(`Order placed: ${result.checkout?.orderId}`);

Implementation Complexity Analysis

Implementing UCP from scratch requires:

JSON-LD manifest parsing
Capability intersection algorithm
Payment handler abstraction
Multiple transport bindings

Implementing ACP from scratch requires:

Bearer auth with API versioning
Payment token delegation
Product feed management
Strict state machine adherence

Agorio handles all of this for you, providing:

UcpClient with discovery + REST/MCP auto-transport
AcpClient with full session lifecycle management
ShoppingAgent with 12 built-in tools for commerce workflows
MockMerchant for testing (UCP, ACP, and MCP variants)
LLM adapters for Gemini, Claude, OpenAI, Ollama

Practical Recommendations

Start with ACP if you're building for ChatGPT or want the simplest integration with Stripe/PayPal.
Start with UCP if you need decentralized discovery, multi-item carts, or Google AI Mode integration.
Use Agorio if you want to support both protocols from day one (recommended).

Remember: merchants should support both protocols for maximum AI agent coverage, and so should your agent.

Try It Yourself

The fastest way to experiment is Agorio's interactive playground:

Agorio Playground

Or install the SDK:

npm install @agorio/sdk

Check out the GitHub repository (MIT licensed) and star it if you find it useful.

The Future of Agentic Commerce

Both UCP and ACP are evolving rapidly. UCP's AP2 mandates will enable cryptographic payment authorization for autonomous agents, while ACP is expanding to multi-item purchases and international markets.

The key takeaway: protocol literacy is your moat. Understanding these standards will make you a more effective agent builder, whether you're working on a personal shopping assistant or an enterprise procurement agent.

Have you started building with UCP or ACP? Share your experiences in the comments below!

Build a UCP Watchdog: Catch the Production Breaks Your CI Never Will

Peter — Fri, 05 Jun 2026 14:50:32 +0000

You wired UCP validation into CI. Every push runs the checks, every PR gets a score, and a bad profile fails the build before it merges. Good - that is the right baseline.

Here is what it does not catch: the break that happens when nobody touches the code.

The standard here is UCP (Universal Commerce Protocol) - an open standard that gives AI shopping agents a machine-readable entry point to a store at /.well-known/ucp. (Quick disclaimer: UCP is owned and maintained by Google and Shopify. UCPtools, which I work on, is an independent community tool - not affiliated with either.)

A CI gate is triggered by your commits. But a UCP profile is a live production surface, and most of the things that break it are not commits at all:

A TLS certificate renews and propagates to your origin but not to every CDN edge.
A capability schema host your profile references goes down - someone else's outage, your broken profile.
A CDN or DNS change starts serving a cache page or a redirect at /.well-known/ucp.
Your platform (Shopify, BigCommerce, a WooCommerce plugin update) quietly changes the served manifest or strips the Content-Type: application/json header.
A signing key rotates in your infra but not in the published profile.

None of these trips a build, because there is no build. Your CI is green. Your store works fine for human browsers. The only thing that regressed is the machine-readable layer that no human ever visits - and the AI agent that hits it does not file a bug. It just leaves for the next merchant whose profile answers.

CI catches what you break on merge. A watchdog catches what breaks itself. You need both.

What a Watchdog Actually Watches

A pre-merge gate asks "is the profile I'm about to ship valid?" A watchdog asks a different question on a schedule: "is the profile that is live right now still valid, from outside, the way an agent sees it?"

Two design rules make the difference:

Check from outside your network. A check that runs inside your own infra can hit a warm cache or an internal route and report healthy while external agents get errors. Fetch your public URL over the public internet.
Compare against a baseline, not just against pass/fail. A profile can stay technically valid while its score quietly slides from A to C. Alert on regression from a known-good baseline, not only on hard failures.

Let's build it two ways: a dependency-free cron version, and a GitHub Action with Slack alerts.

The 10-Line Version: cron + curl

UCPtools exposes a public remote-validation endpoint that fetches a live domain's profile and runs the checks server-side. You can hit it from anything that runs curl and jq:

#!/usr/bin/env bash
# ucp-watch.sh - alert if the live UCP profile is broken
DOMAIN="mystore.com"

resp=$(curl -sS -X POST https://ucptools.dev/v1/profiles/validate-remote \
  -H "Content-Type: application/json" \
  -d "{\"domain\":\"$DOMAIN\"}")

ok=$(echo "$resp"     | jq -r '.ok')
errors=$(echo "$resp" | jq -r '[.issues[] | select(.severity=="error")] | length')

if [ "$ok" != "true" ] || [ "$errors" -gt 0 ]; then
  codes=$(echo "$resp" | jq -r '[.issues[] | select(.severity=="error") | .code] | join(", ")')
  curl -sS -X POST "$SLACK_WEBHOOK_URL" -H 'Content-type: application/json' \
    -d "{\"text\":\":rotating_light: UCP profile for $DOMAIN is broken: ${codes}\"}"
fi

The endpoint returns the live result, shaped like this:

{
  "ok": false,
  "profile_url": "https://mystore.com/.well-known/ucp",
  "issues": [
    { "severity": "error", "code": "UCP_SCHEMA_FETCH_FAILED",
      "path": "$.ucp.capabilities[0]", "message": "...", "hint": "..." }
  ],
  "validated_at": "2026-06-05T14:33:57Z"
}

Schedule it and you have a watchdog:

*/15 * * * * SLACK_WEBHOOK_URL=https://hooks.slack.com/... /opt/ucp-watch.sh

Now UCP_SCHEMA_FETCH_FAILED or UCP_ENDPOINT_NOT_HTTPS showing up at 3am - hours after a cert renewal, with no deploy in sight - pages you instead of silently costing you agent traffic.

The GitHub Action Version: scheduled, with a baseline

If your store already lives in GitHub, you can run the same idea on a schedule: trigger and reuse the existing ucp-validate-action - the same action people put in CI - but pointed at your live production domain and run on a clock instead of on push. The difference is entirely in the trigger and what you do with the result.

name: UCP Watchdog
on:
  schedule:
    - cron: '*/30 * * * *'   # every 30 minutes
  workflow_dispatch:          # let me run it by hand too

jobs:
  watch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - id: ucp
        uses: Nolpak14/ucp-validate-action@v1
        with:
          domain: 'mystore.com'   # your LIVE domain, not staging

      - name: Alert on regression
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
        run: |
          score="${{ steps.ucp.outputs.score }}"
          grade="${{ steps.ucp.outputs.grade }}"
          found="${{ steps.ucp.outputs.ucp-found }}"
          baseline=$(cat .ucp-baseline 2>/dev/null || echo 0)

          echo "Live: score=$score grade=$grade found=$found | baseline=$baseline"

          if [ "$found" = "false" ] || [ "$score" -lt "$baseline" ]; then
            curl -sS -X POST "$SLACK_WEBHOOK_URL" -H 'Content-type: application/json' \
              -d "{\"text\":\":rotating_light: UCP regression on mystore.com - score ${score} (grade ${grade}), baseline ${baseline}\"}"
            exit 1
          fi

Commit a one-line baseline file the first time you go green:

echo 90 > .ucp-baseline   # your known-good score

The action exposes score, grade, ucp-found, passed, and result-json, so you can build whatever alerting logic you want on top. The point is that the trigger is a clock, the target is production, and the comparison is against your last known-good state.

Alert Hygiene (so you don't train yourself to ignore it)

A watchdog that cries wolf gets muted, and a muted watchdog is worse than none. Three things keep it honest:

Baseline, don't just pass/fail. A slow slide from grade A to grade C is the regression you most want to know about, and a binary "still valid?" check will miss it entirely. Diff the score.
Debounce flaps. A single failed fetch can be a transient network blip. Require two consecutive bad checks before paging, or alert on a sustained drop rather than one data point.
Bump the baseline when you improve. When you legitimately raise your score, update .ucp-baseline in the same PR. The baseline is a ratchet - it should only move up on purpose.

Platform Notes

The watchdog is platform-agnostic - it reads the open /.well-known/ucp standard, not platform internals - but the regression that pages you tends to differ by stack:

WooCommerce: a caching or security plugin update that starts serving /.well-known/ucp from cache, behind a challenge, or as text/html.
BigCommerce / headless: a frontend deploy or app change that moves an endpoint the profile still advertises, or a storefront-scope mismatch.
Shopify: the platform changing what it serves at the well-known path out from under you.

In every case the failure is invisible until something fetches the live profile from outside and compares it to what you expect. That is the whole job of the watchdog.

CI proves the profile you wrote is correct. A watchdog proves the profile your customers' agents actually hit is still correct - at 3am, after a cert renewal, when no one shipped a thing. Both are a few lines of YAML. The merchants who win the agentic-commerce transition will treat the second one like uptime, because that is exactly what it is.

If you would rather not run your own, UCPtools does hosted monitoring with break-alerts across all four validation levels - start here. Either way: watch the live profile, not just the build.

UCP is an open standard by Google and Shopify. UCPtools is an independent community tool.
Built by Peter at UCPtools.

How AI Shopping Agents Read Your Magento Store (and 4 UCP Checks That Fail in Production)

Peter — Thu, 21 May 2026 15:52:52 +0000

If you run a Magento or Adobe Commerce store, you have probably started getting the question:

"Can ChatGPT or Google's AI find my products? Are we 'AI-ready'?"

The standard that answers it is UCP (Universal Commerce Protocol) - an open standard from Google and Shopify that gives AI shopping agents a machine-readable entry point to a store, served at /.well-known/ucp. (Quick disclaimer: UCP is owned and maintained by Google and Shopify. UCPtools, which I work on, is an independent community tool - not affiliated with either.)

Here is the catch for Magento specifically: a UCP profile that validates perfectly on your laptop can still be broken for every real AI agent in production. Magento's enterprise stack - GraphQL plus REST, Varnish full-page cache, multi-store scopes, CDN edges - breaks UCP discovery in ways a single-tenant Shopify store simply never encounters.

This post walks through the four levels of UCP validation and, for each, the Magento-specific failure mode that bites in production.

Why Magento Is a Different Animal

On Shopify, the platform owns the edge. Your UCP surface is largely handled for you and the failure modes are narrow.

On Magento/Adobe Commerce, you own the edge - and that is exactly where UCP lives:

/.well-known/ucp is a static-looking path served by a very dynamic system. Varnish, Fastly, or your CDN decides whether agents see a fresh profile or a stale one.
Two API surfaces. Magento exposes both GraphQL and REST. A UCP profile that points agents at endpoints has to point at ones that actually answer.
Multiple store views and websites. A profile bound to the wrong scope describes the wrong catalog, currency, or domain.
Self-managed TLS and CDN. Certificate renewals and cache propagation are your problem, and agents are unforgiving about both.

UCP validation is not a one-time setup step here. It is a production concern, like uptime.

Level 1: Structural - Does the Profile Parse?

The first level is the cheap one: is /.well-known/ucp valid JSON, are the required fields present, and is the version string a valid YYYY-MM-DD date?

Magento failure mode: Varnish serves HTML, not JSON. The single most common Magento issue is that the full-page cache or a misconfigured rewrite intercepts /.well-known/ucp and returns an HTML error page (or the homepage) with a 200. Structurally, an agent receives HTML where it expected JSON, and discovery dies at step one.

The fix is a cache-bypass rule for the .well-known path. If you are on Varnish, exclude it from the full-page cache so the profile is always served fresh and as application/json.

Level 2: Rules - Is the Profile Internally Consistent?

Structural validity is not compliance. Level 2 checks the UCP rules: namespace and origin binding, extension chains, HTTPS-only endpoints, and the presence of signing keys.

Magento failure mode: origin/scope mismatch. Multi-store Magento installs serve several domains and store views from one backend. It is easy to publish a profile whose declared origin does not match the host actually serving it, or whose capability endpoints point at a different store view's domain. To an agent, that is a profile that does not trust its own host - and it will not transact against it.

A close second: declaring capability endpoints over http:// or with trailing slashes that your rewrites then bounce. Agents follow the spec literally; "close enough" URLs are not close enough.

Level 3: Network - Do the Endpoints Actually Answer?

Level 3 leaves the profile behind and goes to the wire. It fetches the schemas and endpoints the profile advertises and verifies they resolve, over HTTPS, with a valid certificate chain.

Magento failure mode: the deploy that quietly breaks an endpoint. This is the one that makes UCP a recurring concern rather than a checklist item. A setup:upgrade, a module update, or a routing change can move or 500 the very endpoint your profile promised. The profile still validates structurally - it is the live endpoint that regressed.

The other classic: a certificate renewal that propagated to your origin but not to every CDN edge, so agents hitting one POP get a valid chain and agents hitting another get a handshake error. You will not see it in a browser; an agent will.

Level 4: SDK / Spec - Does It Pass Official Compliance?

The final level runs the profile against the official UCP SDK to confirm it complies with the current published spec, not just a plausible-looking shape. Specs move; a profile written against an older draft can drift out of compliance without anyone touching it.

Magento failure mode: pinned-and-forgotten. Enterprise Magento changes slowly and deliberately - which is a virtue everywhere except here. A profile authored months ago against an earlier UCP version keeps validating against its own assumptions while the spec advances around it. Level 4 is what catches that drift.

The Part Most Magento Teams Miss: Discovery Is Not Checkout

A page can be perfectly structured - Schema.org markup, FAQs, breadcrumbs - and an agent can still be unable to buy. Structured data helps agents understand your catalog. UCP is the actionable layer that lets them complete a purchase: the capabilities, endpoints, and payment handlers a profile declares.

Passing a structural "AI readiness" check means you are discoverable. Passing all four UCP levels - in production, on every CDN edge, after every deploy - means you are transactable. Those are different bars, and only the second one earns the order.

How to Check Your Store

If you want to see where your Magento store actually stands:

Run your domain through a UCP validator that does all four levels, not just a JSON parse. (UCPtools does this for free; it works on Magento, Adobe Commerce, and any other platform, since it reads the open /.well-known/ucp standard rather than platform internals.)
Pay special attention to the Network level - that is where Magento's Varnish/CDN/deploy issues surface.
Re-run it after every deploy and certificate renewal. Treat a UCP regression like a failed health check.

I wrote a deeper, Magento-specific walkthrough - including the GraphQL + REST endpoint setup and the Varnish bypass rule - in the Magento & Adobe Commerce UCP guide. If you want to compare structural "readiness" checks against full UCP validation, this comparison lays out the difference.

The merchants who win the agentic-commerce transition will not be the ones with the prettiest product pages. They will be the ones whose checkout an agent can actually complete - reliably, in production, on Magento's genuinely complicated stack. The good news is that it is all measurable now. Measure it.

UCP is an open standard by Google and Shopify. UCPtools is an independent community tool.

ACP Moved Checkout to the Merchant Surface. It Didn't Cede Commerce - Here's the Protocol Convergence.

Peter — Wed, 06 May 2026 10:21:17 +0000

ACP Moved Checkout to the Merchant Surface. It Didn't Cede Commerce - Here's the Protocol Convergence.

Updated July 2026: this article originally ran as "ACP Pivoted from Checkout to Discovery. UCP Wins by Default." That call was wrong. ACP's March pivot moved the checkout **surface, not the checkout **capability* - and the 2026-04-17 spec release that landed weeks after this article was published added carts, an orders lifecycle, a public product feed spec, its own /.well-known/acp.json discovery document and MCP transport. ACP is not a discovery-only layer. The sections below are corrected; the implementation advice about UCP profile quality stands.*

In March 2026, OpenAI pivoted ACP (Agentic Commerce Protocol) away from its original premise: completing purchases inside ChatGPT. The "Instant Checkout" button that was supposed to revolutionize shopping? Narrowed. Replaced by a merchant app model where purchases complete on the retailer's own storefront.

That was widely read - including here - as ACP retreating to discovery and handing the commerce stack to UCP. Four months later, that reading has not held up.

What actually happened

OpenAI's ACP launched with an ambitious vision: users would discover products, compare options, and complete purchases entirely within ChatGPT. Stripe provided the payment rails. The promise was a seamless, one-tap checkout experience inside an AI conversation.

The in-chat version of that didn't work.

CNBC reported on March 20 that "OpenAI's first try at agentic shopping stumbled." Users browsed products in ChatGPT but abandoned purchases before completing them. The in-chat checkout experience lacked sales tax infrastructure, return policy visibility, and the trust signals that mature e-commerce storefronts provide.

The pivot, detailed by Digital Commerce 360 on March 24, shifts where checkout renders:

Dedicated retailer apps inside ChatGPT (Instacart, Etsy, Shopify, Walmart)
Product discovery and comparison happens in-chat
Purchase completion happens on the merchant's own storefront (in-app browser on mobile, separate tab on desktop)

The commentary at the time framed this as a demotion. Roger Dunn wrote that "ACP's role shifts from universal long-tail merchant connector to plumbing for deep, bespoke retailer partnerships." Ken Huang's Substack went further: "Google's UCP Just Won Agentic Commerce."

Then OpenAI shipped the 2026-04-17 spec release, and the demotion thesis fell apart.

What ACP actually shipped after the pivot

The 2026-04-17 release is the largest in ACP's history. It added:

Carts (rfc.cart) - merchant-hosted, pre-checkout basket building
Orders (rfc.orders) - a full order lifecycle with fulfillments and adjustments
A public product feed spec (rfc.product_feeds) - the feed model is now public
/.well-known/acp.json (rfc.discovery) - ACP's own discovery document, structurally the same move UCP made with /.well-known/ucp
Delegate authentication (rfc.delegate_authentication) - 3DS2 browser-based auth delegation
MCP transport - an OpenRPC binding so agents can speak ACP over MCP
Mandatory idempotency keys, marketing consent, decimal quantities

Carts and orders are not discovery primitives. They are the transaction layer. A protocol that ships a cart model, an order lifecycle and delegated authentication six weeks after "retreating from checkout" is not retreating from checkout - it is moving the checkout UI to a surface merchants already control while keeping the protocol underneath.

The protocol math - corrected

Before the pivot (January - February 2026):

UCP: Discovery + browsing + cart + checkout, completed in the agent surface
ACP: Discovery + Instant Checkout completed inside ChatGPT

After the pivot and the April spec release:

UCP (latest 2026-04-08): Discovery + browsing + cart + checkout, agent-completed, identity linking, payment handlers
ACP (latest 2026-04-17): Discovery + feeds + cart + orders + delegated payment, with the final purchase step rendered on the merchant surface

The protocols are converging structurally, not splitting into layers. Both now have a .well-known discovery document. Both have a cart model. Both have an orders/checkout lifecycle. They differ in architecture - UCP starts from a JSON manifest agents parse, ACP is a server-to-server REST API the agent calls - and in who completes the final step.

The clearest evidence that "pick the winner" is the wrong frame: Microsoft Copilot is deliberately dual-protocol. It added UCP feeds and UCP-powered checkout in April 2026 while continuing to consume ACP-side Shopify Catalog data. It did not switch. It added.

What this means for developers building today

Implement UCP if you want agent-completed checkout. It's co-created by Google and Shopify with 20+ partners, and it's what Google AI Mode, Gemini, Google Maps, YouTube Shopping and Microsoft Copilot use to discover and transact with stores. The full capability set - catalog browsing, cart, identity linking, payment handlers - is agent-side.

Implement ACP if you want ChatGPT reach - and treat it as a transaction protocol, not a billboard. Feed quality decides whether ChatGPT surfaces your products at all, and the checkout endpoints plus delegated payment decide whether the purchase completes. Payment is an open delegated model: Stripe first, Adyen in the provider enums, PayPal building.

If you have reach ambitions, the honest answer is both. That is what the dual-protocol merchants are doing.

The real implementation gap isn't protocol choice. It's quality. Most deployed UCP profiles fail at basic validation levels:

Missing signing_keys means agents can't verify your manifest
Namespace/origin mismatches break discovery before it starts
Incomplete Cart capability definitions create failed add-to-cart experiences
Identity Linking (the stable spec) is the least-implemented capability despite being the most valuable for cross-domain user recognition

At UCPtools, we scan thousands of profiles. The average score sits well below what AI agents consider reliable. Being "detected" is not the same as being "buyable."

What to build

Implement UCP on your primary store domain first. The .well-known/ucp manifest is table stakes. Make sure it validates at all four levels: structural JSON validity, business rules consistency, network reachability, and SDK-level agent simulation.
Don't skip Identity Linking. It's the stable spec that enables cross-domain user recognition. When a user browses your store on one device and returns via an AI agent on another, Identity Linking is what connects those sessions. Note that the 2026-04-08 UCP revision declares it via config.scopes with PKCE S256 mandatory - validate against whichever version your profile declares.
Treat ACP as a full protocol surface. Publish a clean product feed, stand up the checkout endpoints, and make sure /.well-known/acp.json is reachable. The handoff to your storefront is a UX decision by OpenAI, not a reason to implement half the protocol.
Monitor continuously. Protocols evolve - this article is itself an example of how fast a confident read can go stale. Your profile that validated perfectly in April might fail in June when a capability gets promoted from draft to stable. Continuous validation catches regressions before they cost you AI agent traffic.

The bottom line

There is no protocol war with a winner. ACP moved its checkout surface and then expanded its transaction layer. UCP shipped its own April revision. Microsoft runs both on purpose.

The question for e-commerce developers isn't which protocol to bet on - it's whether your implementation of either one is good enough for an AI agent to actually complete a purchase.

Most aren't.

Validate your UCP profile at https://ucptools.dev?utm_source=devto&utm_medium=article&utm_campaign=202605 - the free tier runs all four validation levels and simulates a real AI agent interaction against your store. Check your ChatGPT/ACP readiness at https://ucptools.dev/acp-checker. If an AI agent can't buy from you, your customers can't either.

DEV Community: Peter

UCP v2026-08-25 Breaks Quietly: 4 Changes That Still Pass Validation

Why this release breaks quietly

Silent breaker 1: signing_keys became keys

We got this wrong in the opposite direction

Silent breaker 2: fulfillment config lost its allows_ prefix and changed shape

Silent breaker 3: buyer consent went from booleans to a reverse-DNS map

Silent breaker 4: payment extensions moved namespace

The migration checklist

The broader point

Is Your UCP Validator Lying to You About Cart and Catalog?

Is Your UCP Validator Lying to You About Cart and Catalog?

The draft-spec trap nobody talks about

What a hard-fail actually costs you

The fix: draft-aware validation

Three things to check in your current validation workflow

The spec is moving. Your validation should move with it.

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

ChatGPT Can Shop Now. Is Your Store Ready to Sell to It?

What ACP Actually Checks

ACP vs UCP: Don't Confuse Them

The March 2026 Pivot (And Why ACP Matters More, Not Less)

The Numbers

Test It in 30 Seconds

Run UCP + ACP Validation in Your CI/CD Pipeline

What actually breaks

The GitHub Action

The pattern that actually pays: gate the deploy

Not on GitHub? Use the CLI

The other protocol: ACP readiness

Where to set the bar

Getting started

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

The Agentic Commerce Stack Is Complete - Here's Your July 2026 Implementation Checklist

1. Validate at All 4 Levels

2. Run the AI Agent Simulator

3. Fix the Top 3 Failures

4. Set Up Monitoring

5. Test All Three Layers

Why This Matters

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Building a Dual-Protocol Checkout with Agorio SDK: Support UCP and ACP in Your AI Commerce Agent

Why Dual-Protocol Support Matters

What Agorio Provides

Step 1: Project Setup

Step 2: Discover a Merchant via UCP

Step 3: Create an ACP Checkout Session

Step 4: Build a Dual-Protocol Shopping Agent

Step 5: Test with Mock Merchants

Step 6: Deployment Considerations

Conclusion: Why Agorio is the Right Choice

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

We Tracked Every AI Agent That Visited Our Site. 5 Different Agents Found Us This Month.

What showed up (and what they did)

This isn't about SEO as you know it

What this means for developer tools and e-commerce platforms

The protocol layer matters too — here's how they connect

How to check if AI agents can find you (and transact with you)

One thing I'm still figuring out

Google's Universal Cart Is Live. Here's the Checklist to Make Sure Agents Can Actually Check Out on Your Store

Level 1: Structure - does the profile parse at all?

Level 2: Rules - is it actually UCP-compliant?

Level 3: Network - do your references actually resolve?

Level 4: SDK - does it pass the official compliance pass?

Run the whole checklist in one call

Where each stack tends to break

The thing the launch list quietly proves

UCP vs ACP: The Battle of AI Commerce Protocols and How to Build for Both

The Rise of Agentic Commerce

UCP: Google & Shopify's Decentralized Approach

Key Architecture

When to Choose UCP

ACP: OpenAI & Stripe's Delegated Payment Model

Key Architecture

When to Choose ACP

Head-to-Head Comparison

Why Choose? Build Both with Agorio

Example: UCP Client

Example: ACP Client

The ShoppingAgent: Auto-Detection Magic

Silent breaker 1: `signing_keys` became `keys`

Silent breaker 2: fulfillment config lost its `allows_` prefix and changed shape