DEV Community: Peter

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 Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

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

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

OpenAI just made the biggest strategic retreat in agentic commerce, and most developers missed what it means for their stack.

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

This isn't a bug. It's an admission that full-stack commerce is harder than discovery. And it hands the complete commerce stack to UCP by default.

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.

It 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 ACP to a merchant app model:

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)

As Roger Dunn wrote in his analysis: "ACP's role shifts from universal long-tail merchant connector to plumbing for deep, bespoke retailer partnerships."

The protocol math just changed

Here's what this means for the two competing protocols:

Before the pivot (January - February 2026):

UCP: Discovery + browsing + cart + checkout (full commerce)
ACP: Discovery + Instant Checkout inside ChatGPT (full commerce)
They competed for the same stack

After the pivot (March 2026 onward):

UCP: Discovery + browsing + cart + checkout (full commerce)
ACP: Discovery + handoff to merchant storefront (discovery only)

The protocols aren't competing anymore. They're converging into different layers of the same stack. UCP owns commerce. ACP owns discovery within ChatGPT's walled garden.

As Ken Huang put it on his Substack: "Google's UCP Just Won Agentic Commerce."

What this means for developers building today

If you're an e-commerce developer deciding where to invest protocol implementation time, the math is now straightforward:

Implement UCP now. It's the only protocol that gives AI agents the full commerce capability: product catalog browsing, cart management, identity linking, and payment processing. It's co-created by Google and Shopify with 25+ partners. It's what Google AI Mode, Gemini, and an expanding ecosystem of agents use to discover and transact with stores.

ACP is becoming a discovery layer. If you want your products surfaced inside ChatGPT conversations, ACP integration matters - but as a discovery mechanism that hands off to your storefront, not as a transaction protocol.

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.
Add ACP as a discovery channel, not a transaction channel. The merchant app model means your ChatGPT presence should focus on product discovery and comparison, with a clean handoff to your UCP-enabled storefront where the actual purchase happens.
Monitor continuously. Protocols evolve. Specs change. 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

The protocol war is over before it really started. ACP pivoted to discovery. UCP owns the commerce stack by default.

The question for e-commerce developers isn't which protocol to bet on - it's whether your UCP implementation is good enough for AI agents 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. If an AI agent can't buy from you, your customers can't either.

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

Peter — Fri, 01 May 2026 10:26:52 +0000

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

Most stores with a UCP profile are stuck at Grade C. Their manifest loads. Agents can see them. But they cannot buy a single thing. Here is what changes when you fix the three fields every Grade C store is missing - and how a 7-day trial makes it a 15-minute job.

The Grade C trap: visible, but not transactable

A Grade C UCP profile means structural validity. Your /.well-known/ucp returns valid JSON. An AI shopping agent can discover your store. That feels like progress.

But Grade C also means the agent hits a wall the moment it tries to do anything commercial. No payment handlers configured. No signing keys for verification. No return policy for the agent to communicate to the buyer. The agent walks away, and your store never knows it happened.

We see this pattern constantly. In the last 7 days, 59 UCP profiles were validated on UCPtools. Eleven of those stores ran the AI Agent Simulator - a real end-to-end agent interaction test. None of them completed a purchase. Zero.

Grade C means "detected." That is not the same as "can transact."

The three fields keeping you at Grade C

After scanning dozens of e-commerce domains, three failures appear on nearly every Grade C profile:

1. signing_keys - the trust layer agents require

Without a public key in your manifest, AI agents cannot cryptographically verify that your UCP responses are authentic. This is not optional. Agents check this before they take any commercial action. A missing signing_keys field is an instant trust failure.

2. payment_handlers - the "how do I pay?" gap

Agents need to know which payment methods your store accepts before they can initiate a checkout. No payment_handlers array means the agent has no path to complete a purchase. The store is technically "discoverable" but functionally invisible for any transaction.

3. Return policy schema - the confidence gap

AI agents are designed to communicate return terms to buyers before purchase. If your manifest does not include return policy information, the agent cannot answer basic buyer questions like "what happens if I need to return this?" That missing confidence costs conversions - both for the agent and for you.

These are not exotic edge cases. They are the baseline requirements that separate "the agent found your store" from "the agent bought from your store."

What the free tools tell you vs. what the trial shows you

Free UCP checkers give you a binary answer: detected or not detected. They run structural validation. They might catch a missing JSON field. But they stop there.

A UCPtools Starter trial ($9/mo, 7 days free, no credit card) gives you four layers the free tools skip:

Level 1 - Structural validation: Yes, free tools do this. Valid JSON, required fields present. This is where every Grade C store already passes.

Level 2 - Rules validation: Business logic checks. Do your namespace and origin match? Are your capability declarations internally consistent? This is where most Grade C stores start failing - but free checkers do not run these tests.

Level 3 - Network validation: Live endpoint testing. Are your UCP endpoints actually reachable over HTTPS? Do they return the correct response codes? A manifest can be structurally valid and still serve 404s to agents.

Level 4 - SDK validation (AI Agent Simulator): This is the one that matters. The simulator behaves like a real AI shopping agent - it discovers your store, reads your manifest, and attempts to complete a purchase. It shows you exactly where the agent fails and why. Eleven stores ran this in the last 7 days. All eleven hit failures that structural validation alone would never catch.

From Grade C to Grade A: the 15-minute path

Here is what the upgrade looks like in practice:

Step 1: Run the full scan (2 minutes)

Start your trial and point UCPtools at your domain. The 4-level scan completes in under 90 seconds. You get a report that looks nothing like a "detected/not detected" badge - it is a prioritized list of failures ranked by severity, with exact fix recommendations.

Step 2: Generate your signing keys (3 minutes)

UCPtools generates a key pair for you through the hosted profile generator. Copy the public key into your manifest. The tool validates the placement so you know it is right before you deploy.

Step 3: Configure payment handlers (5 minutes)

Map your existing payment stack (Stripe, Shopify Payments, PayPal) to the UCP payment handler format. The trial shows you the exact JSON structure your manifest needs based on what your store already supports.

Step 4: Add return policy schema (3 minutes)

Structured return policy data that agents can parse and communicate. The trial's hosted profile builder includes a template you fill in once and deploy.

Step 5: Re-scan and simulate (2 minutes)

Run validation again. Run the AI Agent Simulator. Watch the agent discover your store, verify your keys, read your payment handlers, and complete a purchase simulation. Grade A means the agent can do everything a human shopper can do - find you, browse, and buy.

Why the trial matters (and why it is free)

Nobody pays $9 to see a validation report. They pay $9 because the report tells them something the free tools never will: whether AI agents can actually buy from their store, and exactly how to fix it if they cannot.

The 7-day trial exists because this is not something you evaluate from a marketing page. You need to see your own domain's results. You need to run the simulator against your own store. The trial gives you full access to do exactly that, with no credit card required.

If your store passes structural validation but you have never run the simulator, you do not know if your UCP profile works. You just know it loads.

Scan your store free

Start your 7-day free trial at ucptools.dev - no credit card required. Run a full 4-level validation against your domain and see exactly where your store stands with AI shopping agents.

Written by the team at UCPtools - the only toolkit that validates, monitors, and optimizes your UCP business profile for AI agent discoverability. Questions? Find us on X @ucptoolsdev.

UCP Validation for Agencies: How to Audit AI Readiness Across Every Client Domain

Peter — Wed, 29 Apr 2026 11:02:37 +0000

If you're a GEO consultant or agency managing ecommerce clients, you've probably been asked some version of this question:

"Can AI agents find my store? How do I know?"

The honest answer, until recently, was: you don't. There was no standardized way to measure AI agent discoverability. That changed with UCP (Universal Commerce Protocol) - the open standard from Google and Shopify that gives AI shopping agents a machine-readable entry point to any store.

Now there is something measurable. And if you're the one measuring it for your clients, that's a service worth charging for.

Why Agencies Should Care About UCP Audits

Google AI Mode, Microsoft Copilot, ChatGPT, and Perplexity are all building agentic commerce capabilities. Microsoft announced GA of UCP feeds in Merchant Center on April 21, 2026. Over 12,000 merchants have published UCP profiles as of Q1 2026.

Your clients are going to ask about this. Some already have. The agencies that can answer with data - not hand-waving - will win those conversations.

Here's what makes UCP audits a natural fit for agencies:

It's per-domain. Each client's hosting stack, CDN, and certificate chain breaks differently. A profile that works on Shopify fails on WooCommerce for entirely different reasons.
It's recurring. UCP validation isn't a one-time setup. Deploys break endpoints. CDN caches serve stale schemas. Certificate renewals don't propagate. The profile that passed last month can silently fail this month.
It's reportable. UCP validation produces a numerical AI readiness score (0-100) with specific, fixable issues. That's the kind of deliverable clients understand.

The Agency Audit Framework

Here's a repeatable process for running UCP audits across a client portfolio. It works whether you manage 3 domains or 300.

1. Baseline Scan: Does the Profile Exist?

Before anything else, check whether each client domain serves a UCP manifest at /.well-known/ucp.

https://client-store.com/.well-known/ucp

Three outcomes:

404 / No manifest - The store is invisible to AI agents. Full stop. This is your biggest finding and your clearest upsell.
Manifest exists but invalid JSON - Broken deployment or misconfigured server. Quick fix, high impact.
Valid manifest - Move to deeper validation.

In our experience, roughly 70% of ecommerce stores don't serve a UCP manifest at all. For the ones that do, about 60% have issues at deeper validation levels.

2. Four-Level Validation

UCP validation isn't binary (pass/fail). There are four distinct levels, and each catches different categories of issues:

Level	What It Checks	Common Failures
1. Structural	JSON syntax, required fields, version format	Missing `ucp` root, wrong version format
2. Compliance	Protocol rules: namespaces, HTTPS, signing keys	Namespace mismatches, missing signing keys (42% of L2 failures), HTTP endpoints
3. Network	Do declared URLs actually resolve?	CDN 404s, stale schemas, malformed JWK keys
4. Agent Simulation	Full checkout lifecycle test	Backend returns 500 on cart creation, state machine failures

Most validators - including the free ones your clients might have tried - only check Level 1. That gives false confidence. A Level 1 pass with Level 3 failures means the profile looks correct but agents can't actually use it.

For agencies, Level 3 is the most valuable finding. These are infrastructure-drift issues that only surface after deploys, CDN changes, or certificate renewals. They're invisible to the developer who wrote the profile but obvious to an auditor running regular checks.

3. Score and Categorize

After running validation, each domain gets an AI readiness score (0-100) and a letter grade:

Grade	Score	What It Means
A	90-100	AI agents can discover, browse, and transact
B	70-89	Discoverable with minor issues
C	50-69	Detected but can't complete transactions
D	20-49	Major issues blocking agent interaction
F	0-19	Effectively invisible

The Grade C trap is the most common: the profile exists and passes basic checks, but missing signing keys or broken endpoints prevent any actual transaction. Your client thinks they're "UCP ready" because they have a manifest file. They're not.

4. Build the Client Report

A useful client report contains:

Score and grade for each domain
Issue breakdown by validation level (structural, compliance, network, simulation)
Specific fixes with estimated effort (most Level 2 fixes take minutes)
Comparison to previous audit if this is a recurring engagement
Competitive context - how do they compare to others in their vertical?

The key metric clients care about: "Can AI agents buy from my store?" Frame everything around that question. A score of 62 means "AI agents can find you but can't complete a purchase." That's concrete enough to drive action.

What to Check Per Platform

UCP issues cluster differently by ecommerce platform. Knowing the common patterns saves audit time:

Shopify

UCP profile served via app proxy (path configuration matters)
Payment handler configuration usually correct (Shopify handles this)
Watch for: signing key rotation gaps, custom app conflicts

WooCommerce

Profile typically served via WordPress plugin or .htaccess rewrite
Watch for: HTTP endpoints (mixed content from plugin misconfiguration), schema URL 404s after plugin updates

BigCommerce

Common issue: dev.ucp.shopping service missing required spec field (UCP_INVALID_SERVICE)
Watch for: trailing slashes on API endpoints

Magento / Adobe Commerce

Custom module required for /.well-known/ucp routing
Watch for: namespace mismatches when using third-party extensions, GraphQL endpoint schema drift

Custom / Headless

Most flexibility, most failure modes
Watch for: CORS blocking agent preflight requests, endpoint URLs changing between environments

Automating Portfolio Audits

Running manual checks across 10+ domains doesn't scale. Two automation approaches:

CI/CD Integration (Per Client)

If you have access to client repos, the ucp-validate GitHub Action fails the build when the AI readiness score drops below a threshold:

- uses: Nolpak14/ucp-validate-action@v1
  with:
    domain: 'client-store.com'
    min-score: 70

This catches regressions at deploy time - before they affect agent traffic.

Scheduled Monitoring (Portfolio-Wide)

For ongoing monitoring without repo access, run validation against each client domain on a schedule. The UCPtools validator supports domain-level validation via URL - no code access needed.

Track scores over time. A domain that drops from 85 to 62 between audits means something broke in production, and you're the one catching it before the client's AI-driven traffic disappears.

Positioning This as a Service

UCP auditing fits naturally into existing GEO/SEO service packages:

One-time audit - Baseline scan across all client domains with a findings report. Natural entry point.
Monthly monitoring - Recurring validation with score tracking and regression alerts. Retainer model.
Implementation support - Fix the issues the audit found. Scope varies by platform (Shopify is usually hours, custom builds are days).

The pitch to clients: "Your SEO drives traffic to your store. UCP drives AI agent traffic. We monitor both."

What makes this defensible: UCP validation requires understanding the spec, the four validation levels, and platform-specific patterns. A generic SEO tool can't do this. You can.

Getting Started

Run a free validation against one of your client domains at ucptools.dev. See the score, the issues, and which level caught them.
Repeat for your portfolio. Note which clients have no manifest at all vs. which have broken ones.
Build the report. Score, grade, issues, fixes. Send it to the client.
Set up monitoring. Catch regressions before they cost AI traffic.

The agencies that can quantify AI discoverability will own this conversation. The ones that can't will be explaining why they didn't notice their client's store disappeared from ChatGPT.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Peter — Sun, 26 Apr 2026 15:55:30 +0000

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

We scanned 111 e-commerce stores. 35 of them have UCP profiles that pass validation. But not a single one can actually complete a purchase with AI agents.

Here's why: these "Grade C" stores all share the same 3 critical missing fields.

The Grade C Trap: Detection ≠ Readiness

Every store in the Grade C category (score: 60-79) has UCP manifest files that basic validators like UCPChecker.com report as "valid." They pass structural validation, network connectivity, and even basic schema checks.

But when AI agents actually try to interact with these stores, they fail. Every single time.

The problem isn't that these stores lack UCP profiles. The problem is that their profiles lack 3 specific fields that AI agents need to complete transactions.

The 3 Missing Fields Break AI Commerce

1. Missing `signing_keys` - The Trust Gap

What it is: Cryptographic verification that the UCP manifest hasn't been tampered with.

Why agents need it: AI agents need to verify that the UCP profile they're interacting with is authentic and hasn't been maliciously modified.

Impact: Without signing keys, AI agents cannot trust the UCP profile, making the entire interaction insecure.

Prevalence: 19.8% of stores with UCP profiles lack signing keys, but 100% of Grade C stores are missing them.

2. Missing `payment_handlers` - The Purchase Blocker

What it is: Configuration that tells AI agents how to process payments for the store.

Why agents need it: AI agents need to know which payment methods to use, how to format payment requests, and how to handle payment processing.

Impact: Without payment handlers, AI agents cannot complete purchases. They can discover the store and browse products, but they can't buy anything.

Prevalence: 22.5% of stores with UCP profiles lack payment handlers, but 100% of Grade C stores are missing them.

3. Missing `return_policy` Schema - The Trust Builder

What it is: Structured data about return policies, warranties, and refund terms.

Why agents need it: AI agents need to show customers trust signals before making purchases. Return policies are one of the most important trust signals for e-commerce.

Impact: Without return policy schema, AI agents cannot display return terms, build customer trust, or handle post-purchase service.

Prevalence: 48.6% of all stores lack return policy schema, but 100% of Grade C stores are missing them.

Why This Matters for Agentic Commerce

The Grade C pattern reveals a critical gap in current UCP implementations:

Stores pass "presence" validation but fail "interaction" validation.

This means:

AI discovery works (agents can find the store)
Product browsing works (agents can see products)
But purchasing fails (agents cannot complete transactions)

For agentic commerce to work, we need to move beyond "is UCP present?" to "can UCP actually facilitate commerce?"

How to Fix Your Grade C Profile

The good news: these are configuration issues, not platform limitations. Here's how to address each:

1. Add Signing Keys

{
  "signing_keys": [
    {
      "key_id": "your-key-id",
      "public_key": "your-public-key-here",
      "algorithm": "ES256"
    }
  ]
}

2. Configure Payment Handlers

{
  "payment_handlers": [
    {
      "payment_method": "credit_card",
      "supported_networks": ["visa", "mastercard", "amex"],
      "capabilities": ["supports_installments", "supports_3d_secure"]
    },
    {
      "payment_method": "paypal",
      "capabilities": ["supports_paypal_vault"]
    }
  ]
}

3. Add Return Policy Schema

{
  "return_policy": {
    "return_window_days": 30,
    "return_shipping_paid_by": "merchant",
    "refund_method": "original_payment_method",
    "exceptions": ["final_sale_items", "custom_products"],
    "restocking_fee_percent": 0
  }
}

The BigCommerce Platform Bug

Our scans reveal a specific pattern affecting BigCommerce stores:

Issue: dev.ucp.shopping service missing required spec field
Issue: REST transport missing required schema field
Result: All report UCP_INVALID_SERVICE errors

This appears to be a platform-level issue in BigCommerce's UCP implementation. BigCommerce merchants should verify their REST schema fields and contact BigCommerce support if these fields are missing.

Who's Affected?

All 35 Grade C stores share these exact same failures, including:

SaaS agencies: obundle.com, papathemes.com
Fashion DTC: allbirds.com, brooklinen.com, chubbiesshorts.com, fashionnova.com
Home Decor: curatedhomedecor.com, interiordelights.net, feldkampsfurniture.com
Beauty: kyliecosmetics.com

These aren't small, unknown stores. These are established brands with UCP profiles that "pass validation" but fail at AI commerce.

The Reality Check

65% of stores have zero UCP profiles.
Zero stores are fully AI-agent ready.
35 stores have "broken but detectable" UCP profiles.

The state of agentic commerce readiness is worse than most merchants realize. Having a UCP profile isn't enough. Your profile actually needs to work with AI agents.

Test Your AI Readiness

Don't trust basic validation. Test your actual AI commerce readiness:

Check your signing keys: Can your manifest be cryptographically verified?
Test payment handlers: Can AI agents process payments on your store?
Verify return policy: Do agents have access to your return terms?

The gap between "UCP detected" and "AI commerce ready" is where most merchants are stuck. Fixing these 3 fields is the bridge from discovery to actual transactions.

Data from UCPtools AI Readiness Index (111 domains scanned, April 13, 2026)

Test your store's actual AI readiness at ucptools.dev?utm_source=devto&utm_medium=article&utm_campaign=202604

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

Peter — Fri, 24 Apr 2026 09:54:57 +0000

On January 8, 2026, Microsoft launched Copilot Checkout on ACP - OpenAI's Agentic Commerce Protocol, powered by Stripe.

104 days later, on April 22, Microsoft announced general availability of UCP feeds in Merchant Center. Target was the launch partner. The same day, Ulta Beauty went live with agentic commerce, linking 46 million loyalty members through UCP.

Microsoft didn't just add a second protocol. They switched horses mid-race.

The question nobody's answering clearly: what does UCP have that ACP doesn't?

The answer is one capability: Identity Linking.

The Loyalty Problem AI Agents Create

Think about what happens when an AI agent shops on your behalf.

It finds a product. Compares prices. Adds to cart. Checks out. Every step works. But it checks out as a guest.

The agent doesn't know you're a Target Circle member. It doesn't know you have 50,000 reward points. It doesn't know you qualify for member-only pricing on the item it just found.

Every AI-mediated purchase becomes a guest checkout. Merchants lose their most valuable signal: who this customer actually is.

This isn't an edge case. Target Circle has tens of millions of members. Ulta has 46 million. Sephora, Best Buy, Gap - all UCP endorsers - have massive loyalty programs. When AI agents ignore all of that, merchants lose the customer relationship they spent years building.

The protocol that solves this wins. That's why Microsoft switched.

How Identity Linking Actually Works

Identity Linking is a stable capability in the UCP spec (not draft, not experimental). It's been there since the January 2026 launch.

The namespace is dev.ucp.common.identity_linking - note it's under common, not shopping. This trips up a lot of implementations.

Here's what the capability declaration looks like in your /.well-known/ucp profile:

{
  "name": "dev.ucp.common.identity_linking",
  "version": "2026-01-11",
  "spec": "https://ucp.dev/latest/specification/identity-linking/",
  "schema": "https://ucp.dev/schemas/common/identity_linking.json",
  "config": {
    "supported_mechanisms": [
      {
        "type": "oauth2",
        "issuer": "https://yourstore.com"
      }
    ]
  }
}

The flow uses standard OAuth 2.0 Authorization Code (RFC 6749). Nothing exotic:

Agent reads your UCP profile and sees you support Identity Linking
Agent discovers your OAuth server via RFC 8414 at /.well-known/oauth-authorization-server
Agent requests authorization on the user's behalf
User sees a one-time consent prompt (inside Copilot or Gemini)
Agent gets an access token scoped to ucp:scopes:checkout_session
Every subsequent checkout carries member pricing, points, preferences

The critical insight: one consent, persistent identity. The user approves once. After that, the agent carries their loyalty membership into every future session with that merchant. No re-auth. No per-transaction prompts.

Your OAuth server needs to publish a metadata endpoint per RFC 8414:

{
  "issuer": "https://yourstore.com",
  "authorization_endpoint": "https://yourstore.com/oauth/authorize",
  "token_endpoint": "https://yourstore.com/oauth/token",
  "scopes_supported": ["ucp:scopes:checkout_session"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic"]
}

Note: the OAuth endpoints are NOT declared in the UCP profile. They're discovered dynamically via RFC 8414. The profile only declares the issuer URL.

Target Circle in Copilot: What the Flow Looks Like

Here's what Microsoft built with Target as the launch partner:

You ask Copilot to find running shoes under $80
Copilot queries Target's UCP endpoint, finds matching products
You pick a shoe. Copilot starts checkout
Copilot sees Identity Linking in Target's profile. Prompts: "Connect your Target Circle account?"
You approve. OAuth happens behind the scenes
Checkout continues - but now with your Circle discount applied, your email pre-filled, your reward points available
Next time you shop at Target through Copilot, step 4 is skipped. Your identity persists

This is why Microsoft specifically called out Identity Linking in their Merchant Center announcement. It's not a nice-to-have feature - it's the mechanism that makes loyalty programs survive the shift to AI-mediated commerce.

Why ACP Can't Do This

ACP uses Stripe delegated tokens. A Stripe token represents a payment credential - a card, a wallet, a bank account.

A Stripe token knows your card number. It does not know you're a rewards member. It does not know your loyalty tier. It does not carry member pricing.

ACP has no OAuth identity layer. No account linking mechanism. No way for an agent to say "this shopper is customer #4821 with Gold status."

This is a structural gap, not a missing feature. ACP was designed for payment delegation. UCP was designed for the full commerce lifecycle - including identity.

When Microsoft needed loyalty programs to work in Copilot Shopping, ACP couldn't deliver. UCP could. 104 days was all it took to make the switch.

Implementation: Adding Identity Linking to Your Profile

If you have a loyalty program and want it to work with AI agents, here's what you need:

1. Add the capability to your UCP profile

Add the dev.ucp.common.identity_linking entry to your capabilities array (see the JSON example above). Common namespace - not shopping.

2. Set up your OAuth server

You need a standard OAuth 2.0 Authorization Server with a metadata endpoint at /.well-known/oauth-authorization-server. If you already support OAuth for mobile apps or partner integrations, you're most of the way there.

3. Watch for these validation failures

Our validator catches 4 Identity Linking-specific issues:

Error Code	What Went Wrong
`UCP_IDENTITY_MISSING_MECHANISMS`	No `config.supported_mechanisms` in your capability
`UCP_IDENTITY_INVALID_MECHANISM`	Mechanism entry missing required `type` field
`UCP_IDENTITY_MISSING_ISSUER`	OAuth2 mechanism without an `issuer` URL
`UCP_IDENTITY_ISSUER_NOT_HTTPS`	Issuer URL uses HTTP instead of HTTPS

The most common failure: declaring the capability but forgetting the config block entirely. A Level 1 validator (JSON structure only) won't catch this. You need Level 2 compliance validation.

What To Do Next

Check if your profile declares Identity Linking - if you have a loyalty program and it's missing, your members are invisible to AI agents
Validate your Identity Linking config at ucptools.dev - the validator checks all 4 error codes and tells you exactly what to fix
Add UCP validation to CI/CD - catch regressions before agents do (GitHub Action)
Test the OAuth flow end-to-end - a valid profile means nothing if the OAuth metadata endpoint returns a 404

Microsoft made their bet. Target and Ulta are live. The Identity Linking spec is stable and validated by multiple agent platforms. If you have a loyalty program, this is the capability that makes it travel with your customers into AI commerce.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Peter — Sat, 18 Apr 2026 07:03:35 +0000

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Published April 18, 2026 | 5 min read

We just scanned 111 e-commerce domains and found a staggering truth: 93% of UCP profiles cannot complete AI agent purchases. Not because they don't have UCP files, but because they fail at the 3 critical steps that actually matter for agentic commerce.

The Data Behind the 93%

Our AI Readiness Index scanned 111 reachable domains across fashion, home decor, beauty, SaaS, and marketplaces:

72 domains (65%): Zero UCP presence at all
35 domains (31.5%): Have UCP files but are functionally broken
4 domains (3.6%): Have structural issues
0 domains: Are actually AI-agent ready

Among the 35 stores that technically "pass" UCP validation (Grade C), 100% share the same 3 fatal failures. This is where the real problem lies.

The 3 Failures That Break AI Commerce

1. Missing `signing_keys` - 20% of all stores

{
  "ucp_version": "1.0",
  "signing_keys": []  // ← EMPTY OR MISSING
}

Why it matters: Without cryptographic signing keys, AI agents cannot verify that your UCP manifest is authentic and hasn't been tampered with. This is a security requirement for any transaction.

Impact: Agents will refuse to interact with your store, period.

2. Missing `payment_handlers` - 23% of stores with UCP

{
  "services": {
    "checkout": {
      "type": "rest",
      "uri": "https://yourstore.com/checkout",
      "payment_handlers": []  // ← EMPTY OR MISSING
    }
  }
}

Why it matters: Payment handlers tell AI agents which payment methods you accept (credit cards, PayPal, Apple Pay, etc.). Without them, agents have no idea how to complete a purchase.

Impact: AI agents can discover your store but cannot buy from you.

3. Missing `return_policy` schema - 49% of all stores

{
  "organization": {
    "name": "Your Store",
    "return_policy": {
      "type": "object",
      "properties": {}  // ← MISSING REQUIRED FIELDS
    }
  }
}

Why it matters: Return policies are trust signals for AI agents. They need to know your return terms to recommend your store to users and handle post-purchase issues.

Impact: AI agents cannot display your trustworthiness, reducing conversion likelihood.

The "Detected" ≠ "Ready" Trap

Most UCP validation tools (including our own basic checks) only answer one question: "Is there a .well-known/ucp file?"

They don't answer the questions that actually matter:

✅ Can agents cryptographically verify your manifest?
✅ Can agents process payments at your store?
✅ Can agents display your trust signals?

Stores like Allbirds, Brooklinen, and Fashion Nova all pass basic UCP detection but fail at these critical levels. They're "detected" but not "transactable."

Real-World Example: BigCommerce Bug

We found a platform-wide issue affecting BigCommerce merchants:

{
  "services": {
    "dev.ucp.shopping": {
      "type": "rest",
      "uri": "https://store.mybigcommerce.com/api/ucp",
      "spec": {}  // ← MISSING SPEC FIELD
    }
  }
}

Three BigCommerce domains shared identical UCP_INVALID_SERVICE errors due to missing spec fields. This isn't merchant error - it's a platform implementation issue.

What This Means for AI Commerce

The 93% broken rate isn't just a statistic - it's a barrier to the $15T e-commerce market becoming AI-accessible.

For brands: You have a first-mover advantage right now. Fix these 3 fields and you'll be in the top 7% of AI-ready stores.

For agencies: Your clients' UCP profiles are likely broken even if they "pass" validation. You need to check these 3 critical areas.

For platforms: The current UCP implementation guidance is insufficient. Platforms need to enforce these 3 requirements at the validation level, not just the presence level.

Fix These in 15 Minutes

These aren't complex architectural changes. They're simple field additions:

Add signing keys from your SSL certificate
List accepted payment methods in payment_handlers
Define return terms in the return_policy schema

The tools exist to validate these properly - most just don't yet.

The Market Opportunity

Right now, the gap is enormous:

0% of marketplaces have working UCP
Only 31.5% of DTC brands even have UCP files
Of those, effectively none are actually AI-transactable

This creates a massive opportunity for the first platforms, agencies, and tools that solve these 3 fundamental problems.

Data from UCPtools AI Readiness Index - 111 domains scanned April 13, 2026. Scan methodology: Serper API discovery + targeted validation. All numbers from actual scan reports.

Test your store's UCP profile: https://ucptools.dev/directory?utm_source=devto&utm_medium=article&utm_campaign=202604 ?utm_source=dev.to&utm_medium=article&utm_campaign=202604

UCP and ACP Need a Third Layer: Trust Rails

Peter — Thu, 16 Apr 2026 05:59:36 +0000

If you only watched protocol updates in agentic commerce, this week might have looked like more of the same.

But if you looked at where new announcements actually landed, the signal was different:

UCP and ACP keep defining reach (where an agent can discover and attempt checkout).
A new trust layer is becoming explicit (who carries risk when an autonomous purchase goes wrong).

That second point is the story.

In the last 7 days, the market did not just talk about agent checkout mechanics. It moved toward issuer-side controls, intent proof, and liability handling as first-class infrastructure.

For merchants, this changes the implementation question from:

"Which protocol should we support first?"

to:

"How do we ship protocol coverage and trust controls together so autonomous checkout can scale without blowing up disputes?"

The 7-Day Signal (Apr 10-Apr 16)

Here are the highest-signal changes and discussions from the current window:

Apr 14, 2026: American Express launched ACE developer tooling and registered-agent purchase protection
- Official newsroom announcement: American Express introduced Agentic Commerce Experiences (ACE) and protection mechanics for registered agent purchases.
- Practical meaning: payment-side participants are now publishing explicit models for intent validation, registration, and post-transaction accountability.
Apr 14, 2026: Commerce media coverage emphasized trust, control, and visibility for agent-initiated transactions
- Industry writeups broke out the operational pieces: agent registration, account enablement, purchase intent, tokenized credential pass-through, and optional cart context.
- Practical meaning: trust is no longer an abstract "future standards" topic. It is entering implementation checklists.
Apr 10-Apr 16, 2026: Operator conversation accelerated around protocol fragmentation and execution gaps
- Builders and commerce operators repeatedly framed the same reality: one protocol path rarely covers every agent ecosystem.
- Practical meaning: merchants need a multi-surface strategy (discovery + checkout + payment trust) instead of single-protocol optimism.

UCP and ACP Are Reach Layers, Not Full Safety Models

Let's separate what each layer does.

Layer 1: Reach and Interoperability

UCP (Google/Shopify ecosystem) helps agents discover merchant capabilities and run structured commerce flows.
ACP (OpenAI/Stripe ecosystem) enables structured agent checkout interactions in the ChatGPT-linked path.

Both are essential. Neither is sufficient on its own for production-scale autonomous buying.

Why?

Because successful autonomous commerce needs answers to risk questions that protocol alone does not fully answer:

What evidence proves user intent at authorization time?
Who is accountable if the agent buys the wrong item?
How does dispute resolution separate merchant error from agent error from user error?
What data can be safely retained for adjudication without creating privacy debt?

When volume is low, teams hand-wave these questions.
When agent volume rises, they become blocking architecture.

Why This Week Matters More Than Another Spec Diff

The common pattern in early UCP/ACP discussions was:

"Get discoverable and check-out capable first."

That guidance was directionally right, but incomplete.

This week showed the next constraint very clearly:

Agentic commerce throughput is constrained by the weaker layer:

Throughput ≈ min(protocol reach, trust-rail maturity)

If trust rails lag, throughput stalls. Not because agents cannot click "buy," but because finance, risk, and support teams will cap exposure.

In plain terms:

You can win technical demos with protocol support.
You win real GMV only when risk teams sign off on intent and liability paths.

The New Merchant Architecture (Practical Version)

You do not need to boil the ocean this quarter. You do need to avoid shipping protocol support in isolation.

Use this architecture split:

A) Discovery and Capability Layer

Maintain a valid UCP profile (/.well-known/ucp) where relevant.
Keep capability declarations synchronized with real endpoint behavior.
Validate profile and endpoint health continuously (not manually before launch days).

B) Transaction Execution Layer

Implement clean, deterministic checkout state handling.
Preserve idempotency across agent retries.
Log machine-readable failure reasons so agents can recover.

C) Trust and Liability Layer

Record explicit intent artifacts for agent-initiated actions.
Capture agent identity/registration context where available.
Define dispute routing playbooks: agent error vs merchant error vs user error.
Align payment credential handling with tokenized, scoped, revocable controls.

Most teams currently invest heavily in A and B, then improvise C.
This week's market signal suggests that C is now where winners and false starts will diverge.

A 30-Day Implementation Plan You Can Actually Execute

If your team is small, here is a realistic sequencing model.

Week 1: Baseline Reach Integrity

Validate UCP profile shape and endpoint availability.
Confirm declared capabilities match production behavior.
Patch obvious hygiene gaps (HTTPS, schema paths, key metadata).

Week 2: Checkout Determinism

Add idempotency guards on create/update/complete flows.
Normalize error codes for agent-readable recovery.
Add end-to-end replay tests for interrupted flows.

Week 3: Trust Artifacts

Define and store minimal intent evidence bundle.
Capture agent/session identifiers in transaction metadata.
Document what support can and cannot adjudicate with current logs.

Week 4: Liability Readiness Review

Run simulated dispute scenarios:
- wrong color/variant selected by agent
- stale availability race
- canceled intent arriving after delayed authorization
Confirm owner and fallback path for each failure mode.
Update customer-facing policy language for autonomous purchases.

This is not "perfect security architecture."
It is enough to move from experimental to operational.

The Cost of Ignoring the Trust Layer

If you skip this shift and treat agentic commerce as protocol-only, you will usually see one of four outcomes:

High discovery, low completion: agents can find you but fail late in checkout.
Completion spikes, dispute spikes: operations spend explodes and leadership throttles rollout.
Silent risk caps: internal teams reduce allowed agent use-cases without product visibility.
Channel fragmentation debt: each ecosystem gets separate one-off fixes, no shared risk model.

In other words, engineering may report "integration complete" while finance reports "do not scale this yet."

Where UCPtools Fits (and Where It Doesn't)

UCPtools helps with the readiness and validation side:

profile and capability validation
endpoint and schema checks
implementation diagnostics you can run before shipping

It does not replace your policy, underwriting, or issuer agreements.

But it does reduce one expensive failure class: shipping broken protocol posture and discovering it only after agents already route traffic.

If you want a quick baseline, run your domain through the validator:

https://ucptools.dev/validator?utm_source=devto&utm_medium=article&utm_campaign=ai_commerce_for_developers&utm_content=risk_layer

Then use the score as your Week 1 input for the 30-day plan above.

What to Do This Week

If you are deciding where to spend engineering time in April, here is the short answer:

Do not pick between UCP and ACP as an ideology war.
- Pick based on your near-term customer channel mix.
Do not treat protocol support as the finish line.
- Add intent and liability handling to the same roadmap.
Do not wait for perfect standards convergence.
- Build a clear internal trust model now, then adapt.

The teams that move fastest from pilot to durable volume will likely be the ones that connect these layers earliest:

Reach (UCP/ACP) + Execution (checkout reliability) + Trust (intent/liability rails).

That was not obvious to most teams a month ago.
After this week, it should be.

UCP is an open standard driven by Google and Shopify. ACP is an open standard driven by OpenAI and Stripe. UCPtools is an independent community tool and is not affiliated with Google, Shopify, OpenAI, or Stripe.

UCP vs ACP Payment Architecture: Why Both Protocols Matter for AI Commerce

Peter — Wed, 15 Apr 2026 09:00:42 +0000

UCP vs ACP Payment Architecture: Why Both Protocols Matter for AI Commerce

In the realm of AI-driven commerce, two protocols have emerged as frontrunners in enabling seamless transactions between consumers and merchants: the Universal Commerce Protocol (UCP) and the Agentic Commerce Protocol (ACP). Both protocols aim to bridge the gap between AI agents and commerce platforms, yet their approaches diverge in several key ways. This article will delve into these differences, highlighting when and why you might choose one over the other.

Understanding UCP and ACP

Universal Commerce Protocol (UCP):

Developed with a focus on interconnectivity and standardized interactions.
Establishes a "trust triangle" involving consumers, merchants, and AI agents.
Leverages a decentralized manifest system for merchant discovery, ensuring flexible integration.

Agentic Commerce Protocol (ACP):

Prioritizes rapid deployment and ease of use.
Utilizes a delegated payment model, allowing agents to act as intermediaries.
Supports both centralized and decentralized discovery mechanisms.

Payment Credential Flow Differences

UCP: Centers around direct credential exchanges with robust verification steps, ensuring high security.
ACP: Employs a streamlined delegated approach, where agents facilitate transactions without directly handling sensitive credentials.

Trust Triangle vs Delegated Payment

UCP Trust Triangle: Creates a robust ecosystem where merchants and consumers can interact through verified AI agents. This approach emphasizes security and reliability.
ACP Delegated Payment: Facilitates quicker transactions by reducing the steps needed for verification, making it ideal for environments where speed is more critical than comprehensive checks.

When to Use Which Protocol?

UCP: Best suited for environments where security and interoperability are paramount. It's the protocol of choice for platforms needing a robust verification system.
ACP: Optimal for scenarios requiring rapid transaction speeds and minimal friction in onboarding new merchants or consumers.

Agorio: Dual-Protocol Support

Agorio stands out by offering dual-protocol support, seamlessly integrating both UCP and ACP to provide flexible options for developers. Whether building for security-focused platforms or speed-intensive environments, Agorio's SDK ensures compatibility and enhances the AI-commerce interface.

Conclusion

In the evolving landscape of AI commerce, the choice between UCP and ACP largely depends on specific business needs. While UCP offers rigorous security and interoperability, ACP provides speed and ease of use. By understanding and leveraging the strengths of both protocols, developers can create more effective and versatile AI-driven commerce solutions.

WooCommerce UCP Setup: The 3 Fields Most Developers Miss

Peter — Mon, 13 Apr 2026 06:55:15 +0000

You installed the WordPress plugin. Your .well-known/ucp endpoint returns valid JSON. The UCP checker says "Detected."

But AI shopping agents still can't buy from your store.

After scanning 43 WooCommerce domains with UCP manifests, we see the same 3 missing fields over and over. Not edge cases. Not spec trivia. These are the fields that determine whether an AI agent can actually complete a purchase - or just window-shop and leave.

The state of WooCommerce UCP right now

WooCommerce does not have native UCP support. There's an official feature request and a GitHub discussion, but as of April 2026, you're on your own.

The WordPress plugin gets you started. It generates the manifest and serves it at the right endpoint. That covers structural validation.

But structural validation is level 1 of 4. The next 3 levels are where WooCommerce stores fall apart.

Field 1: `signing_keys` (missing on ~60% of WooCommerce UCP profiles)

The signing_keys field tells AI agents how to verify that your manifest is authentic - that it actually came from you and wasn't tampered with.

Without signing_keys:

Agents can't cryptographically verify your manifest
Some agents will skip your store entirely rather than risk interacting with an unverified profile
Google's UCP documentation explicitly recommends including signing keys

In our Apr 10 scan of 15 domains, over half were missing this field. The WordPress plugin doesn't generate it by default. You need to add it manually.

How to add it:

Generate a key pair (Ed25519 recommended):

openssl genpkey -algorithm ED25519 | openssl pkey -outform DER | base64

Add to your .well-known/ucp manifest:

{
  "signing_keys": [{
    "alg": "EdDSA",
    "kid": "key-1",
    "key": "BASE64_PUBLIC_KEY_HERE"
  }]
}

Store the private key securely. You'll need it if you ever sign UCP responses.

Field 2: `payment_handlers` (missing on ~70% of WooCommerce UCP profiles)

This is the one that actually breaks checkout. payment_handlers tells AI agents which payment methods your store accepts. Without it, agents know your store exists but have no idea how to pay.

This is not the same as your WooCommerce payment gateway settings. Those are for human checkout flows. payment_handlers is the machine-readable equivalent.

How to add it:

{
  "capabilities": {
    "checkout": {
      "payment_handlers": [
        {
          "type": "card",
          "networks": ["visa", "mastercard", "amex"]
        },
        {
          "type": "payment_link",
          "url": "https://your-store.com/pay/{sessionId}"
        }
      ]
    }
  }
}

Match the networks to what your WooCommerce payment gateway actually supports. Don't declare Amex if you don't accept it - agents will try to use it and the transaction will fail at checkout.

Field 3: Namespace/origin match (broken on ~40% of WooCommerce UCP profiles)

The namespace and origin fields in your manifest must match your actual domain. This sounds obvious, but it breaks constantly when:

Your WordPress site is at www.yourstore.com but the manifest declares yourstore.com
You use a CDN subdomain that differs from your WooCommerce origin
The WordPress plugin auto-generates the origin from site_url which may not match the domain AI agents use to discover you

If an agent requests /.well-known/ucp from www.yourstore.com and the manifest says origin: "yourstore.com", the agent may reject the manifest as invalid for that domain.

How to fix it:

Check what domain AI agents actually use to find your store. It's usually the canonical URL (the one with www or without, whichever you've standardized on).
Make sure your manifest matches:

{
  "namespace": "https://www.yourstore.com",
  "origin": "https://www.yourstore.com"
}

If you serve on both www and non-www, pick one canonical domain and redirect the other. Don't try to serve different manifests on each - that's a namespace collision.

Why these 3 matter more than the rest

All three of these failures happen at validation level 2 (rules) or level 3 (network). A basic JSON validator won't catch them. A "Detected / Not Detected" checker won't catch them. They only surface when you:

Run rules-based validation that checks capability consistency
Actually test the endpoint with a live HTTP request
Simulate an AI agent trying to complete a purchase flow

This is the gap between "my UCP file exists" and "AI agents can buy from my store." It's the gap that matters.

Quick validation checklist for WooCommerce stores

Run through this after you set up the WordPress plugin:

[ ] signing_keys present with Ed25519 or RSA key
[ ] payment_handlers lists the card networks you actually accept
[ ] namespace and origin match your canonical domain (including www)
[ ] All endpoints use HTTPS (no HTTP)
[ ] No trailing slashes on endpoint URLs
[ ] Cart capability includes add, remove, and view actions (not just add)
[ ] Return policy schema present if you have a return policy

You can validate all 4 levels for free at ucptools.dev. It runs structural validation, rules checks, live endpoint testing, and AI agent simulation - not just "is the file there."

What about Google's March 2026 UCP update?

Google released new UCP capabilities and a simplified onboarding experience in March 2026. The update focuses on making it easier for merchants to get started, but the core validation requirements haven't changed. Your .well-known/ucp still needs the same fields. The difference is that Google is now providing more guidance on what "complete" looks like - which makes the missing fields above even more visible.

If you set up your WooCommerce UCP profile before March 2026, it's worth re-validating. The rules about what constitutes a "passing" profile have tightened.

Bottom line

The WordPress plugin gets your WooCommerce store to level 1. That's the floor. If you want AI agents to actually complete purchases - not just discover your products and bounce - you need level 2-4 validation. The 3 fields above are where most WooCommerce stores fail. Fix them and you're ahead of the curve.

Validation data from UCPtools scans conducted Apr 1 and Apr 10, 2026. Sample sizes: 28 and 15 domains respectively. Percentages are approximate given sample size.

Shopify Agentic Storefronts Enabled? Your UCP Profile Still Has Gaps.

Peter — Sat, 11 Apr 2026 08:38:47 +0000

You enabled Shopify's Agentic Storefronts. You verified your .well-known/ucp returns JSON. Google AI Mode should be able to find your store now, right?

Maybe. Probably not.

In our April 1 scan of 28 e-commerce domains, every single store that had a UCP manifest was still failing at least 3 validation checks. Not one scored healthy. The most common pattern: Shopify generates the manifest structure correctly, but leaves critical fields empty or misconfigured - and most merchants never notice because their JSON looks valid.

Here is what is actually missing, why it matters for AI agent discovery, and what to check.

What Shopify's Agentic Storefronts Actually Set Up

When you enable the Agentic plan in Shopify, the platform auto-generates a .well-known/ucp manifest. It includes:

Store metadata (name, origin, namespace)
Capabilities block (Cart, Catalog, Identity Linking, Checkout)
Transport bindings pointing to Shopify's endpoint infrastructure

This gets you past Level 1 validation (structural). The JSON parses. Required fields exist. If you run a basic JSON schema validator, it passes.

But AI agents do not stop at Level 1. They need the manifest to be callable - endpoints that respond, keys that verify, handlers that process payments.

The 4 Gaps Shopify Leaves Open

1. Missing Signing Keys

What you see: JSON validates fine. No errors in your Shopify admin.

What AI agents see: No signing_keys array in the manifest. Agents that verify manifest authenticity (and Google's agents do) cannot confirm the profile was published by the domain owner. This is a trust signal, not just a formality.

Fix: Generate a key pair, add the public key to your UCP manifest's signing_keys field, and sign your manifest responses. Shopify does not handle this automatically.

Severity: Build-breaking. Missing signing keys means agents skip your store or treat it as unverified.

2. No Payment Handlers

What you see: Checkout works in the browser. Customers buy things.

What AI agents see: The payment_handlers array is empty or missing. Agents that want to complete a purchase on behalf of a user cannot determine which payment methods your store accepts through the UCP manifest alone.

Fix: Add each active payment method to payment_handlers in your manifest. This includes credit cards, Shop Pay, Apple Pay, Google Pay - whatever your store accepts.

Severity: Build-breaking for checkout-capable agents. Discovery and browsing still work, but the purchase flow is blocked.

3. Missing Return Policy Schema

What you see: Your return policy is on a web page. Humans can read it.

What AI agents see: No structured return policy data in your manifest or linked schema. Agents cannot communicate return terms to users before purchase. For regulated categories (cosmetics, electronics), this is a hard blocker.

Fix: Add a returnPolicy field to your product schema or UCP manifest. Use Schema.org's MerchantReturnPolicy type.

Severity: Warning for most stores. Build-breaking for regulated product categories.

4. Organization Schema Gaps

What you see: Your About page exists. Your brand looks legitimate.

What AI agents see: No Organization schema linked from your manifest. Agents that verify merchant identity (especially for first-time interactions) cannot confirm the business behind the store.

Fix: Add Schema.org Organization markup to your store's homepage. Include @id, name, url, and contactPoint at minimum.

Severity: Warning. Does not block discovery, but reduces trust scoring for agents that cross-reference identity.

How to Actually Validate This

Running curl https://your-store.com/.well-known/ucp tells you the JSON exists. It does not tell you whether an AI agent can use it.

Here is what to check instead:

Level 1 - Structural: Does the JSON parse? Are required fields present? (Shopify handles this.)

Level 2 - Rules: Are capabilities consistent? Does your namespace match your origin? Are declared capabilities actually wired to endpoints? (Shopify partially handles this, but custom theme modifications can break it.)

Level 3 - Network: Do the endpoints in your manifest actually respond? Over HTTPS? With correct content types? With no trailing slashes? (Shopify handles the endpoints, but CDN misconfigurations, custom domains, and redirect chains can break reachability.)

Level 4 - SDK: Can a real AI agent complete a discovery-to-checkout flow? Can it browse, add to cart, and initiate payment? (This is where most "valid" manifests fail - the structure is right but the interaction flow breaks at runtime.)

The 5-Minute Checklist

Run through this after enabling Agentic Storefronts:

curl -I https://your-store.com/.well-known/ucp - verify 200 status, application/json content type, HTTPS
Check the response for signing_keys - if empty or missing, generate and add keys
Check the response for payment_handlers - if empty, list your active payment methods
Check your homepage for Organization schema - add if missing
Check your product pages for returnPolicy schema - add if missing

Or run a free 4-level validation at ucptools.dev that checks all of this in one scan, including a simulated AI agent interaction.

The Bigger Picture

Shopify's Agentic Storefronts are the on-ramp, not the destination. They handle the hardest part (generating a spec-compliant manifest and wiring commerce endpoints). But the trust and completeness layer - signing keys, payment handlers, identity and return policy schema - is still on you.

Most merchants will enable the feature, see the green checkmark in Shopify admin, and assume they are done. The ones who validate beyond Level 1 are the ones AI agents actually find and use.

The gap between "enabled" and "discoverable" is where your competitors will also get stuck. Close it first.

Scan data from UCPtools' April 1, 2026 scan of 28 e-commerce domains. 0 healthy profiles found. 92% broken or missing. Full results at ucptools.dev/directory.

DEV Community: Peter

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

What a Watchdog Actually Watches

The 10-Line Version: cron + curl

The GitHub Action Version: scheduled, with a baseline

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

Platform Notes

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

Why Magento Is a Different Animal

Level 1: Structural - Does the Profile Parse?

Level 2: Rules - Is the Profile Internally Consistent?

Level 3: Network - Do the Endpoints Actually Answer?

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

The Part Most Magento Teams Miss: Discovery Is Not Checkout

How to Check Your Store

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

ACP Pivoted from Checkout to Discovery. UCP Wins by Default - Here's the Protocol Convergence.

What actually happened

The protocol math just changed

What this means for developers building today

What to build

The bottom line

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

What Your UCP Trial Unlocks: From Grade C to Grade A in 15 Minutes

The Grade C trap: visible, but not transactable

The three fields keeping you at Grade C

What the free tools tell you vs. what the trial shows you

From Grade C to Grade A: the 15-minute path

Why the trial matters (and why it is free)

Scan your store free

UCP Validation for Agencies: How to Audit AI Readiness Across Every Client Domain

Why Agencies Should Care About UCP Audits

The Agency Audit Framework

1. Baseline Scan: Does the Profile Exist?

2. Four-Level Validation

3. Score and Categorize

4. Build the Client Report

What to Check Per Platform

Shopify

WooCommerce

BigCommerce

Magento / Adobe Commerce

Custom / Headless

Automating Portfolio Audits

CI/CD Integration (Per Client)

Scheduled Monitoring (Portfolio-Wide)

Positioning This as a Service

Getting Started

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

The Grade C Trap: Detection ≠ Readiness

The 3 Missing Fields Break AI Commerce

1. Missing signing_keys - The Trust Gap

2. Missing payment_handlers - The Purchase Blocker

3. Missing return_policy Schema - The Trust Builder

Why This Matters for Agentic Commerce

How to Fix Your Grade C Profile

1. Add Signing Keys

2. Configure Payment Handlers

3. Add Return Policy Schema

The BigCommerce Platform Bug

Who's Affected?

The Reality Check

Test Your AI Readiness

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

The Loyalty Problem AI Agents Create

How Identity Linking Actually Works

Target Circle in Copilot: What the Flow Looks Like

Why ACP Can't Do This

Implementation: Adding Identity Linking to Your Profile

What To Do Next

93% of UCP profiles are broken. Here are the 3 failures that matter most.

93% of UCP profiles are broken. Here are the 3 failures that matter most.

The Data Behind the 93%

The 3 Failures That Break AI Commerce

1. Missing signing_keys - 20% of all stores

2. Missing payment_handlers - 23% of stores with UCP

3. Missing return_policy schema - 49% of all stores

The "Detected" ≠ "Ready" Trap

Real-World Example: BigCommerce Bug

1. Missing `signing_keys` - The Trust Gap

2. Missing `payment_handlers` - The Purchase Blocker

3. Missing `return_policy` Schema - The Trust Builder

1. Missing `signing_keys` - 20% of all stores

2. Missing `payment_handlers` - 23% of stores with UCP

3. Missing `return_policy` schema - 49% of all stores

Field 1: `signing_keys` (missing on ~60% of WooCommerce UCP profiles)

Field 2: `payment_handlers` (missing on ~70% of WooCommerce UCP profiles)