Coder Legion - Recent posts tagged agenticcommerce

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.

Payment Infrastructure Has Always Assumed a Human. That Assumption Is Breaking

Fri, 17 Apr 2026 09:10:12 +0000

This article was originally published on the Blockonomics blog. Read the original version here.

Search through any PayPal forum or subreddit and you'll find the same story told a thousand ways: an account flagged for fraud, funds frozen, business interrupted. More often than not these are false positives — a legitimate transaction that tripped an algorithm.

The first instinct is that this is a bug, an example of how automated systems break down when engaging with real humans. That isn't an incorrect analysis. But it's also a view into the future — and things are only going to get worse, though not for the reasons you might think.

Every payment system built in the last 50 years was built for humans. Why wouldn't it be? Humans are who buy things. No bot had the sophistication or the trust to make a purchase worth designing around. So human interaction got baked into everything: fraud detection, KYC, dispute resolution, checkout flows, purchasing.

But as we enter the era of AI agents, that is changing. AI will soon need to interact with these systems, navigate them without breaking, and complete purchases on behalf of the people who deploy them. This is a problem. Our infrastructure was never designed to accommodate that.

We can already see it breaking down — and agents haven't even arrived yet. Take this account of a tech-savvy professional who lost his PayPal account of twenty years: https://www.linkedin.com/pulse/twenty-years-one-invoice-im-out-how-paypals-killed-my-michael-mcnally-wb7tc/

The system wasn't trying to stop him. He simply wound up in the wrong menus, and that was enough to trigger a permanent deletion — reversed only after his story gained enough public attention to force a human review. A competent person, doing normal things, undone by an interface that had no tolerance for deviation.

And it's not just fraud detection. KYC assumes a human is present to verify everything. An AI agent can't hold a passport up to its face and take a picture. Checkout flows time out when no one is actively clicking through them. Two-factor authentication expects someone to be watching a phone.

The entire architecture of internet commerce was built around keeping bots out. We invented CAPTCHAs for that exact reason. Now we have to reckon with the fact that some bots are supposed to be let in.

AI usage is growing, and agents will increasingly need to access ecommerce systems to do their jobs. We already see those systems struggling with ordinary human behavior — false positives, unnecessary friction, unexplained account closures. But these aren't bugs to be patched. They are structural decisions made years ago, now hardened into infrastructure, with consequences that will compound as agent-driven transactions begin to scale. AI behavior will look nothing like human behavior. And humans are already getting stuck.

As agents enter our commercial ecosystems in larger numbers, the question becomes unavoidable: how will these systems deal with them?

The answer requires more than a software update. It requires rethinking the assumptions underneath. Can fraud detection be built around accountability rather than identity? Can KYC verify an entity and its delegated permissions rather than a face? Can checkout flows be designed for both human and non-human actors without sacrificing security or usability?

I don't have complete answers to those questions. What I do know is that these systems need to be rebuilt intentionally — with the knowledge that autonomous agents will interact with them. That means finding ways to establish accountability while separating it from individual identity. It means designing for actors that don't get tired, don't browse before they buy, and don't respond to a verification text.

These are the problems that people across payments, security, and infrastructure are beginning to work through.

At the end of the day, the coming revolution is not really about AI. It is about infrastructure that was never as robust as we assumed.