Universal Commerce Protocol (UCP) for agentic payments

Protocol job

UCP makes commerce capabilities discoverable and composable

Universal Commerce Protocol defines building blocks that businesses can expose to agent and platform clients. Its published materials describe capabilities including catalog search and lookup, cart building, identity linking, checkout, and order management, with extensions for concerns such as discounts and fulfillment. Capability and version negotiation let participants determine which operations and schemas they can use instead of assuming every merchant implements one identical journey.

That scope addresses a real gap in agentic payments: the agent needs machine-readable seller, product, totals, fulfillment, order, and post-purchase state before and after the rail call. UCP does not make a discovered product authorized, and a checkout object is not proof that the principal approved it. Commerce interoperability, user authority, payment execution, and settlement should remain named layers in the architecture.

UCP can describe the commercial transaction. A mandate and policy decision must still establish why the agent may commit to it.

Preserve checkout versions and order transitions

Checkout assembles the material terms that authorization must evaluate: merchant, line items, quantity, discounts, taxes, fees, currency, payment requirements, fulfillment options, destination, and total. Those values can change as inventory, pricing, shipping, or buyer details change. Record the exact checkout version or canonical digest evaluated by policy and require a new decision when a changed field falls outside the mandate.

Order management continues after payment. Confirmation, fulfillment expectations and events, adjustments, returns, and refunds belong to the commercial lifecycle. Link them to the payment without flattening one into the other. A rail can report settlement while the order remains unfulfilled; an order adjustment can show a refund while the principal has not yet received the credit. Reconciliation must compare both sources.

Keep identity linking, mandates, and payment credentials separate

Identity linking can let a buyer authorize an agent or platform to access a business account through established mechanisms such as OAuth. That access should be scoped to the necessary commerce capabilities and revoked independently. Account access identifies a relationship with the merchant; it does not grant unlimited financial authority or prove that a specific order is within the principal's mandate.

UCP materials describe integration with payment and agent protocols, including AP2. A robust flow binds the final checkout to mandate evidence, asks deterministic policy to allow or step up, then presents the narrowest credential supported by the chosen rail. Store each artifact with its issuer and version. Avoid placing raw reusable payment credentials in UCP objects, agent prompts, or broad operational logs.

• Scope identity tokens to the business, capability, subject, and required lifetime.
• Bind authorization to a versioned checkout or order digest and material terms.
• Use one idempotency record for the intended economic effect across retries.
• Verify payment status from the responsible provider or rail rather than the agent narrative.
• Treat post-purchase changes as new policy inputs when they add fees or waive rights.

Implement UCP as an adapter around a stable internal model

Businesses should publish only capabilities and versions they can operate end to end. Validate every request, use deterministic totals, authenticate clients where required, make completion idempotent, and emit durable order events. Agents should reject incompatible required capabilities and avoid silently dropping extension fields that alter price, fulfillment, cancellation, or identity semantics.

An internal model for intent, order, decision, payment, and outcome keeps protocol changes from rewriting the meaning of authority. Preserve the original UCP payload or digest, map it into that model with a versioned adapter, and record fields that could not be represented. Test changing checkout totals, duplicate completion, delayed order events, partial fulfillment, returns, and refund reconciliation before treating protocol interoperability as production readiness.

• Pin schema versions and maintain fixtures for supported capability combinations.
• Separate merchant order truth from processor or rail payment truth.
• Expose stable identifiers across checkout, order, payment, fulfillment, and adjustment events.
• Keep a human-operable support and correction path for incompatible or incomplete state.