Loading…
Agentic commerce
The protocols agree the merchant decides. None of them decides for you.
Agent payment protocols authenticate the buyer's delegation to their agent. None of them decides whether your side should accept the order. That check — margin, discounts, stock, discretion — is the merchant's, and it runs before the order commits.
What the protocols settle
Three agent-payment protocols now reach a merchant's checkout. They differ in shape and agree on where their responsibility ends.
| Protocol | What it settles | What it leaves to you |
|---|---|---|
Agentic Commerce Protocol Stripe and OpenAI, Apache 2.0 | A delegated payment token and a signed request, so the merchant knows which agent is asking and on whose behalf. | Whether to take the order. The specification puts accept-or-decline with the business, per agent and per transaction. |
Agent Payments Protocol Google, standardising through the FIDO Alliance | Cryptographically signed mandates proving a human authorised an agent to buy within stated limits. | Everything on the merchant's side. The mandates bind the buyer to the agent; they say nothing about whether the seller should fill the order. |
Universal Commerce Protocol Google and Shopify, with a retail and payments coalition | Capability negotiation and checkout, with merchant-declared constraints the platform reads before it submits, and a hold that keeps a checkout from completing. | What the constraints should say. The protocol carries the merchant's rules; it does not decide what they are. |
Decionis is not a member, partner or certified implementer of any of these specifications. They are named here because they are what arrives at a merchant’s checkout, not because they endorse anything on this page.
Buyer-side delegation is not merchant-side acceptance
Every one of these protocols proves the same thing: a human authorised an agent to act within limits. That is the buyer's half of the transaction.
Proof that a shopper authorised their agent to spend up to $400 tells you the request is genuine. It does not tell you the basket clears your margin floor, that the three promotions on it were meant to combine, or that the last unit has not already sold on another channel. Those are facts about your business, held in your systems, governed by your policy.
The gap matters more with an agent on the other side than it did with a person. An agent is faster, it is optimising explicitly for the buyer, and it will find the combination of promotions that clears your checkout at a loss — not by attacking it, but by doing exactly what it was asked to do.
What your side has to answer
Four questions, each with a policy shape and a worked example. These are the same checks that apply to a human-placed order; the agent only makes them urgent.
Does this basket still earn anything?
Stacked promotions and a price that moved overnight combine into an order that is profitable on the listing and loss-making on the invoice. An agent optimising for the buyer will find that combination faster than a person would.
Margin floor at checkoutAre these discounts legal together?
Native combination settings decide which codes may combine. They do not see codes issued by a third-party app, a loyalty integration or a support agent, and they do not decide what the order is worth once they have.
Checkout validationIs the stock actually there?
Inventory sync is eventually consistent and checkout is immediate. The oversell is created in the gap and paid for in cancellations and marketplace defect rates.
Oversell preventionIs this within what the agent may decide alone?
A request written by a customer is untrusted text, so an amount it asks for is a claim rather than an authorisation. Discretion belongs to the action, not to the login.
Agent refund limitsWhat runs today, and what does not
Stated precisely, because a merchant evaluating this will read the API before they read the page.
Live. A merchant-side authorization endpoint that accepts a proposed order and returns a verdict before the order commits. It verifies ACP-style webhook signatures over the raw request body when a shared secret is configured, and verifies AP2 mandate signatures on the way in. Escalations have a real lifecycle: an order can be held, resolved by a named person, and re-evaluated.
Reported, not enforced by default. AP2 mandate verification failures are recorded and returned; rejecting on them is opt-in, so a merchant can watch the signal before it starts refusing orders.
Half built, and the half matters. A verdict can now be returned in UCP’s own shape: an allow omits actions entirely, as the specification requires; an escalation returns an outstanding Action, which is UCP’s existing primitive for work that must be processed before a checkout can complete; a block returns a refusal. What is not built is the inbound half — verifying a UCP request the way ACP signatures and AP2 mandates are verified — so this is a mapping of our answer onto UCP’s vocabulary, not a UCP-verified integration.
Not asserted. UCP declines carry an error code, and the specification’s list of them was not retrievable when the mapping was written. A refusal therefore leaves the code unset rather than guessing one. A plausible-looking code would produce an integration that reads as conformant and is not, which is a worse failure than an obvious gap.
A real limit worth knowing. UCP lets a merchant publish constraints the platform reads before it submits, which sounds like somewhere policy could live. It mostly cannot: a constraint states a set of permitted values for a field, with no arithmetic and no comparison across fields. So “quantity must be one” publishes cleanly and “net margin after every discount, shipping and channel fee clears the floor” cannot be published at all. Discrete rules narrow what arrives; the computed ones are answered where they have to be, against facts the platform does not hold.
Not this product. This is not fraud scoring. Fraud vendors build a risk model of a person from behaviour across many merchants; Independent Execution Authority evaluates one proposed action against policy the merchant wrote, and returns the same answer every time for the same facts. If what you need is a probability that a shopper is who they claim, you need the other thing, and probably both.