Coder Legion - Recent posts tagged ucp

The Stack Nobody Talks About: Why Travel Needs an Execution Runtime

Fri, 26 Jun 2026 13:54:45 +0000

Google just published the UCP Lodging charter. Booking.com, Expedia, Hilton, Marriott, Amadeus, Trip.com. The largest players in travel have aligned around UCP as the open standard for lodging distribution.

The industry just mapped the destination. The question nobody in that charter answered is who executes the transaction when the agent arrives there.

The charter defines interoperability. It does not specify the execution runtime that carries an autonomous transaction from intent to confirmed booking. Those are different problems.

HTTP enabled the Web.
OAuth enabled delegated identity.
MCP enables tool invocation.
UCP defines commerce interoperability.
UCP.travel enables autonomous travel execution.

That last line is not marketing. It is a technical claim about a missing layer. This article explains what the layer is, why it has to exist, and why none of the charter signatories have shipped it.

What agents can do today vs what they need to do

An AI agent connected to a travel search tool can find flights. It can present options, explain fare conditions, and compare prices. That part works. The agent is an excellent research assistant.

The problem is that research is not a booking. A booking requires:

A verified offer that has not expired
A confirmed price that has not changed since search
An authenticated identity on whose behalf the transaction occurs
A cryptographic mandate proving that identity authorized this specific transaction
A payment that clears without a human opening a browser

Every travel API on the market stops short of this list. They provide inventory access. They do not provide execution.

An API exposes operations. An execution runtime owns the outcome.

The gap between inventory access and confirmed booking is where every autonomous travel agent demo breaks. The offer expires while the agent is reasoning. The price changes between search and purchase. The payment step requires 3D Secure, which requires a human to complete a browser challenge. The booking comes back as a pending confirmation that the agent does not know how to handle.

These are not edge cases. They happen on every booking in production.

Why the incumbents cannot close this gap

The global distribution systems were built when the assumed actor at every step was a trained human agent. The EDIFACT messaging protocol that still processes the majority of global airline transactions was designed in the 1980s. NDC modernized the data format but did not change the assumption: a human reviews the offer, a human approves the price, a human completes the payment.

Layering an AI interface on top of a human-assumed architecture produces a better research tool, not an autonomous execution system. The agent can fill the form. It cannot own the transaction.

The reason this has not been solved is not technical difficulty alone. It is that solving it requires rethinking the settlement chain, not just the interface. Who is responsible when an agent books at a price that changed between search and purchase? Who holds the mandate that authorizes autonomous payment? Who owns the audit trail when a dispute occurs?

These are architecture questions. They require a purpose-built layer, not a plugin on top of an existing one.

Signing a charter defines intent. It does not ship a runtime.

What an execution runtime actually does

An execution runtime is not another API. It is the trusted decision layer between an autonomous agent and supplier infrastructure. It verifies policy, identity, mandates, payment eligibility, offer validity, and booking state before any transaction commits.

Every major shift in computing created a new execution layer. HTTP did not eliminate web servers. OAuth did not eliminate authorization systems. UCP will not eliminate execution runtimes. Someone still has to decide whether a transaction is allowed to commit.

That execution layer is what UCP.travel implements.

It sits between the AI agent and the travel inventory. The agent calls tools. The runtime handles everything the agent cannot handle on its own.

Concretely, before any booking completes, the runtime verifies:

The offer is still live and has not expired
The price has not changed since the agent retrieved it; if it has, the delta surfaces before money moves
The traveler's identity is authenticated via OAuth
A signed mandate exists confirming this traveler authorized this class of transaction at this price
The payment clears without requiring a browser challenge

If any of these conditions fails, the booking does not proceed. The agent receives a structured error with an instruction for what to do next. No silent failures. No double charges on retry. No expired offer exceptions the agent cannot recover from.

This is not a feature list. It is what makes the difference between a demo and a production system.

The stack

Each layer solves a problem the layer below it cannot. The LLM reasons but does not invoke. MCP invokes but does not transact. UCP defines how systems exchange commerce but does not enforce whether a specific transaction is allowed to commit. That is the execution layer.

Two webs, two models

The web was built for human request-response. Autonomous commerce runs on a different model entirely.

The human web assumes a person at every decision point. The agent web assumes a runtime. Without a runtime that can enforce mandate, verify policy, and commit transactions, the agent web is just the human web with a chatbot in front of it.

This has been demonstrated in production

On June 1, 2026, at 15:33 CET, a Gemini 2.5 Flash agent connected to the UCP.travel MCP endpoint, called two tools, and completed a confirmed flight booking in 8 seconds.

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

The PNR was visible in the travel provider dashboard within seconds. No human touched the booking flow after the traveler's one-time setup.

The UCP.travel manifest is public at ucp.travel/.well-known/ucp and verified by UCPChecker. It is currently the only verified implementation of travel.ucp.mandate in the UCP ecosystem.

As travel joins the UCP ecosystem, execution semantics such as offer validity, passenger identity, mandates, payment authorization, and supplier confirmation will need to be represented alongside the base protocol.

"Love the Agentic AI workflow & distribution layer! Good stuff, keep it coming!"
— Fritz Oberhummer, Strategy Advisory for Product, Platform & AI, oberhummer.com

The protocol layer it builds on

UCP.travel does not replace the Universal Commerce Protocol. It extends it for travel.

UCP defines the checkout lifecycle, identity linking, AP2 mandates, and commerce interoperability. It was built for retail. Retail has stable SKUs, fixed prices, and shipping fulfillment. Travel has none of these. Travel has perishable offers, real-time repricing, passenger identity requirements, asynchronous booking confirmations, and supplier-specific policy enforcement.

The travel.ucp.* namespace handles what the base spec has no primitives for: offer TTL, price revalidation, cancellation timelines, loyalty accounts, passenger age derivation, and codeshare booking references. These are not optional. Every one of them is a failure mode in production if not handled.

The charter organizations will eventually build toward this. Building on top of a 40-year-old distribution assumption is a different starting point than building for agents from day one.

What this means for developers building travel agents

If you are building an AI travel assistant today, you are probably doing one of two things.

You are wrapping a travel search API in an MCP tool and presenting results to a user who then books manually. The agent is a research layer. The human is the execution layer. This is not autonomous booking.

Or you are trying to complete the booking autonomously and hitting the wall: expired offers, silent price changes, 3DS challenges your agent cannot complete, 202 responses your agent retries into double charges.

UCP.travel is the runtime that removes that wall. The agent calls tools. The runtime handles offer lifecycle, mandate verification, identity, and payment. The booking completes. The PNR comes back.

The traveler sets up once: authenticates, signs a mandate defining their booking constraints, connects their AI assistant via OAuth. After that, every booking within those constraints is autonomous.

That is not an assistant. That is an execution runtime.

The infrastructure sequence

HTTP answered:     "How do computers communicate?"

OAuth answered:    "Who is allowed to act?"

MCP answered:      "How do agents invoke tools?"

UCP answers:       "How do systems exchange commerce?"

The remaining question is:

                   "Who is trusted to execute the transaction?"

That is the execution layer.

Each layer in this sequence solved a problem the layer below it could not. Each one was called unnecessary by people who could not yet see the applications it would enable.

The applications that require autonomous travel execution are not theoretical. Corporate travel management at agent scale. AI-driven itinerary optimization that books, not just suggests. Travel policy enforcement that operates at the moment of transaction, not after the receipt arrives.

Protocols tell agents how to speak. Execution runtimes decide whether they are allowed to act.

UCP.travel is built by Zologic. The manifest is public at ucp.travel/.well-known/ucp. UCPChecker verification: ucpchecker.com/status/ucp.travel. The booking demonstration is documented at dev.to/zologic.

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

Mon, 18 May 2026 19:27:55 +0000

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, completed a purchase, and then handled a return with keep-offer logic. Not on a mock store. Not with human agents behind the curtain. Through UCPReady and KeepCard.io on protocol-native rails.

The transcript in one line

Customer asked for a face cleanser. Model searched the live WooCommerce catalog. Customer bought two products. Checkout ran through UCPReady. Order completed. Customer changed their mind. KeepCard.io verified the order, surfaced the line items, collected the reason, and presented a keep offer. Customer accepted. 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 session 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 ✓

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 important part: no AI in the business logic

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 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."
}

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 but the agent runner could report failure because the round trip took too long. This is a latency problem, not a logic problem.

2. Duplicate finalization needed hardening. When the first accept completed but the runtime retried, the system needs to treat the retry as a successful terminal state rather than an error. Repeated accept should return: already processed, discount code, final state.

3. Mixed shopping and returns in one session exposed session contamination. Running search, purchase, and return inside a single session exposed a session-context boundary problem: return tools were receiving stale search arguments from the earlier shopping flow. 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

AP2 Mandates Are Live on UCPReady — Here's What That Actually Means for Autonomous Payment

Mon, 27 Apr 2026 09:00:29 +0000

Zero merchants in Ben Fisher's 4,024-merchant UCP dataset support native payment. I've been building toward closing that gap since March. Today it's done — at least on the business side.

This post is about AP2 Mandates: what they are, why they're the only spec-compliant path to autonomous card payment on UCP, and what it took to implement them correctly on WooCommerce.

Why every UCP checkout still ends with a browser redirect

When an AI agent completes a UCP checkout today, it gets a continue_url. The buyer clicks a link, lands on the WooCommerce checkout page, fills in their card, and pays. The agent handled discovery and session setup. The human handled payment.

That handoff exists because the spec requires it — unless one specific extension is active.

From the UCP checkout specification:

"The checkout has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported."

That "unless" is the entire autonomous payment story in UCP. Not Stripe tokens. Not saved cards. Not wallet APIs. AP2 Mandates.

What AP2 Mandates actually are

AP2 is a cryptographic authorization framework. When it's negotiated between a business and a platform, the checkout session is "security locked" — neither party can revert to an unprotected flow.

The flow has two sides:

Business side: Every checkout response must include ap2.merchant_authorization — a JWS detached signature proving the checkout terms (price, line items, totals) are authentic and haven't been tampered with. The signature is ES256, JCS-canonicalized per RFC 8785, with the payload excluded from the JWS body (RFC 7515 Appendix F detached content format).

Platform side: When the user confirms the purchase, the platform generates a cryptographically signed mandate — an SD-JWT credential proving the user explicitly authorized this specific transaction. It submits that mandate at complete_checkout. The business verifies it. If valid, payment proceeds without a browser redirect.

The checkout mandate contains the full checkout response including the business's merchant_authorization. So the platform's signature covers the business's signature. It's a nested cryptographic binding: the business proves the terms, the platform proves the user consented to those exact terms.

What implementing this actually required

Getting the signing right

The spec says ES256 with detached JWS. In PHP, openssl_sign() on a P-256 key produces a DER-encoded ECDSA signature. JWS ES256 requires raw r||s — 64 bytes for P-256. Those are not the same format.

Every JWS library you'd use on the platform side (jose, python-jose, jsonwebtoken) expects raw r||s. A DER signature will fail verification silently or throw a malformed signature error. The fix is a DER-to-raw-rs converter:

// openssl_sign() → DER. JWS ES256 → raw r||s. Not the same.
openssl_sign( $signing_input, $signature_der, $private_key, OPENSSL_ALGO_SHA256 );
$r = substr( $der_inner, $r_offset, $r_len );
$s = substr( $der_inner, $s_offset, $s_len );
$signature_raw = str_pad( ltrim($r, "\x00"), 32, "\x00", STR_PAD_LEFT )
               . str_pad( ltrim($s, "\x00"), 32, "\x00", STR_PAD_LEFT );

The JCS canonicalization (RFC 8785) is the other non-obvious requirement. Before signing, the checkout payload is canonicalized — keys sorted recursively, Unicode normalized, numbers in IEEE 754 format. This ensures the signature is reproducible across systems that may re-serialize JSON differently.

Enforcing the mandate at complete_checkout

The spec is explicit: if AP2 was negotiated, complete_checkout MUST reject requests without ap2.checkout_mandate. This is the security boundary. Without it, AP2 is advertised but provides no protection — a platform could skip the mandate entirely and the checkout would succeed.

The enforcement block runs before order creation:

if ( $ap2_ext->is_ap2_configured() ) {
    $mandate_jwt = $body['ap2']['checkout_mandate'] ?? null;
    if ( empty( $mandate_jwt ) ) {
        // Return mandate_required error — session stays ready_for_complete
        return $this->mandate_error_response( 'mandate_required', $session );
    }
    $mandate_error = $ap2_ext->verify_checkout_mandate( $mandate_jwt, $session, $request );
    if ( null !== $mandate_error ) {
        return $this->mandate_error_response( $mandate_error['code'], $session );
    }
}

Verifying the mandate

When a mandate is present, the full verification chain runs:

Parse the SD-JWT structure (header.payload.signature~disclosures~keybinding)
Check expiry (exp claim)
Extract the embedded checkout from mandate claims
Re-verify merchant_authorization — confirm the platform wrapped our own signature, not a different checkout
Verify checkout ID matches the current session
Verify totals match — no bait-and-switch between what the user saw and what gets charged

Platform key verification

The final step: verifying the SD-JWT outer signature using the platform's public key. This is what proves the mandate is genuinely from the platform and not forged.

The flow: decode the JWS header → extract alg and kid → fetch the platform's UCP profile from the UCP-Agent header → pull signing_keys → find the JWK matching kid → build an OpenSSL public key from the JWK x/y coordinates → verify.

Building an EC public key from JWK coordinates without a library means constructing the SubjectPublicKeyInfo DER by hand in PHP — OID encoding, SEQUENCE wrapping, BIT STRING for the uncompressed EC point. It's ~80 lines but removes a runtime dependency and works on any WordPress host.

The platform profile is fetched over HTTPS and cached with WP transients, respecting Cache-Control max-age with a 60-second floor. Verification result is logged with kid, algorithm, and session ID for auditability.

The capability name that broke everything

Before any of this verification mattered, there was a simpler bug: the capability was advertised as dev.ucp.shopping.ap2_mandates — plural. The spec uses dev.ucp.shopping.ap2_mandate — singular.

Capability negotiation is a string equality check. The intersection algorithm finds no match between ap2_mandates and ap2_mandate. AP2 is never activated. Every checkout session falls back to delegate payment. No error, no warning — it silently never negotiates.

One character. Every implementation should validate capability names against the spec registry rather than trusting their own strings.

What's live now

When dev.ucp.shopping.ap2_mandate is enabled in UCPReady and a compatible platform connects:

Every checkout response includes ap2.merchant_authorization (JWS ES256, detached, JCS payload)
complete_checkout rejects requests without ap2.checkout_mandate
Verification runs: SD-JWT parse → expiry → embedded checkout extraction → merchant_authorization re-verification → ID and totals match → platform key verification
If all checks pass, payment proceeds — no browser redirect

The one remaining piece is ecosystem readiness: a platform that supports AP2 mandate submission and forwards the access token that proves identity linking. Ben Fisher's UCPPlayground is the logical first test. Once that's connected, UCPReady will produce the first confirmed AP2-mandate-verified autonomous purchase on WooCommerce.

Why this matters beyond WooCommerce

Ben's dataset of 4,024 merchants shows zero native payment support. Part of that is the SPT/ACS story — Stripe's Shared Payment Token is US-only right now and requires Stripe to host the checkout flow. That's a different architecture than UCP.

On UCP, AP2 Mandates is the spec's answer. It's protocol-agnostic — the mandate can cover any payment method handled by any PSP. The platform proves user consent cryptographically. The business verifies that proof and charges via their existing payment gateway. No card data crosses protocol boundaries. PSD2 SCA compliance comes from the mandate being platform-issued and buyer-authenticated at mandate creation time.

This is what autonomous agent commerce looks like when the merchant controls the checkout instead of delegating it to Stripe's infrastructure.

UCPReady is available at zologic.nl/ucpready.

If you're building a platform that supports UCP and want to test AP2 mandate submission against a live endpoint, reach out. houseofparfum.nl is running UCPReady 1.8.23 with AP2 ready to activate.