PAP Signs In, UCP Handles Checkout and Payment

Two protocols now divide the work of an agent buying something for a person, and as of November 2 they say so in writing. The Personal Agent Protocol — PAP, or “Poppy” — merged a ucp extension into its draft 0.3 that defines how it fits with the Universal Commerce Protocol. The extension’s first section puts the split in one sentence:

“This protocol finds the Company, identifies the Personal Agent and a pseudonymous User, and signs the User in; UCP is the business protocol for how a Personal Agent shops once it is there.”

Read that twice, because it settles an argument the agent-commerce world has been having by accident. Discovery and sign-in are one job. Commerce is another. PAP does the first. UCP does the second. Neither is the whole road.

The two files

Each protocol starts from a file a company publishes on its own host. PAP’s is /.well-known/poppy.json: it identifies the organization and lists what the company offers an agent. UCP’s is /.well-known/ucp: the profile that declares the commerce capabilities and carries the signing keys.

For a company that speaks both, the extension asks for almost nothing. The UCP profile stays exactly where UCP puts it. The company adds one entry to the extensions object in its poppy.json:

"extensions": {
  "ucp": { "version": "1" }
}

That is the entire integration on the discovery side, and the restraint is deliberate. In the extension’s words, “what the Company offers an agent is what the negotiated UCP profile says it offers; poppy.json carries nothing about it.” The pointer file points. The profile describes. Two rules ride along: a poppy.json may redirect, but a UCP profile must not — an agent must not follow a redirect from the UCP profile’s address — and the agent’s UCP platform profile must not be specific to a user, so its address cannot be used to match one person across stores.

Who does what

The extension’s division of labor, job by job:

• Finding the company — PAP, through poppy.json. UCP’s profile sits on the same host.
• Capabilities and versions — UCP, negotiated from the UCP profile. PAP carries nothing about them.
• Who is calling — PAP names the agent through a session header and an operator signature. UCP names the platform through its profile, carried in the UCP-Agent header, with signatures.
• Signing the person in — PAP, through Direct Sign-In at the company’s own issuer. UCP’s side is identity linking — and the extension is explicit that it is the same issuer. One sign-in, seen from two sides, not two sign-ins stacked.
• Questions to the store — either PAP conversations, or UCP’s Ask capability listed as the conversation protocol.
• Cart, checkout, order, payment — UCP. All of it. PAP’s entry in the table is the word “Nothing.”
• State — PAP keeps one session per visitor. UCP keeps one identifier per workflow: cart, checkout, order, conversation.

The names translate cleanly, which helps: UCP’s Business, Platform and Buyer are PAP’s Company, Personal Agent and User. And where the extension names a UCP field or rule, it defers — “this page describes the connection, and UCP describes the commerce.”

“UCP is its payment mechanism”

Payment was the open question when PAP’s first draft appeared, because a protocol that signs a person in eventually has to answer who takes their money. For companies that advertise the extension, draft 0.3 now answers it in section 6:

“Carts, checkouts, orders, catalog search, and payment are defined by UCP, with their schemas, lifecycles, and negotiation.”

“Payment is part of UCP checkout: the Company’s UCP profile advertises the payment handlers it accepts, the Personal Agent’s platform profile says which it supports, and the checkout carries the instrument. For a Company that advertises this extension, UCP is its payment mechanism, and a Personal Agent that supports the extension pays through it.”

One purchase gets one approval, and the approval is UCP’s: the person reviews the checkout in a trusted interface, then the agent completes it. The extension warns companies not to return a second approval operation for the same action, because “two approval records for one action can disagree.” When a checkout needs the person to finish a step on the store’s own page, the hand-off link goes to the person’s browser, not the agent’s. And the instruments themselves travel as tokens — UCP’s payment handlers tokenize them, so the agent carries tokens rather than raw credentials, and those tokens stay out of the model’s context.

That last point deserves a pause. The security story of agent commerce is mostly a story about what the agent never touches. It never holds your card. Under this split it also never holds your password: PAP’s sign-in happens at the company’s issuer, on the company’s own page, and what the agent carries afterward is a session and a pseudonymous identity — an ID for the user that is different at each company.

It is not a gate

The clause that keeps the split honest is easy to miss. Section 2: “A Company MUST NOT require a UCP platform to implement this protocol as a condition of access UCP otherwise permits.”

PAP is an offered convenience, not a toll booth. A store can publish poppy.json, list the extension, and offer the smooth path — discovery, one sign-in, a session that follows the person across the store’s APIs, website and agent conversations. An agent that wants none of that can still call the store’s plain UCP endpoints and shop. The agent decides, per request, which way it calls. Protocols that try to make themselves mandatory tend to become obstacles; this one has written its own optionality into the draft.

Where Ask fits — and a draft already behind its subject

The extension also lets a company name UCP’s Ask capability — dev.ucp.common.ask — as its conversation protocol, listing it in poppy.json with type ucp and the UCP profile’s address as the endpoint. PAP’s conversation fields map onto Ask’s: the message text becomes the query, the reply is the answer.plain, and a turn is always idle afterward because Ask is synchronous. Handing off to a human has no Ask equivalent.

There is a small, telling wrinkle here. The extension describes Ask as being “in UCP’s current draft” and shipping “in a later UCP release.” On the same day the extension merged — November 2 — UCP backported Ask into its 2026-08-25 release, and the Ask documentation is live. The connecting document was out of date about its subject on the day it landed. That is not a scandal; it is what draft protocols look like from inside. It is also the reason everything quoted here carries its status with it: this is draft 0.3 of PAP, and any of the text may still change.

Three stores already run both

PAP Checker’s list counts 31 sites publishing a poppy.json. Checked on November 3, three of them also serve a UCP profile: Ticket Fairy (PAP 0.2, UCP 2026-08-25, declaring checkout, catalog search, discounts, fulfillment and orders, plus its own ticketing extensions), GT Slot Cars (PAP 0.1, UCP 2026-04-08), and X402-BROKER (PAP 0.2, UCP 2026-08-25, including identity linking). None of the three lists the new ucp extension yet — expected, a day after it merged. They are running the two protocols side by side before the connective text existed, which is usually how a standard learns what it needs to say.

The money side has one more thread in flight. A financing-offers extension — proposed in PAP’s issue tracker on November 2, signed by Synchrony as a design partner — would let an agent ask a lender which offers apply to a purchase, show the lender’s disclosures unchanged, and carry the chosen offer into the payment the person approves, with the offer’s ID riding in the checkout protocol’s payment data. It is an open proposal, not part of the draft. On UCP’s side, installment payment terms already shipped in the 2026-08-25 release, and the Payments Tech Council’s BNPL working group is the room where the rest gets decided.

And the context behind the authorship: the extension’s two authors, David Pettersson and Ilya Grigorik, both list Shopify on their GitHub profiles. Shopify reported its third quarter the day after the merge — revenue up 32% to $3.74 billion, GMV of $119 billion — and its CFO told the call “we co-led the creation of the Universal Commerce Protocol” and “we’re actively driving other standards, like the Personal Agent Protocol.” Its president put AI traffic at 2.6 times year-over-year, orders growing faster at 3.3 times, and added “it is still quite early.” Shopify did not split agent orders by protocol. Nobody can yet say how much commerce runs on either one.

What a store actually does with this

If your store already speaks UCP, the honest answer is: almost nothing. Your UCP profile does not change. If you also publish a poppy.json, add the one-line extension entry, keep both files on the same host, and serve the UCP profile without a redirect.

If your store uses PAP for sign-in, the extension asks for one sign-in, not two: offer Direct Sign-In, list private_key_jwt at your issuer, and list your UCP identity-linking scopes in scopes_supported, so the person signs in once at the same issuer both protocols use.

If you build agents: fetch both files, negotiate against the UCP profile, send the same platform profile address everywhere a transport carries it, and pay through UCP checkout. An agent that does not support the extension can still use a store’s UCP MCP endpoint when the store lists one.

Why the split is the story

It would have been easy for this to go the other way — one protocol swelling to cover discovery, identity, conversation, checkout and payment, owned end to end by whoever got there first. Instead the two drafts now point at each other and stay in their lanes: PAP finds the company and signs the person in; UCP runs the commerce and takes the payment; the seam between them is one line in a JSON file and a shared issuer.

That is what a healthy protocol boundary looks like, and it is worth naming because merchants will be asked to bet storefront work on it. The questions to watch from here are the ones the checker sites are already watching: the first stores to list the extension, how PAP’s separate payments work reconciles with UCP’s payment handlers, whether financing offers become an extension, and the WebMCP mapping the draft promises once UCP’s WebMCP binding is published.

Identity here. Commerce there. The protocols finally agree on which is which — in draft, in public, where anyone can read it.