DEV Community: Almin Zolotic

The WooCommerce Cart Abuse Problem Hidden by Modern Bot Traffic

Almin Zolotic — Sun, 11 Oct 2026 03:04:48 +0000

Residential proxy networks have become a significant part of the infrastructure used for automated internet activity. They can route requests through consumer connections, rotate addresses rapidly, and make traffic difficult to classify using IP reputation or request frequency alone. This is no longer a hypothetical security concern. In July 2026, Lumen's Black Lotus Labs reported tracking nearly 20 million distinct IP addresses per day across more than 30 malicious proxy botnet clusters, with more than 20 clusters regularly exceeding 100,000 daily victims. Its research describes a market in which proxy operators can replenish their inventory through interconnected botnets and reselling arrangements. [1]

The same month, Reuters reported that Google, working with the FBI, Lumen and other partners, had disrupted infrastructure associated with NetNut, a residential proxy service operated by Israeli company Alarum Technologies. Google said the intervention reduced the available proxy-device population by millions. The reported investigation concerned the relationship between NetNut and the Popa botnet. [2] Ynet/Calcalist also reported an FBI investigation into whether devices were enrolled without owners' consent, Alarum's temporary suspension of relevant traffic, and the company's statements that it was cooperating and disputed some outside findings. [3] These reports concern NetNut and do not establish that NetNut was responsible for the traffic described in our WooCommerce investigation.

Google Threat Intelligence Group published its own technical account on July 2, 2026. It estimated that the NetNut network included at least 2 million devices worldwide and reported observing 316 distinct threat clusters using suspected NetNut exit nodes during one week in June, including cybercriminal and espionage activity. Google described SDKs embedded in smart TVs and streaming boxes, disabled Google services used for command and control, and said Play Protect was acting against applications incorporating known NetNut SDKs. These findings are also discussed in Michael Kan’s July 2 PCMag report, This Proxy Service Is Using TV Streaming Devices to Host Cybercrime. [5][6] The figures describe Google’s investigation, not the size or attribution of the traffic hitting House of Parfum.

The significance for online stores is practical. A store does not need to be the target of a conventional denial-of-service flood to experience unwanted application work. Distributed automation can invoke legitimate-looking endpoints at scale, while each individual address appears only once.

During an investigation of automated traffic against House of Parfum, a live WooCommerce store, Zologic observed exactly this pattern. In one correctly parsed server-log interval, we recorded 2,167 direct add-to-cart operations from 2,156 unique source IP addresses. Of those operations, 2,139 returned HTTP 403 after protective controls were introduced. That is approximately 1.005 operations per IP address. We built Zologic WooCommerce Cart Guard to address this specific application-level problem.

What the server was actually processing

The activity centered on WooCommerce's legacy direct add-to-cart mechanism:

?add-to-cart=<product_id>

This is legitimate WooCommerce functionality. It is also a cart-changing operation that can be requested directly. A syntactically valid URL and an ordinary browser user agent do not establish that a request came through the intended storefront interaction.

We extracted operations from the HTTP request field of the web-server access logs, rather than searching the entire line for add-to-cart. That distinction prevents an unrelated referrer URL from being miscounted as a cart operation.

Measurement	Observed result
Actual direct add-to-cart operations	2,167
Unique source IP addresses	2,156
HTTP 403 responses	2,139
Operations per source IP	1.005

The result explains why per-IP rate limiting was poorly matched to this traffic. A rule looking for repeated requests from one address has almost no history to work with when the address changes after approximately one operation. Blocking the first IP can still be useful, but it does not prevent the next request from arriving through a different address.

This is not evidence that all 2,156 IP addresses belonged to one operator, one proxy provider, or one botnet. It is evidence of a highly distributed pattern of direct WooCommerce operations.

What our traffic, ASN and Analytics analysis showed

We investigated several layers of data: raw access-log requests and response codes, source IP addresses, ASN/network ownership, geographic distribution, user-agent strings, Google Analytics observations, and later Cart Guard telemetry.

The traffic included rotating addresses, ordinary-looking Chrome user agents, and source networks associated with multiple geographies, including Chinese and Singaporean address space. Some infrastructure was consistent with proxy use. An IP's geolocation is not the location or nationality of the person directing the traffic, and an ASN alone does not establish who initiated a request.

We also escalated traffic involving HostRoyale infrastructure. In its response, HostRoyale identified Bright Data Ltd. as its customer for the reported infrastructure and stated that it had asked Bright Data to investigate its user. That is a specific provider relationship documented by the correspondence; it is not proof that Bright Data itself directed the requests, nor that every source address in the broader dataset was part of its network.

Google Analytics gave us a different perspective from the origin logs. An HTTP operation may be processed by WooCommerce without appearing as a meaningful Analytics shopping session. This makes Analytics alone an incomplete measurement of automated application work. We used it alongside server and application telemetry, not as a substitute for them.

Why residential proxy infrastructure matters

Black Lotus Labs' July 2026 report provides broader context for what we observed. Its researchers describe malicious proxy ecosystems that combine compromised routers, Android devices and other consumer hardware with commercial storefronts and resellers. Some operators reportedly regain capacity quickly after disruptions because the supply chain connects multiple proxy pools. [1]

That research does not identify the operator of our WooCommerce traffic. It does, however, explain why an attacker or automated client can obtain many unrelated-looking source addresses and why static IP lists are an incomplete answer.

Google’s primary technical report adds detail beyond the news coverage: it identifies consumer streaming hardware as part of the proxy supply chain, describes how home devices can become exit nodes, and reports the use of suspected NetNut exit nodes by hundreds of distinct threat clusters. Google also warned that disrupted proxy operators may purchase capacity from competitors or resell other networks, complicating attempts to block a single provider. [5] PCMag reported these findings and the FBI domain seizures, including Alarum’s statement that it would cooperate with the investigation. [6]

The NetNut/Popa reporting is another illustration of the scale and enforcement attention surrounding the proxy market. Reuters described Google's July 2026 disruption and Alarum's cooperation statement. [2] Ynet described allegations being investigated about device enrollment and also reported the company's position and response. [3] Investigations, allegations, observed infrastructure links, and proven wrongdoing are not interchangeable.

For a merchant, the immediate problem is simpler: the request still reaches an application endpoint, regardless of how many intermediary devices or providers carried it.

Why this activity can be missed

WooCommerce security discussions often focus on compromised accounts, vulnerable plugins, malicious uploads, credential attacks and payment fraud. Direct cart abuse can generate none of those indicators.

The site may see valid HTTP syntax, a recent Chrome user agent, and a source IP with no previous history. Yet processing a cart mutation can involve PHP execution and WooCommerce application work. Depending on configuration, sessions, cookies, cache and database operations may also be involved. The actual performance impact depends on traffic volume and store configuration; our request counts alone do not quantify lost revenue or resource consumption.

A firewall may correctly find no known exploit signature. A rate limiter may find no repeat offender. Analytics may not represent the requests as ordinary customer sessions. The store is still receiving attempts to perform a cart operation.

What Cart Guard changes

Zologic developed WooCommerce Cart Guard around authorization of the cart operation, rather than a universal classification of the client.

For the legacy ?add-to-cart= path covered by the current implementation, a normal first-party storefront flow obtains short-lived cryptographic proof. Cart Guard verifies that proof before permitting the protected mutation. A direct request without the required proof can be rejected before the protected WooCommerce operation proceeds.

The proof is not a human-verification mechanism. It establishes the expected storefront context. Browser automation capable of obtaining and replaying legitimate proof within its validity window is a different threat model, so this should not be described as an absolute barrier to all bots or AI agents.

The design also preserves explicitly supported machine-commerce interfaces. WooCommerce REST/Store API routes and UCP discovery or agent interfaces are not indiscriminately blocked simply because their callers may be automated. The current protected scope is the legacy direct add-to-cart flow, not every possible WooCommerce cart mutation.

Production results and telemetry

A later Cart Guard production snapshot recorded 223 direct cart mutations from 222 unique observed sources, with 162 blocked requests, 59 suspicious/no-proof requests, and 2 validated storefront requests. The near one-to-one relationship between mutations and unique sources remained visible at the application layer. These counters span different operating modes: some suspicious/no-proof requests were recorded during Observation mode, so 162/223 should not be interpreted as an Enforcement-mode block rate.

The telemetry matters because a single blocked-request number does not describe whether a store is seeing repeated requests from one client or one request each from hundreds of clients. In our case, the latter pattern persisted.

Where Cloudflare, Wordfence and Fail2ban fit

Cart Guard does not replace network or general WordPress security controls. Edge services such as Cloudflare can provide WAF rules, bot management, challenges, reputation filtering and rate limiting. WordPress security plugins cover many other attack classes. Fail2ban can turn precise server-log events into temporary IP bans, and firewall rules can stop unwanted network ranges before PHP executes.

Those layers remain valuable. We used multiple layers during this incident.

The narrower issue is that a generic network control does not inherently know whether a WooCommerce direct cart operation followed the storefront sequence expected by the application. Cart Guard makes that decision with WooCommerce-specific context. A resulting HTTP 403 can then become a reliable signal for an additional layer such as Fail2ban.

We did not find an existing WordPress security control that addressed this exact one-operation-per-IP, legacy direct-cart authorization problem in the way we needed. That is a statement about our evaluation and design requirements, not a claim that no other plugin or Cloudflare configuration can ever mitigate related traffic.

AI agents and the changing definition of automated traffic

AI agents, search crawlers, browser automation, scrapers and abusive clients increasingly share the same transport techniques: ordinary browser identities, JavaScript execution, distributed networks and proxy services. The overlap makes source-based classification an imperfect basis for deciding whether an application operation should proceed.

At the same time, legitimate machine commerce is developing. Blocking everything that looks automated would interfere with supported integrations and emerging agent protocols. A store needs to decide which operations are permitted and through which interfaces.

For Zologic, the operational lesson was to keep IP intelligence, ASN analysis, analytics, edge controls and incident response, but to move the cart-operation authorization decision into WooCommerce itself. Cart Guard was developed and tested against the distributed traffic described here, with a deliberately limited and measurable scope.

You can purchase the battle-tested Zologic WooCommerce Cart Guard plugin here.

Sources

Lumen Black Lotus Labs, Symbiotic parasites: the modern proxy ecosystem, July 24, 2026. https://www.lumen.com/blog/en-us/symbiotic-parasites-the-modern-proxy-ecosystem
Reuters, Google disrupts NetNut proxy network used in malware operations, July 2, 2026. https://www.reuters.com/business/media-telecom/google-disrupts-netnut-proxy-network-used-malware-operations-2026-07-02/
Ynet / Calcalist, Israeli tech firm Alarum crashes after FBI probe into proxy network, July 5, 2026 (date displayed as 07.05.26). https://www.ynetnews.com/business/article/syvloyu7me
Zologic incident investigation, House of Parfum production web-server access logs, IP/ASN and geography analysis, Google Analytics review, HostRoyale abuse correspondence, and WooCommerce Cart Guard telemetry, October 2026. Internal evidence; not publicly linked.
Google Threat Intelligence Group, Google’s Continued Disruption of Malicious Residential Proxy Networks, July 2, 2026. https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks
PCMag / Michael Kan, This Proxy Service Is Using TV Streaming Devices to Host Cybercrime, July 2, 2026 (updated July 7). Report text supplied for this article.

Independent research shows e-commerce is directly in the target set

This is not only a pattern we observed on one WooCommerce store. In June 2026, Synthient published research based on outbound traffic collected from residential-proxy SDKs. Its researchers reported that the majority of the proxy traffic they observed facilitated abuse against financial institutions, advertising networks and e-commerce platforms. The report also argues that the industry's increasing emphasis on AI use cases can obscure the abusive traffic that continues to move through these networks.

Synthient's dataset is especially relevant to what we measured because its analysis focused heavily on the Popa proxy botnet. The researchers reported observing Popa-connected devices routing traffic for both IPIDEA and NetNut, and described an ecosystem built in significant part from Android applications, TV boxes and routers. For May 2026 alone, Synthient reported approximately 9.2 million unique domains and subdomains targeted by residential proxies. Its examples of high-value targets included Walmart, alongside Google and Ticketmaster.

The defensive conclusion independently reaches the same problem we encountered in WooCommerce: traditional IP reputation alone is insufficient. Synthient explicitly recommends that defenders move beyond traditional IP-risk blocklists and use multiple layers of detection. Our production data shows why this becomes particularly difficult at the application level: when 2,167 cart operations arrive from 2,156 source IPs, there is almost no per-IP history on which a conventional rate limiter can act.

Source: Synthient Research — Who Are The Victims of Residential Proxies? (June 9, 2026)

8,096 IPs, One WooCommerce Cart Attack: How We Protected the Cart Without Blocking AI Commerce

Almin Zolotic — Mon, 05 Oct 2026 22:35:03 +0000

A real-world WooCommerce incident involving rotating IPs, browser-like bot traffic, WordPress lifecycle ordering, signed cart proofs, Redis, and keeping UCP/MCP agent commerce online.

A WooCommerce store we operate started showing a strange traffic pattern.

At first glance, it looked like growth.

Traffic increased sharply. The basket page was receiving unusual attention. Google Analytics showed thousands of new sessions.

Then we looked closer.

Engagement was almost zero.

Revenue from the traffic was zero.

And thousands of requests were hitting WooCommerce URLs containing:

?add-to-cart=...

This turned into an interesting engineering problem because the obvious solutions were also the wrong solutions.

We could not simply block the IP addresses.

We could not block the browser User-Agent.

We did not want to block legitimate crawlers indiscriminately.

And most importantly, we are actively building infrastructure that allows legitimate AI shopping agents to interact with WooCommerce.

We needed to stop abusive automation without breaking agentic commerce.

This is how we approached it.

The first signal: analytics that made no sense

The traffic initially looked impressive.

Thousands of sessions appeared, with large increases in active and new users.

But almost none of those sessions behaved like customers.

We saw extremely low engagement and a disproportionate amount of traffic around the WooCommerce basket.

Server logs provided the real picture.

Requests repeatedly looked like this:

GET /shop/example-product/?add-to-cart=1234
GET /basket/

Sometimes the second request arrived only one or two seconds after the first.

The User-Agent often looked completely ordinary:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/150.0.0.0 Safari/537.36

Blocking that User-Agent would have been a bad security decision.

Chrome 150 is not an identity.

It is just a string.

Then we counted the IP addresses

Across the available logs, we extracted unique IP addresses that used that Chrome/150 signature while requesting add-to-cart.

The result:

8,096 unique IP addresses

This immediately changed the problem.

Traditional per-IP rate limiting or Fail2ban-style blocking could still remove individual offenders, but it was no longer an effective primary defense.

Most addresses appeared only once or twice.

The network was rotating faster than an IP reputation system could meaningfully respond.

ASN sampling also showed significant hosting and proxy infrastructure, including traffic associated with several hosting networks.

But ASN blocking was not the answer either.

The fundamental problem was not:

Which IP is malicious?

The better question was:

Should this request be allowed to perform an expensive state-changing WooCommerce operation?

That distinction became the foundation of the solution.

Known bots were a different problem

Not all of the traffic was pretending to be a browser.

We also observed recognizable crawlers hitting cart operations, including identifiers such as:

SERankingBacklinksBot
MJ12bot
Reflectionbot

Those could be handled through explicit bot detection.

But during testing we discovered another important issue.

Correctly detecting a bot does not help if enforcement happens too late in the WordPress lifecycle.

WooCommerce processes legacy add-to-cart requests during wp_loaded.

Our enforcement path was initially occurring later.

That meant a request could be correctly identified as a bot while WooCommerce had already been given an opportunity to process the cart operation.

The fix was conceptually simple:

add_action(
    'wp_loaded',
    array( __CLASS__, 'observe_request' ),
    1
);

Priority matters.

WooCommerce's cart processing happens later.

Security enforcement must happen before the mutation, not after it.

After correcting the lifecycle ordering, controlled tests produced the expected result:

MJ12bot      -> 403
Reflectionbot -> 403
SERanking    -> 403
Normal browser -> normal WooCommerce flow

That solved recognizable bots.

It did not solve the distributed browser-like traffic.

Why we refused to block Chrome

It was tempting.

The suspicious traffic had a remarkably consistent Chrome/150 signature.

But blocking it globally would have violated one of the basic principles we wanted the system to follow:

A User-Agent is a signal, not authentication.

The same applied to several other tempting rules.

We did not want to block requests merely because they had:

an empty Referer
a particular country
a particular Chrome version
a /basket/ URL
a hosting-provider IP address

Each might be useful as a signal.

None was strong enough to become the security boundary.

Protect the state transition instead

We built a separate WooCommerce protection layer around the legacy GET add-to-cart flow.

The idea is straightforward.

A client should not be able to arrive from nowhere and immediately perform a legacy cart mutation.

A normal storefront visitor first establishes first-party context.

The cart request then carries short-lived proof that this context exists.

The proof is signed using HMAC:

$issued_at = time();
$nonce     = wp_generate_password( 20, false, false );

$payload = 'v1.' . $issued_at . '.' . $nonce;

$signature = hash_hmac(
    'sha256',
    $payload,
    wp_salt( 'auth' )
);

The resulting proof is stored in a secure first-party cookie with properties including:

HttpOnly
Secure
SameSite=Lax

The proof expires after five minutes.

Before WooCommerce processes a legacy add-to-cart operation, the guard verifies the signature and age.

Conceptually:

Legacy ?add-to-cart request
        |
        v
Valid short-lived proof?
      /   \
    no     yes
    |       |
   403      v
        WooCommerce

This does not attempt to determine whether the client is human.

That is an important distinction.

A sufficiently capable automation system can obtain the proof.

The mechanism instead changes the economics and state requirements of the attack while preventing blind, stateless cart mutations.

Page caching introduced another complication

There was a practical WordPress problem.

A heavily cached storefront page may be served without executing the PHP code that would normally issue a proof cookie.

So proof issuance cannot depend solely on uncached page execution.

We exposed a cache-safe proof endpoint:

/wp-json/wccg/v1/proof

A request to that endpoint returns the signed first-party cookie and explicitly disables caching.

Example:

{"issued":true}

The storefront can establish the proof while full-page caching remains enabled.

Again, this is not CAPTCHA.

It is not proof of humanity.

It is proof of state.

Redis gives us the next layer

The store already uses Redis as its WordPress external object cache.

Rather than creating another Redis connection, the protection layer can use the normal WordPress object-cache API.

That gives us inexpensive counters for signals such as:

global cart mutations per minute
requests with valid proof
requests without proof
rejected cart mutations
proof issuance velocity

That becomes useful if the automation adapts.

For example, if the bot eventually learns:

GET /wp-json/wccg/v1/proof
GET /?add-to-cart=1234

then possession of a proof is no longer sufficiently discriminating.

At that point Redis-backed behavioral and velocity signals can become the next layer.

Security controls should evolve with the attacker instead of pretending one rule will remain perfect forever.

But there was another requirement: do not break AI shopping agents

This is where the project became more interesting.

At Zologic, we are also building UCPReady, our WooCommerce implementation of the Universal Commerce Protocol.

The same production store under attack is intentionally exposed to legitimate AI commerce systems.

Its UCP manifest is available at:

/.well-known/ucp

and it exposes agent-commerce transports including:

REST
MCP
Embedded

That means a simplistic security solution could have "fixed" the bot problem by breaking the future commerce infrastructure we actually wanted to preserve.

So the cart protection explicitly exempts the UCP and REST infrastructure.

The result is two separate trust paths.

Legacy browser cart mutation

Browser
   |
   v
first-party proof
   |
   v
legacy ?add-to-cart
   |
   v
WooCommerce

Agentic commerce

AI agent
   |
   v
/.well-known/ucp
   |
   +--> REST
   |
   +--> MCP
   |
   +--> Embedded checkout

They do not need to pretend to be the same thing.

That separation is important.

Independent UCP validation

We did not want to rely only on our own testing.

UCP Checker independently evaluates UCP storefronts and runs live checks against manifests and declared transports.

House of Parfum currently receives:

UCP Status: Verified
Grade: A
Score: 100/100

Agent Discovery:      100
UCP Conformance:      100
Capability Coverage:  100

Transports:
- REST
- MCP
- Embedded

The store is also currently listed among the highest-scoring stores on the UCP Checker leaderboard.

Earlier testing by UCP Checker was particularly valuable to us because their UCP Playground exposed real interoperability problems that controlled development environments had not.

That is exactly what standards-based engineering needs: independent implementations testing each other's assumptions.

Security and agent accessibility are not opposites

There is an emerging mistake I expect many commerce sites to make.

They will see AI bots, scrapers and abusive automation and respond with increasingly broad blocking rules.

Eventually legitimate agents will be blocked too.

The opposite mistake is equally dangerous: exposing everything because "AI agents need access."

The correct model is more nuanced.

An AI crawler fetching public discovery metadata is not the same operation as an anonymous client mutating a shopping cart.

A UCP agent using a defined commerce protocol is not the same thing as a scraper hammering legacy WooCommerce URLs.

Security policy should reflect those differences.

Our architecture now looks roughly like this:

                    Internet
                       |
          +------------+-------------+
          |                          |
   Recognized bots              Commerce clients
          |                          |
          v                          v
    Bot policy layer          +------+------+
                              |             |
                         Legacy Web       UCP/API
                              |             |
                              v             v
                       Cart proof       Protocol
                         guard           endpoints
                              |             |
                         WooCommerce <------+

Different clients.

Different capabilities.

Different trust boundaries.

The production result

After enforcement became active, we measured the real traffic again.

For the post-enforcement sample:

All add-to-cart requests: 36

403 blocked: 35
302 allowed: 1

Then we isolated the distributed Chrome/150 pattern:

Chrome/150 add-to-cart requests: 30

403: 30
302: 0

30 out of 30 were rejected.

The rotating IP addresses continued.

The User-Agent continued.

The requests continued.

But changing IP addresses no longer helped because IP identity was no longer the security boundary.

At the same time, we verified that legitimate UCP infrastructure remained online:

200 /.well-known/ucp

200 /wp-json/ucpready/v1/openapi.json

200 /wp-json/ucpready/v1/mcp-tools.json

That was the outcome we wanted.

Not:

Block more bots.

But:

Stop unauthorized state mutation while preserving legitimate machine commerce.

The lesson

The most useful lesson from this incident was not a particular WordPress hook or HMAC function.

It was changing the question.

When an attacker can rotate through thousands of addresses, asking:

Is this IP a bot?

has diminishing value.

Instead ask:

Has this client established the state and authority required to perform this operation?

That principle extends well beyond WooCommerce.

Protect the operation.

Define the trust boundary.

Make expensive state transitions require context.

Keep machine-readable public interfaces intentionally accessible.

And treat legitimate agents as first-class clients instead of forcing them to masquerade as browsers.

Having the same WooCommerce problem?

We are continuing to develop these ideas at Zologic, including WooCommerce bot protection, agent-aware access controls, UCPReady, MCP/REST commerce integrations, and security architectures that distinguish legitimate AI agents from abusive automation.

If your WooCommerce store is dealing with:

distributed add-to-cart abuse
rotating proxy traffic
cart/session exhaustion
bots that evade per-IP rate limits
AI crawler access conflicts
UCP implementation
MCP commerce integration
securing WooCommerce without blocking legitimate AI agents

we are interested in looking at the problem.

The solution should not be another giant IP blacklist.

It should fit the way your store actually works.

If you're seeing similar traffic, contact Zologic and send us a sample of the pattern you're dealing with. We can help investigate it and design the appropriate protection or agent-commerce integration.

This article describes a real production incident. IP addresses and infrastructure observations are treated as network evidence only; they do not establish the identity or intent of the underlying operator.

The Field Every WooCommerce PII Guard Misses: meta_data

Almin Zolotic — Mon, 07 Sep 2026 21:26:41 +0000

Every WooCommerce MCP server I looked at protects one thing well: the log file. Almost none of them inspect the payload actually crossing the wire to the model.

That distinction sounds small until you look at what's sitting inside a real order object.

The field that breaks field-level thinking

WooCommerce lets any plugin write arbitrary key/value pairs into meta_data. That's the whole point of it — it's the extension point every third-party plugin uses. It's also the field no permission system or allowlist can reason about, because the same field holds things like this in the same order, side by side:

"meta_data": [
  { "key": "warehouse_reference", "value": "WC-ZG-2026-008192" },
  { "key": "delivery_instruction", "value": "Call customer at +385..." }
]

Both are meta_data. Both pass any check that authorizes the field. One is a warehouse reference your fulfillment team needs to see. The other is a phone number that shouldn't leave the store. A tool-permission system can authorize the order operation. A field allowlist can permit meta_data. Neither one knows what's actually sitting inside that string, because neither one looks.

That's the gap I built Privacy Guard to close, and it's worth being precise about what "closing it" actually means, because the temptation with anything PII-related is to oversell.

What already exists, and where it stops

I'm not the first person to think about PII near an MCP server, and WooCommerce PII redaction isn't a new idea either. WooCommerce's own MCP plugin redacts PII by default — emails, addresses, phone numbers get masked before anything is written to a log. Several community WooCommerce MCP servers take a different approach and just don't expose customer or order PII at all, advertising themselves as "read-only and safe." AbilityGuard, a general WordPress Abilities monitor, leaves output logging off by default specifically because ability responses might contain sensitive data.

Notice the pattern. Every one of those protects the log, or avoids the field entirely. None of them look at the value crossing the boundary and make a decision about that specific value. That's true outside WordPress too — even general-purpose MCP gateway middleware I checked runs PII filtering request-side only, with response-side scanning explicitly flagged as unfinished work.

So the honest claim isn't "nobody has thought about this." It's narrower and stronger: existing controls are aimed at logs, credentials, and tool authorization. Almost nothing is aimed at the live MCP payload itself, at the field level, including inside a container field like meta_data where the key tells you nothing about what's inside the value.

Block before execution, minimize before response

The architecture is bidirectional, not a single sanitize-on-the-way-out step:

AI
 ↓
MCP request
 ↓
PII policy   ← block unexpected sensitive input before the Ability runs
 ↓
Ability execution
 ↓
PII policy   ← redact / tokenize / omit sensitive output
 ↓
MCP response
 ↓
AI

The pre-execution half matters as much as the post-execution half. An Ability the guard doesn't recognize doesn't get a default-allow — it fails closed. That's a stronger guarantee than cleaning the response after the fact, because a sensitive value that never reaches execution can't leak through some code path the redaction step forgot to check.

Three states, not two

The part I had to get right — and the part I'd get called out on if I got it wrong — is what "pass" actually means. It would be easy to write "detected → block, otherwise → safe" and call it done. That's also a false promise, because no detector, mine or anyone else's, can prove a string contains no PII. It can only fail to find any.

So there are three states:

Detected sensitive             → enforce the configured action
Not permitted by policy        → deny
Permitted + no detector match  → pass

The third state is not a safety certification. It means there's currently no policy or detector basis to stop the value — not that the value is verified clean. Anyone selling the opposite promise is selling something they can't actually back.

What "measure it" looks like in practice

Talk about detector quality is cheap. I built a WooCommerce-shaped corpus instead — realistic sanitized orders, customers, products, mixed sensitive and benign values inside the same meta_data structures — and measured it as true positives, false positives, false negatives, true negatives, not pass/fail:

WOOCOMMERCE_CORPUS  TP=8  FP=0  FN=0  TN=23

Small baseline, not a claim that WooCommerce PII is a solved problem. But it's a number, and it's checkable, which is more than most "we redact PII" claims in this space offer.

The part that doesn't go stale

Detectors improve. Better phone-number patterns, more identifier formats, maybe a classifier layered on top of the regex later — none of that changes what the product actually is. The enforcement seam is the architecture: a WordPress-native boundary sitting inside the MCP Ability lifecycle, blocking before execution and minimizing before response. The detector is a versioned evidence engine feeding decisions into that seam. You can replace the evidence without replacing the product.

If you're running WooCommerce data through any MCP client right now, the question worth asking isn't whether your logs are redacted. It's whether anything is looking at the actual value in meta_data before it leaves your store.

I build WordPress/WooCommerce infrastructure for agentic commerce at Zologic. If you're running an MCP client against live WooCommerce data and want this enforced rather than assumed, reach out: Almin Zolotic on LinkedIn.

Further reading

MCP for WooCommerce Documentation — official PII redaction in action logs
AbilityGuard – Abilities API Monitor — output logging disabled by default due to sensitive data risk
mcp-for-woocommerce — community MCP server taking the "no PII exposed" approach

The Inventory Bug Hiding in Every AI-Facing Store (And in Every LLM)

Almin Zolotic — Tue, 14 Jul 2026 18:38:22 +0000

At Zologic we build UCPReady, the WooCommerce implementation of the Universal Commerce Protocol. It's the infrastructure that lets AI agents like Claude, Gemini, and ChatGPT discover, search, and check out on a WooCommerce store autonomously. Most of what we write about is protocol compliance, checkout funnels, agent behavior. This one's different. It's about a bug we found in a customer's store that has nothing to do with AI agents on the surface, and everything to do with them underneath.

The incident

One of our customers runs a fragrance dropshipping store with a catalog north of 53,000 SKUs, synced nightly from a wholesale supplier's API. Standard architecture: pull the vendor feed, match by SKU, update price and stock.

One night, a customer ordered a product. The order came through, payment cleared, and the product didn't exist anymore. Not out of stock. Deleted upstream. The wholesaler had quietly removed the SKU weeks earlier after it sat unsold for over a month. The store's sync script had no way of knowing, because it was never built to ask.

Why this matters more than it looks

Here's the part that made us stop and think harder than a routine sync bug usually warrants: at 53,000+ SKUs, a store like this isn't just serving human shoppers anymore. It's a surface AI agents crawl, index, and reason over, through UCP manifests, MCP tool calls, product schemas. When an agent (or a human, for that matter) asks "is this in stock," the honest answer your system should be able to give is "as of the last time I confirmed it." Most systems don't track that distinction. They track "the last value I stored," full stop.

That's the bug. Not a missing if statement. A wrong mental model. The store's database wasn't holding "the inventory." It was holding a cached copy of what the vendor said, last time anyone asked. And a cache with no expiry policy isn't a cache. It's a slowly rotting assumption.

What we found once we fixed it

We rebuilt the sync to track presence, not just values: every SKU the vendor's feed actually returns gets marked as reconfirmed this run. Anything previously published that's absent from a full feed read gets quarantined, not deleted, just pulled from the storefront, ready to snap back the instant the vendor restocks it.

Running it for the first time against a catalog that had never had this check before surfaced the scale of the accumulated drift:

~2,700 products (over 11% of the published catalog) had been silently stale, some for months
151 new products picked up automatically in the same pass
Total catalog stock units moved from 921,786 to 955,594 in a single sync: a +33,808 unit correction
Published stock alone: 676,169 → 698,153 (+21,984 units)
Draft-side stock: 245,617 → 257,441 (+11,824 units) That's not a rounding error. That's tens of thousands of stock units that were wrong, on a store an AI shopping agent could have been confidently quoting availability from, minutes before check-in.

The paradigm shift

Physical inventory feels like it should be a stable, durable fact. A bottle either exists in a warehouse or it doesn't. But from your system's point of view, that's never something you observe directly. It's an inference from the last API response you got, and every inference like that has a shelf life whether you model it or not.

Anything your system ingests from an external source is perishable by default. Freshness has to be actively reconfirmed, never assumed from silence. "The feed didn't mention it" and "the feed confirmed it's fine" have to be different states in your data model. Collapsing them into one is exactly the bug we found.

Where this converges with everything else we build

This is the same failure shape we deal with constantly on the UCP side. An AI agent operating on stale product data doesn't just annoy a customer. It makes a purchase decision, or tells a shopper a store carries something it doesn't, based on a snapshot nobody re-verified. Multiply that by every WooCommerce store that gets discovered and transacted with autonomously, and "is this data still true, or just still there" stops being a backend nitpick and becomes a trust question for the entire agentic commerce stack.

And if you work with LLMs directly, you already know this pattern under a different name. A model's training data is a frozen snapshot. "Who's the CEO," "does this product line still exist," "is this API still current" all fail the exact same way our customer's SKU did: not because the model is wrong, but because nothing tells it its answer has gone stale. That's why retrieval and web search exist. They reintroduce the "did I just reconfirm this" check that a frozen snapshot structurally can't perform on its own. Even RAG can quietly reintroduce the bug at a smaller scale: an indexed-once, never-recrawled document lets "it's in my vector store" stand in for "it's true," when it only ever meant "it was true whenever I last indexed it."

Same fix, every time: track last confirmed, not just last known.

Takeaway

If your store, or your product, or your model, holds any data it didn't generate itself, ask the unglamorous question up front: what tells you an entry has gone stale, and is "I haven't seen an update" quietly standing in for "confirmed still valid"? At 53,000 SKUs, that gap was worth tens of thousands of stock units and a very real risk of selling something that doesn't exist. At agent scale, it's worse. It's a trust failure nobody notices until an autonomous checkout completes on a product that isn't there.

Perishable by default. Freshness earned, not assumed. That's the standard we're building UCPReady to hold stores to as AI agents become a bigger share of who's actually reading your catalog.

The Missing Middleware for Autonomous Agents

Almin Zolotic — Sun, 05 Jul 2026 13:43:19 +0000

How frontier models turned privacy from an application concern into an infrastructure problem

Frontier models faithfully execute instructions. They also faithfully move data across system boundaries. That changes privacy from an application concern into an infrastructure concern — and most agent architectures have not caught up.

The problem isn't that models misbehave. The problem is that they behave exactly as instructed, which means every piece of data in the context window is a candidate for transmission to the next tool call. In banking, healthcare, legal, HR, and insurance systems, that is not a theoretical risk. It is a structural property of how agents work.

This post identifies where the risk actually occurs, explains why better models make it worse, and describes the middleware layer that has to exist between the agent and every tool it calls.

Travel booking is the domain we implemented first. The architecture applies everywhere.

Better Models, Bigger Problem

Everyone assumes more capable models reduce risk. The opposite is true for data handling.

GPT-3.5 accidentally protected some secrets because it was inconsistent. It would drop fields, misread nested structures, and fail to extract values cleanly. That unreliability was not a feature, but it occasionally functioned like one.

Frontier models have eliminated that accident. GPT-4o, Claude Sonnet, and Gemini 1.5 Pro will faithfully extract a passport number from a 3,000-token profile and pass it directly to a seat selection tool that has no use for it. They do this because the data is present and the instruction says "book the flight." The model is not doing anything wrong. That is the problem.

There are three failure modes, and all three require the model to be working correctly:

Over-sharing on tool input. An agent receives a full traveler profile to perform a search. The profile contains a passport number. The search tool does not need it. The model passes the whole profile because it was told to call the tool with the traveler's details, and the whole profile is the traveler's details. The passport number now appears in the tool's request log.

Credential leakage in context. A tool returns an API response that includes a session token or an authorization header in the body. The model incorporates it into its context. In subsequent tool calls, the model may reference or repeat that token. This is not a hallucination failure. It is a faithful reproduction failure.

PII in structured outputs. The booking confirmation tool returns a full object containing every passenger detail, payment method, and contact. The agent summarizes it for the user, but the full object is in the context window. If that context is logged, the log contains structured PII at booking confirmation density.

None of these require a malicious actor. They require normal model behavior operating on data that should have been scoped before the model saw it.

The Architecture Gap

Traditional systems have a well-understood control plane:

Application
    ↓
API Gateway
    ↓
Service

The gateway handles authentication, rate limiting, and policy enforcement. It is not optional. No one ships a production service by having the application call downstream services directly.

Agentic systems have reproduced the application layer and the service layer but skipped the control plane:

Agent
    ↓
[nothing]
    ↓
Tool Runtime
    ↓
Provider

The agent calls tools directly. Every tool call is a direct transmission of whatever the agent has in context, including data the tool was never intended to receive. The tool returns whatever the provider returns, including data the agent was never intended to see.

The missing layer is a privacy guard that sits at the tool boundary and enforces policy in both directions:

Agent
    ↓
Privacy Guard
    ↓
Tool Runtime
    ↓
Provider

This is the same architectural pattern as an Envoy proxy or an API gateway. The implementation is different because the data is structured JSON rather than HTTP traffic, and the policy is semantic rather than header-based. The structural role is identical: a mandatory chokepoint where policy is enforced before data crosses a boundary.

What the Guard Actually Does

The guard intercepts every tool call in both directions and applies four operations:

Scans the payload for known PII and secret patterns using deterministic detection: field name matching, regex patterns with validation (Luhn for card numbers, format validation for structured types), and domain-specific rules (booking references, passenger name records, loyalty identifiers in travel; account numbers and routing codes in banking; NPI numbers and diagnosis codes in healthcare).

Decides based on configurable policy: allow the data through, redact it with a placeholder, replace it with a deterministic cryptographic token, or block the call entirely. The policy is per-kind and per-severity. Secrets are blocked. High-severity PII is tokenized. Standard PII is redacted.

Audits every inspection, input and output, with a trace ID that correlates the two events. The audit event records what was found and what action was taken, without including the sensitive values or the paths to redacted fields.

Enforces by surfacing violations as structured errors the agent runtime can handle, rather than exceptions that crash the call.

The Implementation

We built this as a dependency-free Node.js package integrated at the invokeTool() boundary in the MCP runtime. One instance at startup, shared across all tool calls:

import { createPrivacyGuard } from "@ucp-travel/mcp-privacy-guard";
import { travelDetectors } from "@ucp-travel/mcp-privacy-guard/travel";

const guard = createPrivacyGuard({
  detectors: travelDetectors,
  policy: {
    tokenizeKey: config.privacyTokenizeKey,
    rules: [
      { match: { kind: "secret" },               action: "block"    },
      { match: { kind: "pii", severity: "high" }, action: "tokenize" },
      { match: { kind: "pii" },                  action: "redact"   }
    ]
  },
  audit: async (event) => logger.privacy(event)
});

Every tool invocation passes through the guard twice:

export async function invokeTool(runtime, toolName, payload, options = {}) {
  const requestId = options.requestId || randomUUID();

  // Sanitize before the tool sees the payload
  const safePayload = await runGuard(
    runtime.guard, payload, "input", toolName, requestId, tenantId
  );

  // Execute the tool on the sanitized payload
  const result = await dispatchToolCall(toolName, safePayload, context);

  // Sanitize the response before the agent sees it
  return runGuard(
    runtime.guard, result, "output", toolName, requestId, tenantId
  );
}

The input guard runs before the tool handler receives the payload. The output guard runs before the response reaches the agent's context. Neither the tool nor the agent is modified.

Per-Tool Output Allowlists

Not all PII in a tool response is a problem. A booking confirmation is supposed to contain the passenger name and contact email. Redacting them breaks the confirmation flow.

The solution is per-tool output allowlists that specify which paths are permitted through unredacted:

const OUTPUT_ALLOWLIST_BY_TOOL = {
  [MCP_TOOLS.COMPLETE_CHECKOUT]: [
    "$.booking.id",
    "$.booking.passengers[*].given_name",
    "$.booking.passengers[*].family_name",
    "$.booking.contact.email"
  ],
  [MCP_TOOLS.GET_BOOKING]: [
    "$.booking.id",
    "$.booking.passengers[*].given_name",
    "$.booking.passengers[*].family_name",
    "$.booking.contact.email",
    "$.booking.contact.phone_number"
  ]
};

Everything not on the allowlist for that tool is redacted or tokenized according to the global policy. The search tool never returns PII even if the provider response includes it. The confirmation tool returns exactly the fields the agent needs.

The same pattern applies in other domains. A banking agent's account lookup tool might allowlist account nickname and last-four digits. A healthcare agent's appointment tool might allowlist appointment time and provider name. The policy is domain-specific; the mechanism is not.

Tokenization and Key Rotation

For high-severity PII, redaction is not enough. You lose the ability to correlate data across audit events. Tokenization replaces the value with a deterministic HMAC-based token tied to a key ID:

{ "email": "TOKEN:pii/2026-q3:a3f8c2..." }

The token is deterministic: the same input and key produce the same token, so you can correlate across audit events without storing the original value. The key ID is logged in every event that produces or reads a token. When you rotate keys quarterly, old tokens are not orphaned; you know exactly which key was active when they were created.

Rotation is a two-line environment change. The guard adds under 50ms to any call on payloads below the 200 KB size limit.

The Open Question

Tokenization solves the audit correlation problem. It does not solve the agent reasoning problem.

When the agent receives TOKEN:pii/2026-q3:a3f8c2... in place of an email address, it cannot send a confirmation to that address. If the agent needs to act on a value rather than acknowledge it, tokenization breaks the flow.

The current design handles this by allowlisting output paths the agent needs to surface to the user. It does not handle the case where the agent needs to use a value internally across multiple tool calls without seeing the raw value.

That is a harder problem. Reversible tokenization with a delegated decryption endpoint is one approach. Restricting which tools can receive which token kinds is another. Neither is fully satisfying. We have not solved it yet.

Most engineering articles end by claiming the problem is solved. This one does not, because it is not. The missing middleware layer exists and is deployable today. The question of how an agent reasons about data it has never seen in plaintext is still open, and the answer will shape how agentic systems handle regulated data at scale.

Almin Zolotic is the founder of Zologic and the author of the ucp.travel autonomous booking infrastructure. The architecture described in this article — bidirectional privacy enforcement at the MCP tool invocation boundary, with per-tool allowlists, deterministic tokenization, and domain-specific detection — was developed as part of the ucp.travel infrastructure and is documented here as a reusable pattern for agentic systems handling regulated data.

ucp.travel is autonomous travel booking infrastructure for operators who want to remove the human agent from the booking loop without losing the compliance properties the human agent currently provides.

The Missing Layer in Agentic Travel: Why "The AI Can Book It Now" Isn't the Hard Part

Almin Zolotic — Thu, 18 Jun 2026 16:01:34 +0000

Something real shifted in commerce this year, and most of the commentary around it is focused on the wrong question.

Visa recently announced a strategic collaboration with OpenAI to bring secure, identity-verified payments directly into AI-driven shopping experiences. Major payment networks don't make moves like that on a hunch — they make them when a category has crossed from experimental into something worth building real infrastructure around. Agentic commerce, the idea that an AI assistant can discover, decide, and complete a purchase on someone's behalf, is no longer a thought experiment. It's a deployment target.

The industry conversation around this, though, keeps collapsing into one narrow question: can an AI agent successfully place an order? Increasingly, yes. New protocols for letting agents discover merchants and call their tools are maturing quickly, and "the agent created a cart and checked out" demos are everywhere.

That's the easy 80%. Travel is where the other 20% lives, and it's the part nobody's marketing slide wants to talk about.

Why travel breaks the standard playbook

Most agentic commerce infrastructure today assumes something travel doesn't have: a stable product. A SKU with a fixed price sitting in a catalog, waiting to be added to a cart. That model works beautifully for a t-shirt. It falls apart the moment the "product" is a seat on a specific flight that a human or an agent took eleven minutes to decide on.

A flight offer isn't a fact. It's a perishable claim with a clock attached. The price quoted at the moment of search can be different by the time checkout happens. The seat itself can simply not be there anymore. None of that is a bug in any individual system — it's how airline inventory has always worked, long before any of this involved an AI. The gap is that most of the emerging agent-commerce tooling was designed around retail's assumptions, not travel's, and there's an open, active conversation in the standards community right now about exactly this: contributors building merchant-facing protocols for AI agents have publicly flagged that the lack of a way to signal "this offer is only valid for the next N minutes" is one of the main reasons the leading agentic commerce standard isn't yet considered production-ready for travel specifically.

That's not a criticism of the standard. It's a fair description of how hard the problem actually is. Perishability is travel's defining trait, and almost nothing in the current agent-commerce stack was built with it in mind.

The part that actually matters: agents aren't naturally careful

Here's the thing that surprised us most while building toward this, and it's the part worth other teams hearing before they find out the hard way.

It is tempting to assume that a sufficiently capable AI model will just behave responsibly. It'll notice when an offer is about to expire. It'll flag a price that crept up between search and purchase. It'll hesitate before re-booking something that already exists. In practice, none of that can be assumed, and assuming it is where the real risk lives.

A language model calling a booking tool is making its best judgment call in the moment, based on whatever it's been told and whatever data happens to be in front of it. That's genuinely useful, and modern models are good at it. But "the model usually behaves well" is a completely different claim from "the system cannot be made to overspend, double-book, or silently swap one set of terms for another." The first is a tendency. The second is a guarantee. Only one of those is something you can actually stand behind when real money and a real traveler's itinerary are on the line.

The practical implication is that every meaningful safety property — a hard budget ceiling, a cabin-class policy, a rule that a flight has to be direct, a requirement that any meaningful airline-initiated schedule change gets a human's eyes on it before anything happens automatically — has to be enforced by the platform sitting between the agent and the booking, not hoped for from whichever model happens to be making the call that day. The agent should be free to reason, suggest, and act quickly. The guardrails need to exist completely independently of whether it chooses to respect them.

What "safe" actually requires, in plain terms

Once you take that seriously, the requirements stop being abstract and become very concrete.

Every offer needs an honest expiry, enforced server-side, not just displayed as a courtesy. A price has to be reconfirmed immediately before money moves, not assumed stable from however many minutes earlier it was first quoted. Spending limits, cabin policy, and routing preferences need to be checked against the actual final terms of a booking, not just the terms that looked fine at the moment of search. A booking attempt that looks like a duplicate of something already purchased needs to be caught before a second charge happens, not after. And critically: anything an airline changes after the fact — a schedule shift, a downgraded itinerary — has to surface to an actual human decision, because that's exactly the kind of judgment call that shouldn't be delegated to an agent acting alone, no matter how capable it is.

None of this is exotic engineering. It's the unglamorous, table-stakes work of building a transactional system that's actually trustworthy, applied to a domain — travel — where the standard agentic commerce tooling hasn't fully caught up yet. Every one of these properties has to be proven, not assumed. The honest way to know a guardrail works is to actively try to break it, watch it hold, and keep a permanent record that it did.

Where this is heading

The standards layer for agentic commerce is moving fast, and that's a good thing — a shared, open way for agents to discover and transact with any business, regardless of platform, is genuinely valuable infrastructure for the whole industry. Large travel technology players are already shipping their own agent-facing interfaces, and that's a healthy sign the category is real, not speculative.

What's still missing, broadly, is the execution layer underneath travel specifically: the part that takes "an agent can call a booking tool" and turns it into "an agent can be trusted to book within real constraints, with a permanent, auditable record of exactly what it was and wasn't allowed to do." That's the layer we've been building at Zologic, under the name ucp.travel — not a replacement for the emerging standards, but the travel-specific safety and policy infrastructure that sits on top of them, so that the convenience of "just ask the AI to book it" doesn't come at the cost of the control any business or traveler would reasonably expect to keep.

The easy part of agentic commerce is already here. The trustworthy part is what's actually being built right now — and travel, with its perishable inventory and real financial stakes, is as good a proving ground for that as any.

We're building ucp.travel, the policy and safety execution layer for autonomous travel booking. If you're thinking about similar problems in agentic commerce — perishable inventory, mandate-based spending controls, audit trails for autonomous transactions — we'd like to hear from you, and you're welcome to try ucp.travel directly at ucp.travel.

From Booking to Beyond: Making Autonomous Travel Servicing Work in Practice

Almin Zolotic — Tue, 09 Jun 2026 22:10:28 +0000

This is part of an ongoing series on building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Built by Almin Zolotic at Zologic.

Last time I wrote about getting an AI agent to autonomously book a flight: search, revalidate, pay, confirm. That was the exciting part.

This week was the less glamorous, but arguably more important, part: what happens after the booking.

Anyone who has built anything in travel knows the booking is only the beginning. The real complexity shows up afterward. The traveler wants to change their flight. The airline changes it for them. The traveler wants to cancel. Dates shift, prices reprice, confirmation windows expire. A real travel platform has to handle all of this without falling apart — and without making the traveler feel like they are operating blind.

That is what we spent the week building.

The three moments that matter after a booking

There are really three post-booking scenarios that define whether a travel platform feels like a product or a prototype.

Voluntary cancellation — the traveler decides to cancel and needs to understand the consequence before committing.

Airline-initiated change — the carrier reschedules or changes the trip, and the platform has to reflect that clearly instead of pretending the booking is still unchanged.

Voluntary change — the traveler wants a different flight, and the system has to guide them through a preview, a confirmation step, and any additional payment required, without ambiguity about what is final and what is not.

All three are multi-step flows. None should happen in a single call. And none should complete without the traveler knowing exactly what they are confirming.

Making irreversible actions feel safe

The principle we kept coming back to was simple: anything irreversible should be preceded by a preview.

The traveler should see what will happen, have a chance to pause, and only then confirm. If the preview expires before they act, the system should catch that and ask them to start again — rather than proceeding with stale information.

That sounds obvious, but implementing it correctly takes real discipline. There are a surprising number of places where a system can skip the preview, auto-confirm, or fail to communicate that a confirmation window has closed. We closed those gaps so a preview can never be skipped and a stale confirmation can never slip through.

The same principle applies to how the system talks about fare conditions. A fare being labelled refundable is a policy statement — not a guarantee that the system can execute a refund right now. We changed the platform to check live booking state before promising that change or cancellation is available. If a booking cannot be serviced through the current interface, the traveler now hears that clearly instead of getting a confusing error after the fact.

Airline-initiated changes were the hardest part

The scenario that took the most care was airline-initiated change.

When an airline changes a trip, the platform receives an event and has to decide what to do. The wrong answer is to handle it silently. Airline changes can involve new flight times, a different aircraft, or sometimes different routing — none of which the traveler has agreed to.

The right answer is to surface the change clearly, show what was originally booked versus what is now being proposed, and ask the traveler to review before anything is accepted or rejected.

We built that escalation path properly, made sure the platform re-fetches fresh booking state before presenting the change, and validated the full flow end to end against real provider behavior.

Honest language matters too

One smaller change that mattered a lot was how cancellations are communicated.

In many travel products, cancellation language quietly implies the traveler will simply get money back the moment they cancel. That's not always accurate, and saying it anyway is the kind of small dishonesty that erodes trust the first time someone notices the gap.

So the platform now communicates cancellation in terms of what's actually true: the booking is cancelled, and the traveler is told plainly what happens next with any refund or credit, rather than a vague promise that may not match reality.

Small wording change. Matters a lot for trust.

How we know it actually works

The thing I am most satisfied with this week is not just the feature list.

It is that we did not stop at "it works locally."

We exercised the full booking lifecycle — booking, changing, cancelling, and handling airline-driven changes — against live provider responses, step by step, until we had confirmed outcomes for every scenario.

That shifted the project from "we think this works" to "we know these core flows work."

There is a meaningful difference between code that looks correct and a system that has been proven to behave correctly under real conditions. This week we crossed that line for the servicing layer.

What is next

The immediate next track is operator tooling: giving the people running travel programs visibility into their bookings and the ability to manage their travelers with confidence.

The AI agent layer is now in a healthy place.

Now the work is turning that foundation into a full product for the humans operating on top of it.

More soon.

Almin Zolotic is the founder of Zologic and building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Follow the build here on dev.to.

We Just Completed a Live AI-Agent Flight Booking End to End

Almin Zolotic — Mon, 01 Jun 2026 14:25:44 +0000

An AI agent received a natural language instruction, searched for flights, selected an offer, passed authorization checks, and created a confirmed booking — autonomously, without human input after initial setup.

Today that went from architecture spec to production reality.

What actually happened

At 15:33 CET, on UCPPlayground, we ran the following prompt against our live stack:

"Use search_flights for ZAG to AMS tomorrow. Then immediately call complete_checkout on the first direct offer. Do not explain first."

Two tool calls. Eight seconds.

The agent searched. The agent booked. A confirmed booking reference came back. We opened the travel provider dashboard and the order was sitting there — confirmed, with a PNR, an e-ticket, passenger details, everything.

No human touched the booking flow after the initial traveler setup.

Why this is harder than it sounds

Anyone can wrap a travel search API in an MCP tool and call it "AI travel booking." That part is easy.

The hard part is everything that happens between search and confirmed booking:

Offers expire. Flight fares are perishable inventory. An offer returned from search may be gone in 15–30 minutes. No LLM checks this unprompted — it will try to book an expired offer and get a rejection it doesn't know how to recover from.

Prices change silently. A fare can reprice between the moment the agent sees it and the moment it tries to book. Without a revalidation gate, the agent books at the new price without telling anyone.

Bookings can partially confirm. A travel provider can return an async response — booking accepted, outcome pending. An agent that doesn't understand this state will retry, and retrying a booking call risks a double charge.

Identity and authorization matter. Who is this booking for? What are they allowed to spend? What cabin class? Are they direct-only? Without a mandate layer, an agent has no constraints. It will spend whatever inventory is available.

Document requirements gate certain routes. Some routes require passport details to be validated before an order is created. An agent that doesn't check this wastes a booking attempt and confuses the traveler.

These aren't edge cases. Every one of them will happen in production. None of them are solved by the travel API or the LLM — they have to be solved by the layer in between.

That's what we built.

The stack

We built UCP Travel — a travel transaction layer that sits between AI agents and travel inventory.

It implements:

UCP (Universal Commerce Protocol) — the open standard for agentic commerce, including the full checkout lifecycle
MCP (Model Context Protocol) — so any MCP-compatible agent can discover and call our tools
AP2 (Agent Payments Protocol) — cryptographically signed traveler mandates that enforce spending limits, cabin class ceilings, and booking constraints before any transaction The traveler sets up once: connects their AI assistant via OAuth, signs a mandate defining their booking constraints, stores their travel preferences. After that, every booking is autonomous within those constraints.

Our capability declarations are public at ucp.travel/.well-known/ucp and verified by UCPChecker — currently the only verified implementation of travel.ucp.mandate in the world.

UCPPlayground now recognizes ucp.travel as the reference pattern for travel-as-shopping — the travel.ucp.* namespace layered over dev.ucp.shopping is the model the ecosystem is converging on.

The UCPPlayground integration

The booking today happened through UCPPlayground — a live testing environment for the UCP ecosystem built by Ben Fisher. It connects real AI models to real UCP endpoints and runs end-to-end agent sessions.

Gemini 2.5 Flash connected to our MCP endpoint, discovered three tools (search_flights, complete_checkout, get_booking), and completed the booking in 3 turns:

Turn 1: search_flights(origin: ZAG, destination: AMS, departure_date: 2026-06-02, max_connections: 0)
Turn 2: complete_checkout(offer_id: off_..., checkout_id: chk_live_1)
Turn 3: [confirmed — PNR returned]

Outcome: purchase_completed. PNR confirmed in the provider dashboard.

What "traveler setup once" actually means

The autonomous booking only works because we solved the identity problem first.

During onboarding, a traveler:

Creates a profile with travel documents and preferences
Signs an AP2 Intent Mandate — their authorized booking constraints, cryptographically signed
Links their AI assistant via OAuth 2.0 Authorization Code flow From that point, every MCP tool call the agent makes carries a bearer token that resolves server-side to the traveler's identity, mandate, and payment profile. The agent never sees raw credentials, card numbers, or passport data. It just calls tools and gets results.

This is the architecture that makes autonomous booking trustworthy — not just technically possible.

What's live now

The multi-tenant operator platform is running. Operators onboard, configure traveler mandates, and connect AI assistants today. Flight booking is live.

Expanding next:

Stay (hotel) booking alongside flights
Post-booking servicing — changes, cancellations, ancillaries
Complete audit trail UI for operators and compliance teams If you're building an AI travel assistant, a travel management platform, or anything that needs to turn travel intent into confirmed bookings — we'd like to talk.

ucp.travel · contact@zologic.nl

Built by Zologic — zologic.nl

UCP spec: ucp.dev · MCP spec: modelcontextprotocol.io · AP2: ap2-protocol.org

30 Days of AI Agents Buying From a Real WooCommerce Store. Here's What the Data Says.

Almin Zolotic — Tue, 26 May 2026 15:32:55 +0000

Last week @benjifisher published a sharp piece on agentic commerce's messy middle — the trust, verification, and liability layer between "found it" and "bought it." His conclusion: the middle is mostly unbuilt.

We have 30 days of production data that says otherwise. Not a demo. Not a sandbox. A live Dutch perfume store with 40,000 SKUs, real pricing, real tax, real wallet debits. Here is what actually happened.

The numbers

€1,269 in AI-driven revenue — last 30 days
39 completed orders via AI agents
€32.54 average order value per AI transaction
76.5% session conversion — 39 of 51 agent sessions resulted in a completed order
1.5 average calls per session — the spec benchmark is 4 (list → create → update → complete)

That last number is the one I want to focus on.

1.5 calls per session means agents are skipping steps

The UCP spec optimised benchmark is 4 tool calls for a complete purchase: list products, create checkout, update checkout, complete checkout. Our agents are averaging 1.5.

That is not agents failing — it is agents that have already done discovery in a prior session arriving with intent and going straight to checkout. The /agents.md instruction layer we shipped two weeks ago is working: agents are reading the operating manual on first visit and not re-reading it on every subsequent transaction.

The messy middle does not look messy when the protocol is clean and the instructions are explicit.

Who is actually buying

Eight distinct agents hit the store in 30 days. Here is what the agent table shows:

Agent	Sessions	Avg Calls	Status
UCP Directory Verifier	19	1	Discovery only
Unknown Agent	13	2.2	Transacting efficiently
UCP Checker	8	1.4	Validation + light transacting
UCPReady MCP	5	1.2	Internal testing
UCP Playground	2	5	+1 above benchmark
Claude	2	1	Clean
Ucptools.dev	1	2	At target
Generic Bot	1	1	At target

The most interesting row is Unknown Agent — 13 sessions, 2.2 avg calls, at or below target. An agent we cannot identify by name is transacting against the store efficiently and repeatedly. It found the /.well-known/ucp manifest, parsed the capability declarations, and is completing purchases without any integration work on our side.

That is the protocol working exactly as designed.

UCP Playground is the only agent above benchmark at 5 calls — that is Ben's testing environment running full end-to-end validation sessions including the identity linking flow. Expected noise, not a problem.

What the messy middle actually looked like

Building to this point was not clean. The first fully autonomous purchase — WooCommerce order #82251 on March 25 — took 24 hours of debugging across two people. The failures were specific:

Idempotency key formatting. Claude kept sending meta as a stringified JSON object instead of a proper nested object. Fixed at the orchestrator level by auto-injecting the key shape.

Wallet instrument ID vs handler name. The store's validator accepted com.terrawallet.store_credit (the handler name) but rejected terrawallet-1 (the instrument ID). Two different identifiers, one lookup path, one silent failure mode.

Stale OAuth sessions. Merchant-side token revocation was not being detected. Agents were holding expired Bearer tokens and getting 401s with no clear recovery path. Fixed by adding token validation on connect and auto-clearing on 401.

MCP endpoint override. Our Shopify storefront probe was overriding the manifest endpoint. OAuth tokens were stored against /api/mcp but MCP calls were going to /wp-json/ucpready/v1/mcp. One endpoint mismatch, zero successful completions until found.

Each of these was a real failure that blocked real purchases. The protocol did not hide them — the session data captured every one. Observability is what made them fixable.

What 76.5% conversion means in context

Human checkout conversion on e-commerce averages 2-4%. Mobile is lower. Even high-performing stores rarely exceed 5% on cold traffic.

76.5% is not comparable to human checkout conversion — agent sessions are intentional by definition, not browsing. But it does tell you something about friction. An agent that reaches create_checkout on a well-implemented UCP endpoint completes the purchase 76.5% of the time. The failures are mostly discovery sessions (UCP Directory Verifier, UCP Checker) that never intended to purchase.

Strip out the pure discovery sessions and the completion rate is higher.

The small retailer readiness tax — revisited

Paul do Forno at Deloitte posted last week that smaller retailers face a "hidden agentic readiness tax" — perfect catalog data as table stakes, deep system access creating data leakage risk.

The data above is from a small Dutch retailer. Not a platform. Not an enterprise. A WooCommerce store. The tax is real — it took months of development to get here — but the output is 39 AI-driven orders and €1,269 in revenue in 30 days that would not have existed otherwise.

The readiness tax is a one-time cost. The revenue is recurring.

What comes next

The 13 Unknown Agent sessions are the most interesting data point we have right now. An unidentified agent found this store, parsed the protocol, and is transacting repeatedly. We do not know where it came from. That is the network effect of an open protocol — you do not have to be listed anywhere specific. You publish a conformant /.well-known/ucp manifest and agents find you.

The next milestone is identifying that agent and understanding its mandate scope. If it is running AP2 autonomous purchasing without an explicit buyer confirmation step, the audit trail is the only thing standing between "it worked" and "it bought the wrong thing." That is the observability layer Ben is right about — not a theoretical need, a live operational requirement.

The middle is not unbuilt. It is early, it is messy to get right, and it generates real revenue when you do.

UCPReady is the WooCommerce plugin behind this data. The AI Agent Analytics dashboard is a Pro feature. houseofparfum.nl is the live reference store — the manifest is at houseofparfum.nl/.well-known/ucp.

If you want to see where your WooCommerce store stands: ucpchecker.com

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Tue, 26 May 2026 15:28:38 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

That file is not protocol. It's instructions. It tells AI agents how to behave when shopping on Shopify: start with discovery, sequence cart before checkout, render totals in the order the merchant provides them, treat escalation as a normal lifecycle step not an error. It encodes operational knowledge that the UCP spec alone doesn't cover.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We build UCPReady — a WooCommerce plugin that implements the full UCP stack. And until last week, WooCommerce merchants running it had the protocol layer but not the instruction layer. No file telling agents how to work with their store. No guidance surface beyond /.well-known/ucp.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

That asymmetry matters. But there's a second asymmetry that's just as real: Shopify agents arrive at a store already knowing how to behave. Non-Shopify agents arrive and have to figure it out from the profile alone.

A SKILL.md bundled in a CLI is one way to solve that. But it only works for agents that installed that specific CLI. The more durable fix is publishing the operating manual on the merchant's own domain — discoverable by any agent, from any platform, the moment it finds the store.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Both are generated dynamically from live merchant capabilities. If cart is disabled, the cart section doesn't appear. If KeepCard isn't active, no keep-offer guidance is included. Nothing is hardcoded; nothing claims unsupported behavior.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

When Google announced Universal Cart at I/O 2026, the commerce director described UCP as "a common language that lets agents reach businesses securely and seamlessly." Universal Cart, AI Mode checkout, YouTube Shopping — they all run on it.

The stores that benefit are the ones agents can actually work with reliably. A broken or ambiguous implementation gets abandoned. A store with a valid manifest, correct capability declarations, and clear operating guidance gets completed transactions.

Shopify's approach is to bundle instructions in a CLI. That works for Shopify's ecosystem. Our approach is to publish instructions on the merchant's own domain, discoverable by any agent from any platform.

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Thu, 21 May 2026 22:45:41 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

I Replaced a Returns Portal with Five MCP Tools. Here's What Actually Happened.

Almin Zolotic — Thu, 30 Apr 2026 20:06:06 +0000

A live WooCommerce journey where a model searched products, completed a purchase, and handled a return with keep-offer logic — through UCPReady and KeepCard.io on the Universal Commerce Protocol.

Most "AI commerce" demos are still just chat layered on top of old flows.

Tonight we did something different.

We ran a live WooCommerce journey where a model:

searched products
helped complete a purchase
and then handled a return with keep-offer logic

Not on a mock store. Not with human agents behind the curtain. Not with Claude-specific business logic buried in the backend. And not by building "AI features" into the store itself.

This ran through UCPReady and KeepCard.io — two products I built — using protocol-native rails so the model could interact with the store as an agent.

The transcript in one line

This was the actual lifecycle:

Customer asked for a face cleanser
Model searched the live WooCommerce catalog
Customer bought two products
Checkout ran through UCPReady
Payment used wallet rails plus browser authorization
Order completed
Customer changed their mind about one item
KeepCard.io verified the order, surfaced the line items, collected the reason, and presented a keep offer
Customer accepted the offer
A real discount code was generated
A real confirmation email was sent

That is the entire commerce loop in one conversational journey.

What actually happened

The session started like a normal shopping flow. The model searched a live WooCommerce store, found products, built a checkout, selected fulfillment, selected payment, and moved through the purchase flow using UCPReady.

Then, in the same broader system, we tested returns through KeepCard.io.

The return flow did this:

Looked up the order by order number and email
Checked eligibility
Collected the return reason
Evaluated keep-offer logic
Presented the customer with a keep offer in chat
Accepted the offer
Generated a real discount code
Sent the confirmation email

We saw the discount code issued. We saw the email arrive. We saw the KeepCard dashboard record the return session as Kept.

That is not "AI-assisted support." That is a real agentic commerce lifecycle.

A real example from tonight

The customer started with:

I want to buy something to clean my face

The model searched the live catalog and found:

Rilastil Aqua Face Cleanser 200ml — €16.95
Shiseido Men Face Cleanser 125ml — €18.95

The customer then said:

buy me 2 of Rilastil Aqua Face Cleanser 200ml and 1 Shiseido Men Face Cleanser 125ml

The system created checkout, configured fulfillment and wallet payment, and moved the buyer into the final authorization step.

After the order completed, the customer came back with:

Oh no, I made a mistake — I want to return the item

The return flow asked for the order number, verified eligibility, and surfaced the exact purchased items:

Rilastil Aqua Face Cleanser 200ml (Quantity: 2)
Shiseido Men Face Cleanser 125ml (Quantity: 1)

The customer selected only the Shiseido item. Then gave the reason:

Other — I made a mistake

Instead of routing to a standard return portal, the system evaluated the return and offered a keep option:

You can keep the Shiseido Men Face Cleanser and receive €1.00 off your next order as a discount code.

The customer replied:

Accept

The result:

Keep offer accepted ✓
Discount code KEEP-3V9FNM generated in WooCommerce ✓
Confirmation email delivered via KeepCard's email stack ✓
No return shipment needed ✓

That is exactly the kind of post-purchase flow that usually lives inside rigid portals, manual support queues, or custom integrations tied to one model vendor. Tonight it happened conversationally on top of a live WooCommerce stack.

The architecture: what UCPReady and KeepCard.io actually are

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol (UCP) — an open protocol for exposing store capabilities through structured, machine-operable interfaces. It turns a WooCommerce store into a UCP-compliant endpoint that AI agents can discover and transact with autonomously.

The MCP endpoint on houseofparfum.nl exposes these tools:

— shopping —
ucp_list_products       ucp_get_product
create_checkout         get_checkout
update_checkout         complete_checkout
cancel_checkout         create_cart
get_cart                update_cart
cancel_cart             convert_cart
ucp_get_order           ucp_list_orders

— returns (KeepCard) —
keepcard_check_return_eligibility
keepcard_select_return_items
keepcard_submit_return_reason
keepcard_accept_keep_offer
keepcard_decline_keep_offer

KeepCard.io is a standalone returns intelligence platform. It connects to WooCommerce via REST API and Shopify via app installation. It owns the decision engine — return eligibility, keep-offer thresholds, fraud signals, monthly caps, discount code generation, and email delivery. None of that logic lives in the LLM.

The UCPReady companion plugin for KeepCard exposes five MCP tools that let any agent drive the return flow conversationally, while KeepCard handles all the business logic and side effects server-side.

The important part: no AI in the business logic

This is the part worth repeating.

There is no hidden LLM orchestration inside the return engine. There is no model deciding business logic in the backend. There is no "if Claude says X, do Y" architecture.

The business logic is deterministic:

Return eligibility
Order verification
Keep-offer thresholds
Duplicate protection
Policy routing
Store credit and discount issuance

The model is only the interface layer.

That makes the system:

Model-agnostic — Claude, GPT-5, Gemini, Grok all work
Easier to audit — no prompt-based rules buried in a system prompt
Easier to harden — business rules are code, not inference
More future-proof — swap the model, the commerce layer stays the same

The same session ran successfully with both Claude Sonnet 4.5 and GPT-5. Neither needed store-specific prompting. The protocol carries the context.

How the return flow chains through UCPReady

The integration works server-to-server. When the agent calls keepcard_check_return_eligibility, UCPReady makes an HTTP POST to the KeepCard /api/mcp/init endpoint with the store slug, order ID, and email. KeepCard resolves the order directly against WooCommerce or Shopify using its own stored credentials — UCPReady never touches the order data.

The full call chain looks like this:

Agent → UCPReady MCP endpoint (WooCommerce)
      → KeepCard /api/mcp/* (cloud service)
      → WooCommerce or Shopify API (order verification)
      → KeepCard decision engine (keep-offer logic)
      → WooCommerce API (discount code creation)
      → KeepCard email stack (confirmation)
      → back through the chain to the agent

The LLM sees clean structured responses at each step:

// keepcard_check_return_eligibility response
{
  "eligible": true,
  "session_id": "...",
  "needs_item_selection": true,
  "customer_message": "I found order #85774. You have 30 day(s) left to return it. Which item(s) would you like to return?",
  "order": {
    "display_id": "85774",
    "items": [...],
    "currency": "EUR",
    "days_remaining": 30
  }
}

// keepcard_accept_keep_offer response
{
  "outcome": "kept",
  "discount_code": "KEEP-3V9FNM",
  "amount": 1.00,
  "currency": "EUR",
  "email_sent": true,
  "customer_message": "Done! Your discount code is KEEP-3V9FNM — worth 1.00 EUR off your next order. A confirmation has been sent to your email."
}

The customer_message field means the agent surfaces KeepCard's language directly — it does not have to infer what to say from raw API data.

Why this is different from what's already out there

Most of what is marketed today as "AI returns" falls into one of these buckets:

Approach	What it actually is
Chatbot on a returns portal	AI layer on top of an existing flow, still ends in a form
Custom automation project	Tied to one model vendor, one store, one integration
Shopify-first AI returns	Good tooling, but WooCommerce is a different ecosystem
Refund infrastructure for devs	Powerful but requires significant custom work

Those are real products. But they are still mostly AI applications sitting on top of commerce systems.

What we are building is different: the commerce system itself becomes operable by agents.

UCPReady exposes structured commerce capabilities through UCP and MCP. KeepCard.io exposes post-purchase capabilities through the same kind of machine-operable interface. The store does not wait for us to write Claude-specific code, GPT-specific prompts, or Gemini-specific workflows.

The model is replaceable. The protocol is the product.

Why WooCommerce specifically matters

A lot of public examples in this space are Shopify-first. That makes sense — Shopify has a louder app ecosystem and more visible AI tooling.

But what happened tonight was on WooCommerce.

WooCommerce powers a large share of the world's online stores. It has almost no public examples of protocol-driven, frontier-model, post-purchase flows. The combination of:

WooCommerce-native
Protocol-native (UCP)
Model-agnostic
Agent-executable
Post-purchase keep-offer logic

...is the category we are helping define. I have not seen a strong public proof of this combination before tonight.

What broke (because honesty matters)

Tonight was not a perfect demo, and that is exactly why it was valuable.

1. The keep-offer accept step was occasionally slow. The final keepcard_accept_keep_offer step sometimes exceeded the runner timeout budget. The business action still completed — coupon created, email sent, session marked kept — but the agent runner could report failure because the round trip took too long. This is a bridge latency problem, not a logic problem.

2. Duplicate finalization needed hardening. When the first accept completed but the runtime retried, we needed the system to treat the retry as a successful terminal state rather than an error. Repeated accept should return: already processed, discount code, final state. That is what resilient agent commerce looks like.

3. Mixed shopping and returns in one session exposed session contamination. In one test, we ran search → purchase → return inside a single session. That exposed a session-orchestration issue: return tools were receiving stale search arguments from the earlier shopping flow. Not a KeepCard logic problem. A session-context boundary problem. The kind you only discover once the stack is real enough to chain these experiences together.

Where we go next

The hardest question has been answered: can a model search, buy, and then resolve a return with keep-offer logic on a live WooCommerce store through protocol-native rails?

Yes. Tonight, it did.

The remaining work is hardening, not architecture:

Reduce latency on the post-purchase bridge
Keep terminal actions idempotent across retries
Isolate session state between shopping and returns flows
Test identity linking across multi-session journeys
Validate the same lifecycle across more stores

When the remaining problems are latency budgets, idempotency, and session context boundaries — you are no longer asking whether the concept works. You are refining a working system.

The bigger idea

The goal is not "AI can help with returns."

The goal is: stores should become operable by agents through standard protocols.

Search is one capability. Checkout is one capability. Payment is one capability. Returns are one capability. Keep-offers are one capability. Once those are exposed properly through open protocol rails, the model becomes interchangeable.

That is when agentic commerce stops being a gimmick and starts becoming infrastructure.

UCPReady: zologic.nl/ucpready — WooCommerce UCP implementation

KeepCard.io: keepcard.io — Returns intelligence platform

Session recording: ucpplayground.com/s/01KQFVJJK6HZF2Z58MVMZQ3WXP

Universal Commerce Protocol: ucp.dev