Strabo: Declarative Specification and Implementation of Agentic Interaction Protocols

# Strabo: Declarative Specification and Implementation of Agentic Interaction Protocols
Source: [https://arxiv.org/html/2606.05043](https://arxiv.org/html/2606.05043)
\\lstdefineformat

LangshawFormat\-/¿=／⟶\\mathchoice\{\\mathrel\{\\hbox to0\.0pt\{\\kern 3\.75pt\\kern\-5\.27776pt$\\displaystyle\\not$\\hss\}\{\\longrightarrow\}\}\}\{\\mathrel\{\\hbox to0\.0pt\{\\kern 3\.75pt\\kern\-5\.27776pt$\\textstyle\\not$\\hss\}\{\\longrightarrow\}\}\}\{\\mathrel\{\\hbox to0\.0pt\{\\kern 2\.625pt\\kern\-4\.45831pt$\\scriptstyle\\not$\\hss\}\{\\longrightarrow\}\}\}\{\\mathrel\{\\hbox to0\.0pt\{\\kern 1\.875pt\\kern\-3\.95834pt$\\scriptscriptstyle\\not$\\hss\}\{\\longrightarrow\}\}\}11institutetext:North Carolina State University 11email:\{schrist, singh\}@ncsu\.edu22institutetext:Lancaster University 22email:amit\.chopra@lancaster\.ac\.uk

###### Abstract

The last few years have witnessed major advances in the modeling and implementation of multiagent systems based on declarative interaction protocols\. Our contribution, Strabo, establishes the relevance of these advances to ongoing industry efforts in Agentic AI\. Specifically, we consider UCP, the*Universal Commerce Protocol*, a recent Google\-led effort to standardize e\-commerce interactions for AI agents\. Our exercise is in two parts\. One, we model the part of UCP dealing with checkouts as a declarative Langshaw protocol and implement agents using Peach, a programming model for Langshaw\. This part of the exercise brings out the advantages of formal, declarative specifications\. Two, we show that Peach agents can interoperate with UCP agents implemented by Google, thereby establishing the fidelity of our approach with respect to UCP\. Such interoperation enables the incremental introduction of declarative protocols and agents into a conventional setting, indicating a pathway by which EMAS ideas could influence practice without demanding a wholesale update\.

## 1Introduction

Interaction protocols model multiagent systems and serve as blueprints for engineering agents\. Recent work, as exemplified by BSPL\[[13](https://arxiv.org/html/2606.05043#bib.bib13),[14](https://arxiv.org/html/2606.05043#bib.bib14),[15](https://arxiv.org/html/2606.05043#bib.bib15)\]and Langshaw\[[16](https://arxiv.org/html/2606.05043#bib.bib16)\], has emphasized formal, declarative approaches for specifying protocols\. Formal specification enables verifying protocols for correctness before any agents are implemented\. Declarative specifications better reflect stakeholder intuitions about the meaning of interactions\[[12](https://arxiv.org/html/2606.05043#bib.bib12)\]and, consequently, support flexible interactions between agents\. Programming models that facilitate implementing agents based on declarative protocols\[[8](https://arxiv.org/html/2606.05043#bib.bib8),[9](https://arxiv.org/html/2606.05043#bib.bib9),[3](https://arxiv.org/html/2606.05043#bib.bib3),[5](https://arxiv.org/html/2606.05043#bib.bib5)\]support improved code structure and dealing with changing requirements\. Protocols are conceptual abstractions\. Not specifying them doesn’t mean they don’t have to be implemented\. It’s just that, absent explicit protocols, developers end up encoding the relevant interaction constraints directly in low\-level code, which is cumbersome and hides assumptions and errors\.

The Agentic AI paradigm has emerged concurrently with the advances in protocols\. Its basic value proposition is that LLM\-based agents will do all kinds of tasks on behalf of their users\. Many of these tasks will involve interacting with the agents of the other users, e\.g\., for shopping, booking travel, and so on\. This recognition has led to a flurry of industry efforts aimed at standardizing interactions between LLM agents\. Among the prominent ones are the Google\-led Universal Commerce Protocol \(UCP\)\[[17](https://arxiv.org/html/2606.05043#bib.bib17)\], which standardizes e\-commerce interactions such as checkout and order processing, and the Agent2Agent \(A2A\) protocol\[[1](https://arxiv.org/html/2606.05043#bib.bib1)\], which provides a general\-purpose framework for interagent task delegation\. These protocols are specified informally in terms of JSON schemas, prose descriptions, and example HTTP traces\.

*Contributions\.*Our objective is to establish the relevance of the “academic” declarative approaches for “practical” uses\. To this end, we contribute*Strabo*, a general method for exploiting declarative protocols in Langshaw in the context of ongoing industry efforts that model protocols via JSON\-RPC or REST API calls\. The method has two components: \(1\) Mapping the industry effort into a Langshaw protocol and implementing agents using Peach\[[5](https://arxiv.org/html/2606.05043#bib.bib5)\], a programming model for Langshaw, and \(2\) Creating a bridge layer that enables Peach agents to interoperate with industry agents, thus demonstrating interoperation with legacy agents built with conventional methods\.

We explain Strabo by modeling UCP’sCheckoutcapability as a Langshaw protocol and implementing Peach agents to enact that protocol\. We demonstrate the interoperability of these Peach agents with sample agents available in a UCP code repository111UCP sample code is available at[https://github\.com/Universal\-Commerce\-Protocol/samples](https://github.com/Universal-Commerce-Protocol/samples)to establish the fidelity of the Langshaw protocol with respect to UCP\.

This exercise establishes that formal, declarative protocols are directly applicable to industry efforts\. Whereas UCP is informally specified, leaving important aspects ambiguous, the Langshaw model of UCP specifies interaction constraints formally, bringing precision without sacrificing practical interoperability\. Our exercise also surfaced implicit assumptions in UCP and revealed enhancements required by Langshaw and Peach\.

## 2Background on UCP, Langshaw, and Peach

We now describe the existing approaches that we build upon in this paper\.

### 2\.1UCP, the Universal Commerce Protocol

UCP addresses e\-commerce interactions involving the roles ofPlatform\(customer\),Business\(merchant\),Credential Provider\(digital wallets\), andPayment Provider\(e\.g\., PayPal and Stripe\)\. The idea is thatPlatform, as representative of the shopper, shops withBusinessand uses theCredential Providerto generate payment tokens that theBusinessredeems with thePayment Provider\.

A typical UCP interaction proceeds as follows\. BothPlatformandBusinesspublish UCP profiles that list their capabilities\. Capabilities are the broad activities involved in an e\-commerce interaction, such asCheckout,Order, andIdentity Linking\(for computing loyalty rewards, and so on\)\. Capabilities may be extended\. For example,FulfillmentextendsCheckoutto support the delivery of physical goods\. Based on its own profile and that ofPlatform,Businessdetermines if they can interoperate\.

#### 2\.1\.1Capabilities\.

A capability is defined by a JSON schema\. Table[1](https://arxiv.org/html/2606.05043#S2.T1)gives some fields in theCheckoutcapability \(the full schema is in Appendix[0\.A](https://arxiv.org/html/2606.05043#Pt0.A1)\)\.

Table 1:TheCheckoutcapability \(extracted from\[[17](https://arxiv.org/html/2606.05043#bib.bib17)\]\)\.
#### 2\.1\.2Operations\.

All operations on an instance of theCheckoutcapability—i\.e\.,Create,Get,Update,Complete, andCancel—are performed byPlatform\. Each operation specifies an input and an output schema comprising required and optional fields\. The output schema specifiesCheckoutinstances that are returned byBusinessin response\.Businessrecomputes the instance based on the input in anUpdate\. Listings[1](https://arxiv.org/html/2606.05043#LST1)and[2](https://arxiv.org/html/2606.05043#LST2), with minor divergences from UCP documentation, show aCreateand its \(truncated\) response\.

Listing 1:ACreateoperation\.POST/checkout\-sessionsHTTP/1\.1

\{”line\_items”:\[

\{”item”:\{

”id”:”item\_123”,

”title”:”RedT\-Shirt”,

”price”:2500\},

”id”:”li\_1”,”quantity”:2\}\]\}

Listing 2:Response to Listing[1](https://arxiv.org/html/2606.05043#LST1)\(truncated\)\.HTTP/1\.1201Created

\{

”id”:”chk\_1234567890”,

”status”:”incomplete”,

”messages”:\[\{”type”:”error”,”code”:”missing”,

”path”:”$\.buyer\.email”,

”content”:”Buyeremailisrequired”\}\],

”currency”:”USD”,

”totals”:\[\{”type”:”subtotal”,”amount”:5000\},

\{”type”:”tax”,”amount”:400\},

\{”type”:”total”,”amount”:5400\}\],

”payment”:\{”instruments”:\[\]\},

”line\_items”:\[\],”links”:\[\]

\}

The response indicates that the buyer’s email is missing\.Platformaddresses this exception with anUpdate\(PUT /checkout\-sessions/\{id\}\) that supplies thebuyerand, optionally, thefulfillmentfields;Businessrecomputes and returns the full instance\. Once the instance reaches statusready\_for\_complete,PlatformsendsComplete\(POST /checkout\-sessions/\{id\}/complete\) with payment instrument data\.

### 2\.2Langshaw

Langshaw\[[16](https://arxiv.org/html/2606.05043#bib.bib16)\]is a declarative protocol language for specifying multiagent interactions\. We illustrate its concepts using the checkout protocol in Listing[3](https://arxiv.org/html/2606.05043#LST3), which we discuss in detail in Section[3](https://arxiv.org/html/2606.05043#S3)\.

A Langshaw protocol defines*who*interacts \(roles\),*what*constitutes a complete enactment, and*what they do*\(actions with attributes\)\. Thewhoclause names the roles—in our example,PlatformandBusiness\. Thedoclause lists actions, each performed by a specific role and with some attributes\. For instance,Createis performed byPlatformand carries attributes such asline\_itemsandbuyer\.

Some attributes are designated as*key*\. Keys correlate actions into*enactments*, that is, protocol instances\. A protocol declares one or more attributes as keys in itswhatclause; all actions bearing the same key values belong to the same enactment\. InSimpleUCP,cidis the sole key, so all actions sharing acidvalue constitute one checkout session\.

An attribute can only be bound once within a given enactment; once bound, it is immutable\. Performing an action either reuses the binding of each parameter or generates a new one\. Action names are themselves bound as attributes when the action occurs, so an action that references another action’s name depends on it having occurred\. For example,CreatedreferencesCreate, establishing a causal dependency:Createdcan only occur afterCreate\.

Thesaysoclause assigns data ownership—which role may bind which attributes\. In the simplest case, a sayso entry gives a role absolute ownership over an attribute: only that role may produce its binding\. However, sayso entries may also specify priority orderings among roles, allowing controlled sharing of attributes where one role’s binding takes precedence over another’s\. Thenonoclause declares mutual exclusion \(e\.g\.,CompletedandCancelledcannot both occur in the same enactment\), and thenogoclause declares directional exclusion \(e\.g\., onceCanceloccurs,Completeis blocked, but not vice versa\)\. Thewhatclause also specifies a completion goal: which actions must occur for an enactment to be considered complete\.

### 2\.3Peach

Peach\[[5](https://arxiv.org/html/2606.05043#bib.bib5)\]is a programming model for building agents that participate in Langshaw protocols\. A developer instantiates aPeachAdapter\(our tooling\) by specifying a protocol, the role the agent plays, and an executor that handles communication and the underlying state model\. The adapter implements the protocol’s semantics: it tracks which actions are feasible given the current state of the enactment, enforces sayso and causal dependencies, and manages key correlation\. Developers build agent logic on top of this adapter rather than reimplementing protocol constraints in application code\.

The adapter exposes a small API\. Crucially,adapter\.enabled\(\)returns the actions the agent may currently perform, given the enactment state\. The developer selects an action, binds its attribute values viaFeasibleAction\.bind\(\), and submits the result viaadapter\.attempt\(\), which returns a promise\. The promise resolves when the action is finalized or rejects if the action fails \(e\.g\., due to a conflicting concurrent action\), allowing the developer to handle failures explicitly\. To react to other agents’ actions, the developer registers observation handlers using the@adapter\.observationdecorator\. A@adapter\.on\_completionhandler fires when the protocol’s completion goal is satisfied\. This API is the same regardless of the executor: Peach currently supports a synchronous executor that connects to aSyncServerproviding shared state with either instant or batched finalization, and an asynchronous executor based on direct message passing\.

A key aspect of Peach is its enablement\-based programming model \(from BSPL\[[13](https://arxiv.org/html/2606.05043#bib.bib13)\]and Kiko\[[9](https://arxiv.org/html/2606.05043#bib.bib9)\]\)\. Rather than requiring the developer to determine which actions are valid after each event—consulting the protocol specification and encoding the operational logic in event handlers—the adapter computes the set of currently feasible actions and presents them directly\. The developer \(or, in principle, an LLM operating the agent\) simply selects from the enabled actions and provides bindings\. This shifts the burden of protocol compliance entirely to the adapter: the developer makes domain decisions, not protocol decisions\.

Operationally, each adapter computes enabled actions from the protocol and the current state of the enactment, and concurrent attempts within the Peach MAS are reconciled at the SyncServer using its configured finalization policy \(instant or batched\)\. Because correlation is by key, agents engaged in overlapping enactments do not interfere; each enactment’s state is independent\. A formal operational semantics is given in\[[5](https://arxiv.org/html/2606.05043#bib.bib5)\]\.

## 3Modeling UCP in Langshaw

There are potentially several ways of capturing UCP’sCheckoutcapability in Langshaw\. We focus here on an*atomic*variant that captures the simplest complete checkout: all information is submitted in a single action, exposing the essential data dependencies and completion conditions\. An*incremental*variant that decomposes updates into separate actions, making data flow and authority explicit, is given in Appendix[0\.C](https://arxiv.org/html/2606.05043#Pt0.A3)\. Our exercise surfaces several assumptions that UCP leaves implicit\.

### 3\.1A Closer Look at UCPCheckout

We make the following remarks about UCP\.

1. R1EachCheckoutinstance has a unique identifier\. Instances are thought of as*sessions*\. TheCreatedoes not bear the instance identifier\. It is generated in the response\.
2. R2Some fields, e\.g\.,id, are atomic whereas others, e\.g\.,line\_items, are composite\.
3. R3Some fields, e\.g\.,line\_items, are*required*in an instance; others, e\.g\.,buyer, are optional\. An operation’s response may additionally specify some of the optional fields, e\.g\.,orderin the response to aComplete, as required\.
4. R4Updates can be partial, possibly overriding existing information\.
5. R5Operations are conceptually request\-response in nature, as is evident from their input\-output style specification\.
6. R6UCP implicitly assumes a synchronous model for operations\. Specifically,Platformmay issue an operation on an instance only after the previous operation on the instance has returned a response\. Otherwise,PlatformandBusinesscould have incompatible views of the instance\. To see this, supposePlatformperforms anUpdateon an instance and, before it receives a response, also performs aCompleteon it\. Now, ifCompleteis processed byBusinessbeforeUpdate\(maybe becauseUpdateis delayed in the network\), theorderplaced may not reflect the intentions ofPlatform\.

### 3\.2UCP in Langshaw

Listing[3](https://arxiv.org/html/2606.05043#LST3)givesSimpleUCP, a checkout protocol in Langshaw that captures the UCP checkout interactions\. The protocol is*atomic*in the sense thatPlatformsubmits all checkout information in a singleCreateaction;Businessresponds with eitherCreated\(bearing the server\-generatedid\) orFailed\(bearingreason, indicating that creation was rejected—e\.g\., due to missing required fields or a server error\)\. If the checkout was created successfully,PlatformmayCompleteorCancelit; a successfulCompleteyields aCompletedaction carrying theorderdetails\.

Listing 3:SimpleUCPcheckout protocol in Langshaw\.SimpleUCP

whoPlatform,Business

whatcidkey,CompletedorFailed

do

Platform:Create\(cid,line\_items,currency,buyer,payment\_pref,discount\_codes,fulfillment\_pref\)

Business:Created\(cid,Create,id,totals,payment,discounts,fulfillment\)

Business:Failed\(cid,Create,reason\)

Platform:Complete\(cid,Created,id,payment\_data,risk\_signals\)

Business:Completed\(cid,Complete,order\)

Platform:Cancel\(cid,Created,id\)

sayso

Platform:line\_items,currency,buyer,discount\_codes,fulfillment\_pref,payment\_pref,payment\_data,risk\_signals

Business:id,totals,payment,discounts,fulfillment,order,reason

nono

CompletedFailed

CreatedFailed

Thenonoclauses enforce mutual exclusion among outcomes:CreatedandFailedcannot both occur in a session \(creation either succeeds or fails\), andCompletedandFailedcannot both occur \(a completed checkout cannot also be failed\)\. Because there is nononobetweenCompleteandCancel,Platformmay emit both concurrently\. How they are resolved depends on the synchronization server configuration: an instant\-resolution server processes them in arrival order, so the first received wins; a batch\-resolution server may accept both as pending and deliver them together, leaving it toBusinessto decide which to honor and respond to\.

Table[2](https://arxiv.org/html/2606.05043#S3.T2)shows the mapping from UCP operations toSimpleUCPactions\. Notice that UCP’sUpdateis realized inSimpleUCPvia two actions: theCancelof the existing checkout and theCreateof a new one\.

Table 2:Mapping from UCP operations to SimpleUCP actions\. Get is unused because the adapter tracks protocol state\. Update is realized at the protocol level by the Platform agent issuing \(Cancel, Create\); on the wire, the outbound Create itself is a POST followed by a PUT to supply fields UCP does not accept in the initial request\.

## 4Programming Peach UCP Agents

We now show how developers build agents for a Langshaw protocol using Peach\. The central point is the separation of concerns: agent code contains only domain decisions \(which actions to take and what values to bind\), whereas the adapter handles protocol compliance, key correlation, and communication\. We show aPlatformagent and aBusinessproxy agent forSimpleUCP\.

### 4\.1PlatformAgent

ThePlatformagent drives the checkout process\. Listing[4](https://arxiv.org/html/2606.05043#LST4)shows the adapter setup: the developer loads a protocol, creates an adapter for thePlatformrole, and registers handlers for observations and protocol completion\. Listing[5](https://arxiv.org/html/2606.05043#LST5)shows the enablement\-driven handlers, each invoked by the adapter when its action becomes feasible\. The adapter also ensures consistency and correctness by presenting only currently valid actions, propagating bindings from prior observations, and accepting viaFeasibleAction\.bind\(\)only attributes the agent has sayso over\.

Listing 4:Platformagent core: adapter setup and observation handlers\.protocol=LangshawProtocol\.load\(”protocols/atomic\-ucp\.lsh”\)

adapter=PeachAdapter\(”platform”,protocol,”Platform”,executor\)

done=asyncio\.Event\(\)

@adapter\.on\_completion

asyncdefon\_done\(keys,mas\_id\):

done\.set\(\)

@adapter\.observation\(’Created’,’Failed’,’Completed’\)

asyncdefon\_observation\(action,performer\):

print\(f”Observed␣\{action\.action\.name\}␣by␣\{performer\}”\)

Listing 5:Platformagent enablement\-driven handlers: the adapter invokes each handler when its action becomes feasible\.@adapter\.on\_enabled\(’Create’\)

asyncdefon\_create\_enabled\(fa\):

awaitadapter\.attempt\(\[fa\.bind\(

line\_items=SAMPLE\_LINE\_ITEMS,currency=”USD”,

buyer=SAMPLE\_BUYER,payment\_pref=\{\},

discount\_codes=\{”codes”:\[\]\},

fulfillment\_pref=SAMPLE\_FULFILLMENT\_PREF\)\]\)

@adapter\.on\_enabled\(’Complete’\)

asyncdefon\_complete\_enabled\(fa\):

awaitadapter\.attempt\(\[fa\.bind\(

payment\_data=SAMPLE\_PAYMENT\_DATA,

risk\_signals=\{”ip”:”127\.0\.0\.1”\}\)\]\)

## 5Interoperation with Google’s UCP Agents

### 5\.1Architecture

Figure[1](https://arxiv.org/html/2606.05043#S5.F1)shows the runtime architecture\. The Peach MAS comprises aPlatformagent that drives the checkout flow and aBusinessproxy adapter that bridges to the external merchant\. Both sides share access to a SyncServer that maintains the protocol’s social state\. When thePlatformagent performs aSimpleUCPaction, the SyncServer notifies theBusiness Proxy, which uses its built\-in field mapping to construct one or more corresponding UCP requests, sends them to the actual UCPBusinessover HTTP, parses the responses, and performs the correspondingSimpleUCPaction\. Field\-name translation is configured inline via theroute\(\)DSL; neither thePlatformagent nor the proxy contains hand\-written HTTP code, with the only imperative code being orchestration for actions that map to multiple HTTP calls \(such asCreate, which requires aPOSTfollowed by aPUT\)\.

Peach MASBusiness ProxyExternalPlatformAgentSyncServerProxyAdapterUCP Business\(Google\)SimpleUCPSimpleUCPREST UCPFigure 1:Strabo Architecture\. The Peach MAS interoperates with Google’s UCP merchant via a Strabo proxy, which translates Langshaw actions inSimpleUCPto REST calls using built\-in field mapping configured via theroute\(\)DSL\.
### 5\.2Proxy

The proxy bridges the Langshaw protocol to the external merchant HTTP API\.ProxyAdapteris aPeachAdaptersubclass with built\-in HTTP client and field mapping\. Routes are defined via theroute\(\)DSL, and for each route, the adapter auto\-registers an observation handler that fires the HTTP request and submits the response action\. ForSimpleUCP,Createrequires orchestration: a single LangshawCreatemaps to a POST to/checkout\-sessionsfollowed by a PUT \(to supply fields likediscountsandfulfillmentthat UCP does not accept in the initial request\)\. Listing[6](https://arxiv.org/html/2606.05043#LST6)shows the core of the proxy: routes are declared inline, and theCreateaction is excluded from auto\-proxy so that a custom handler can orchestrate the two HTTP calls\. All other actions \(e\.g\.,Complete,Cancel\) are handled automatically\.

Listing 6:ProxyAdaptersetup withroute\(\)DSL and customCreateorchestration\.proxy=ProxyAdapter\(

”atomic\_proxy”,protocol,”Business”,executor,

base\_url=merchant\_url,internal=\[”cid”\],

header\_hook=ucp\_header\_hook,exclude=\[”Create”\]\)

proxy\.route\(”Create␣\-\>␣Created”,”POST␣/checkout\-sessions”\)

proxy\.route\(”Update␣\-\>␣Updated”,”PUT␣/checkout\-sessions/\{id\}”,

request=\{”discount\_codes”:”$\.discounts”,

”fulfillment\_pref”:”$\.fulfillment”,

”payment\_pref”:”$\.payment”\}\)

proxy\.route\(”Complete␣\-\>␣Completed”,

”POST␣/checkout\-sessions/\{id\}/complete”\)

proxy\.route\(”Cancel␣\-\>␣Cancelled”,

”POST␣/checkout\-sessions/\{id\}/cancel”\)

@proxy\.observation\(’Create’\)

asyncdefon\_create\(action,performer\):

ifperformer==proxy\.name:return

create\_resp=awaitproxy\.request\(”Create”,

\{k:action\.bindings\[k\]

forkin\(”line\_items”,”currency”,”buyer”\)\}\)

update\_resp=awaitproxy\.request\(”Update”,

\{\*\*action\.bindings,”id”:create\_resp\[”id”\]\}\)

combined=\{\*\*action\.bindings,\*\*create\_resp,\*\*update\_resp\}

awaitproxy\.attempt\(\[proxy\.build\_action\(”Created”,combined\)\]\)

For eachroute\(\)declaration,ProxyAdapterauto\-generates an observation handler that fires when the trigger action is observed, sends the corresponding HTTP request, and submits a fixed response action back into the protocol\. This assumes a one\-to\-one mapping between request and response actions\. Protocols with alternative responses \(e\.g\.,Createyielding eitherCreatedorFaileddepending on the HTTP status\) are supported but require a custom observation handler that inspects the response and selects the appropriate action, as illustrated above forCreate\.

### 5\.3Field Mapping

Field mapping is configured inline via theroute\(\)DSL \(visible in Listing[6](https://arxiv.org/html/2606.05043#LST6)\)\. Eachroute\(\)call declares a round\-trip: a pair of Langshaw actions mapped to an HTTP endpoint\. The adapter supports three kinds of mappings\.*Identity*mappings require no configuration: when a Langshaw attribute name matches the corresponding JSON field name \(e\.g\.,buyer↔\\leftrightarrow$\.buyer\), the adapter translates automatically\.*Explicit*mappings handle cases where names differ: therequestandresponsekeyword arguments specify non\-identity translations \(e\.g\.,discount\_codes↔\\leftrightarrow$\.discounts, orpayment\_pref↔\\leftrightarrow$\.payment\)\.*Excluded*attributes—those declared viainternal—never appear in HTTP traffic \(e\.g\.,cid, which is the Langshaw enactment key\)\. The complete mapping between UCP fields andSimpleUCPattributes is given in Appendix[0\.B](https://arxiv.org/html/2606.05043#Pt0.A2)\.

### 5\.4Interactions

Figure[2](https://arxiv.org/html/2606.05043#S5.F2)shows the interactions for a completeSimpleUCPcheckout\. Each Langshaw action submitted byPlatformis intercepted by the proxy, translated into HTTP calls using the route’s field mapping, and the response is returned as a Langshaw observation—keeping thePlatformagent entirely free of HTTP concerns\.

\\includestandalone

figures/interaction\-flow

Figure 2:Interactions for aSimpleUCPcheckout via the proxy\.Platformspeaks Langshaw; the proxy bridges to the merchant’s HTTP API using its built\-in field mapping\. The proxy\-internalPUTsupplies fields \(e\.g\.,discountsandfulfillment\) that UCP does not accept in the initialPOST\. Solid arrows: requests; dashed: responses\.

## 6Evaluation

### 6\.1Evaluation Criteria

We evaluate our approach along four dimensions\.*Clarity*: Does the Langshaw specification make implicit assumptions explicit?*Generality*: Does the formalism naturally support protocol variants that UCP does not distinguish?*Fidelity*: Can Peach agents interoperate with Google’s UCP reference implementation?*Economy*: How much agent code is needed and what fraction is domain logic versus boilerplate?

### 6\.2Clarity and Generality

We focus on how theSimpleUCPLangshaw protocol addresses the UCP features noted in the remarks above\.

##### Checkout identity \(Remark[R1](https://arxiv.org/html/2606.05043#S3.I1.i1)\)\.

In UCP, checkouts are identified byid, which is generated byBusinessin response toPlatform’sCreate\. Such a model not only reflects a centralized mindset, but also is incompatible with meaning: Being unidentified, a UCPCreateby itself cannot be meaningful\. Since Langshaw’s purpose is to support meaning, it identifies every action instance\. InSimpleUCP, this is accomplished by declaringcidas the key for every action, includingCreate\. For compatibility with UCP,SimpleUCPintroduces the \(non\-key\) attributeid, over whichBusinesshas sayso; it is generated byBusinessinCreated, and is used byPlatformin subsequent actions such asCompleteandCancel\. For interoperation with Google’s sample agents, the proxies strip outcid\.

##### Atomic versus composite fields \(Remark[R2](https://arxiv.org/html/2606.05043#S3.I1.i2)\)\.

UCP distinguishes atomic fields \(e\.g\.,id, a string\) from composite ones \(e\.g\.,line\_items, an array of objects\)\. Langshaw treats all attributes uniformly; their internal structure is orthogonal to the protocol specification\. Peach handles atomic and composite values equally well by treating composite fields as opaque values compared using deep equality \(a built\-in Python feature over dictionaries\) and serializing all values for storage as JSON, which is compatible with the format received from UCP\.

##### Modeling optional attributes \(Remark[R3](https://arxiv.org/html/2606.05043#S3.I1.i3)\)\.

UCP marks certain fields as optional:buyer,fulfillment, anddiscount\_codesmay or may not be supplied\. One way to capture such optionality is via null values\. In theSimpleUCPprotocol, all attributes appear on theCreateaction\. An attribute that the agent does not wish to supply is bound to a null value; the proxy strips null\-valued fields before constructing the HTTP request\. This approach is concise but relies on a convention external to the protocol specification: Langshaw does not distinguish a deliberately null binding from a missing one\. A better approach would be to add support foroptionalaction attributes in the Langshaw language\. We leave this extension as future work\.

The incremental variant in Appendix[0\.C](https://arxiv.org/html/2606.05043#Pt0.A3)avoids null values altogether by giving each optional concern its own action\.

##### Overwrite semantics \(Remark[R4](https://arxiv.org/html/2606.05043#S3.I1.i4)\)\.

UCP allowsPlatformto selectively update fields that have already been bound in a session\. In Langshaw, attributes may be bound at most once in an enactment; they are immutable thereafter\. Moreover,SimpleUCPmodels a checkout as a complete, immutable object\. To revise a checkout,Platformcancels the current session and creates a new one with the updated data—a cancel\-and\-recreate pattern that is semantically equivalent to an in\-place update\. This comes at some cost: aCancelis ambiguous, as observers cannot distinguish a genuine user cancellation from a revision\. In exchange, each session has a definitive state, and it is always clear which version of the checkout is being completed\. Mutable amendment would conflict with Langshaw’s commitment to immutability, which lets agents reason about enactment state without a shared mutable store\. The incremental variant’s version key \(Appendix[0\.C](https://arxiv.org/html/2606.05043#Pt0.A3)\) is the principled counterpart to UCP’s in\-place update: each amendment is a fresh subenactment, and the application interprets the collection of versions as its domain requires \(e\.g\., treating the highest sortablevas authoritative\)\. The incremental versioning example is deliberately minimal; a richer structure—e\.g\., recording parent–child lineage or scoping versioning to attribute groups—could more closely reflect UCP’s selective\-update semantics without relaxing immutability\.

##### Request\-response and synchronous ordering \(Remarks[R5](https://arxiv.org/html/2606.05043#S3.I1.i5)and[R6](https://arxiv.org/html/2606.05043#S3.I1.i6)\)\.

UCP operations are conceptually request\-response pairs, and UCP implicitly assumes that operations on a session are issued sequentially\. Langshaw replaces both conventions with structural causal dependencies: an action that references another action’s name can only occur after it\.SimpleUCPis inherently synchronous—a singleCreate–Completeexchange—so no additional ordering mechanism is needed\. The incremental variant makes the design choice explicit by declaringv\(version\) as key \(Appendix[0\.C](https://arxiv.org/html/2606.05043#Pt0.A3)\)\. Attribute binding authority, implicit in UCP’s JSON schemas, is made explicit throughsayso\.

UCP additionally requires idempotency keys in HTTP headers to prevent the server from reprocessing a duplicate request and repeating side\-effects \(e\.g\., creating a second order\)\. The UCP sample generates a fresh random key per request \(Listing[7](https://arxiv.org/html/2606.05043#LST7)\), which provides protection only at the network level—where the same request is resent with its original headers intact—but not against application\-level retries where a new key would be generated\. In our implementation, idempotency key generation is encapsulated in theProxyAdapter, keeping this transport concern transparent to the agent\.

Table[3](https://arxiv.org/html/2606.05043#S6.T3)summarizes how each remark is addressed\.

Table 3:How Langshaw addresses assumptions implicit in UCP’s specification\.

### 6\.3Fidelity: Interoperation with Google’s UCP Agents

We tested interoperation end\-to\-end by connecting a PeachPlatformagent to Google’s UCP referenceBusinessserver via theProxyAdapter\. ThePlatformagent successfully completed checkout sessions with the Google server, with the adapter’s built\-in field mapping handling name translation and session ID correlation transparently\.

### 6\.4Economy: Comparison with Google’s UCP Agent

We compare the Peach agent implementation with a comparable agent built directly against Google’s UCP SDK\. In the Peach agent, ordering constraints, session management, and data ownership are enforced by the adapter—the agent code contains no ordering logic\. In the direct HTTP agent, the developer must manually track session identifiers, check status before completing \(e\.g\., verifyingready\_for\_complete\), and construct correct HTTP requests\. TheBusinessproxy is particularly compact: theProxyAdapterauto\-generates observation handlers fromroute\(\)declarations, so adding a new UCP capability \(e\.g\., Orders\) requires only a new protocol file and a few route definitions, not new agent code\.

Table[4](https://arxiv.org/html/2606.05043#S6.T4)compares lines of code across implementations\. The difference is most visible in equivalent operations\. Listings[7](https://arxiv.org/html/2606.05043#LST7)and[8](https://arxiv.org/html/2606.05043#LST8)show checkout creation in the direct HTTP client and the Peach agent, respectively\.

Listing 7:Checkout creation using the UCP SDK directly\.item1=ItemCreateRequest\(id=”bouquet\_roses”,title=”Red␣Rose”\)

line\_item1=LineItemCreateRequest\(quantity=1,item=item1\)

payment\_req=PaymentCreateRequest\(

instruments=\[\],selected\_instrument\_id=None,

handlers=supported\_handlers\)

buyer\_req=Buyer\(full\_name=”John␣Doe”,email=”john@example\.com”\)

create\_payload=CheckoutCreateRequest\(

currency=”USD”,line\_items=\[line\_item1\],

payment=payment\_req,buyer=buyer\_req\)

headers=get\_headers\(\)

json\_body=create\_payload\.model\_dump\(

mode=”json”,by\_alias=True,exclude\_none=True\)

response=client\.post\(

”/checkout\-sessions”,json=json\_body,headers=headers\)

checkout\_id=response\.json\(\)\.get\(”id”\)

Listing 8:Checkout creation using the Peach adapter\.@adapter\.on\_enabled\(’Create’\)

asyncdefon\_create\_enabled\(fa\):

awaitadapter\.attempt\(\[fa\.bind\(

line\_items=SAMPLE\_LINE\_ITEMS,currency=”USD”,

buyer=SAMPLE\_BUYER,payment\_pref=\{\}\)\]\)

Table 4:Lines of code comparison for the Checkout capability, with our Peach agent asPlatformand the Google sample asBusiness\. TheBusinessproxy includes inlineroute\(\)declarations for field mapping\.

## 7Discussion

Agent2Agent \(A2A\)\[[1](https://arxiv.org/html/2606.05043#bib.bib1)\], originally developed by Google and now managed by the Linux Foundation, is a widely adopted protocol for interagent task delegation\. A client discovers remote agents via*AgentCard*s and delegates tasks; tasks progress through states \(submitted,working,completed,failed,canceled\) and may involve multiturn conversations\. A2A and UCP are complementary: A2A handles discovery and delegation while UCP handles domain\-specific interactions such as checkout\. Like UCP, A2A is mostly informally specified; its state machine is described in prose, and constraints such as whether a canceled task may be resumed are ambiguous\. A2A’s*context identifier*is analogous to a Langshaw enactment key, and the bridge architecture presented here could equally apply: model the A2A task lifecycle as a Langshaw protocol and bridge to A2A’s JSON\-RPC transport\.

Baldoni et al\.\[[2](https://arxiv.org/html/2606.05043#bib.bib2)\]recently demonstrated BSPL integration with the SARL agent language, exploring a different point in the implementation design space\.

Chopra et al\.\[[6](https://arxiv.org/html/2606.05043#bib.bib6)\]survey the IOP toolkit Strabo builds on—protocol languages, verifiers, and programming models\. Strabo’s contribution is not in expressiveness or execution semantics, which are inherited from Langshaw and Peach, but in the bridge architecture: theProxyAdapterandroute\(\)DSL map declarative actions onto informally\-specified HTTP APIs, letting new capabilities be added by writing a protocol and a few routes rather than new agent code\.

Strabo is concerned with bridging formal protocols to existing HTTP APIs\. Chopra and Singh\[[7](https://arxiv.org/html/2606.05043#bib.bib7)\]recently proposed Fluid, which brings social norms to web\-based multiagent systems—a complementary direction that could inform how normative constraints are layered atop protocols like those modeled here\.

Historically, agent communication was standardized through FIPA\-ACL\[[11](https://arxiv.org/html/2606.05043#bib.bib11)\]and KQML\[[10](https://arxiv.org/html/2606.05043#bib.bib10)\], which focused on speech\-act semantics for individual messages\. UCP and A2A represent a new generation of industry protocols that emphasize structured interactions, but share with their predecessors the challenges of informal specification and inadequate support for meaning\[[12](https://arxiv.org/html/2606.05043#bib.bib12)\]\.

The end\-to\-end test demonstrates feasibility but is not an exhaustive evaluation of protocol conformance\.

## 8Conclusion

We have shown that formal, declarative MAS protocol techniques are directly applicable to industry e\-commerce protocols\. Modeling UCP’s Checkout capability in Langshaw made explicit several assumptions—most notably around attribute binding authority and ordering—that UCP’s informal specification leaves implicit\. The Langshaw formalism naturally supports protocol variants that UCP does not distinguish, exposing a design space that practitioners can reason about; an incremental variant is explored in Appendix[0\.C](https://arxiv.org/html/2606.05043#Pt0.A3)\. Peach agents built against the Langshaw protocol interoperate with Google’s UCP reference implementation via Strabo’sProxyAdapter, which bridges protocol actions to HTTP round\-trips with inline field mapping, demonstrating that formal specification and practical interoperability are not at odds\. Industry protocols like UCP and A2A are defining the interaction patterns for AI\-assisted commerce and multiagent coordination; our exercise demonstrates that MAS protocol research can contribute precision and verifiability to these efforts\.

This exercise was focused on operations in the UCPCheckoutcapability; UCP additionally includesOrder,Identity Linking, and extensible capabilities, each of which would need its own protocol and route definitions\. We model only thePlatform–Businessinteractions; the protocol also involves roles corresponding to credential and payment providers\. Extending Strabo to address additional capabilities and roles should be a rewarding direction, potentially testing Langshaw’s support for protocol composition \(a core facility in BSPL\) and dynamic role bindings \(supported in Splee\[[4](https://arxiv.org/html/2606.05043#bib.bib4)\], a BSPL extension\)\.

Several directions remain for future work\. Addingoptionalattribute support to Langshaw would address the null\-value convention thatSimpleUCPcurrently relies on, making optionality a first\-class protocol concept rather than an implementation convention\. The bridge architecture generalizes beyond UCP: A2A’s task lifecycle could be modeled as a Langshaw protocol and bridged to its JSON\-RPC transport, testing the approach against a complementary industry standard with a different interaction style\. Finally, a benefit of Langshaw that we did not exploit is decentralized enactments—where each agent maintains its own local view of the protocol state without a shared server\. Exploiting this property would enable peer\-to\-peer agent interaction more naturally aligned with the distributed nature of agentic AI deployments, and would test whether theProxyAdapterarchitecture extends to settings without central coordination\.

## References

- \[1\]A2A: Agent2Agent protocol \(2025\),[https://a2aprotocol\.ai/](https://a2aprotocol.ai/), last accessed: 2025\-08\-11
- \[2\]Baldoni, M\., Baroglio, C\., Galland, S\., Micalizio, R\., Outay, F\., Tedeschi, S\.: Interaction protocols in an imperative agent\-oriented programming language: The case of BSPL and SARL\. In: Proceedings of the 24th International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. pp\. 2426–2427\. IFAAMAS, Detroit \(May 2025\)\. https://doi\.org/10\.5555/3709347\.3743891
- \[3\]Baldoni, M\., Christie V, S\.H\., Singh, M\.P\., Chopra, A\.K\.: Orpheus: Engineering multiagent systems via communicating agents\. In: Proceedings of the 39th AAAI Conference on Artificial Intelligence \(AAAI\)\. pp\. 23135–23143\. AAAI, Philadelphia \(Feb 2025\)\. https://doi\.org/10\.1609/aaai\.v39i22\.34478
- \[4\]Chopra, A\.K\., Christie V, S\.H\., Singh, M\.P\.: Splee: A declarative information\-based language for multiagent interaction protocols\. In: Proceedings of the 16th International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. pp\. 1054–1063\. IFAAMAS, São Paulo \(May 2017\)\. https://doi\.org/10\.5555/3091125\.3091274
- \[5\]Chopra, A\.K\., Christie V, S\.H\., Singh, M\.P\.: Peach: Program each agent and communicate howsoever\. In: Proceedings of the 25th International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. IFAAMAS, Paphos, Cyprus \(May 2026\), accepted
- \[6\]Chopra, A\.K\., Christie V, S\.H\., Singh, M\.P\.: Tools for implementing multiagent systems based on protocols\. In: Collier, R\., Mascardi, V\., Ricci, A\. \(eds\.\) Agents and Multi\-Agent Systems Development: Platforms, Toolkits, Technologies, chap\. 8, pp\. 211–230\. Springer Nature, Cham, Switzerland \(2026\)\. https://doi\.org/10\.1007/978\-3\-032\-01082\-7\_8
- \[7\]Chopra, A\.K\., Singh, M\.P\.: Fluid: Social norms\-based multiagent systems on the Web\. In: In Proceedings of the 13th Engineering Multiagent Systems Workshop\. LNCS, vol\. 16407, pp\. 62–79\. Springer \(2025\)
- \[8\]Christie V, S\.H\., Chopra, A\.K\., Singh, M\.P\.: Mandrake: Multiagent systems as a basis for programming fault\-tolerant decentralized applications\. Journal of Autonomous Agents and Multi\-Agent Systems \(JAAMAS\)36\(1\), 16:1–16:30 \(Apr 2022\)\. https://doi\.org/10\.1007/s10458\-021\-09540\-8
- \[9\]Christie V, S\.H\., Singh, M\.P\., Chopra, A\.K\.: Kiko: Programming agents to enact interaction protocols\. In: Proceedings of the 22nd International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. pp\. 1154–1163\. IFAAMAS, London \(May 2023\)\. https://doi\.org/10\.5555/3545946\.3598758
- \[10\]Finin, T\., Fritzson, R\., McKay, D\., McEntire, R\.: KQML as an agent communication language\. In: Proceedings of the 3rd International Conference on Information and Knowledge Management\. pp\. 456–463\. ACM Press, Gaithersburg, Maryland \(Dec 1994\)\. https://doi\.org/10\.1145/191246\.191322
- \[11\]FIPA: FIPA agent communication language specifications\.[http://www\.fipa\.org/repository/aclspecs\.html](http://www.fipa.org/repository/aclspecs.html)\(2002\), FIPA: The Foundation for Intelligent Physical Agents\. Accessed 2025\-01\-20
- \[12\]Singh, M\.P\.: Agent communication languages: Rethinking the principles\. IEEE Computer31\(12\), 40–47 \(Dec 1998\)\. https://doi\.org/10\.1109/2\.735849
- \[13\]Singh, M\.P\.: Information\-driven interaction\-oriented programming: BSPL, the Blindingly Simple Protocol Language\. In: Proceedings of the 10th International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. pp\. 491–498\. IFAAMAS, Taipei \(May 2011\)\. https://doi\.org/10\.5555/2031678\.2031687
- \[14\]Singh, M\.P\.: Semantics and verification of information\-based protocols\. In: Proceedings of the 11th International Conference on Autonomous Agents and MultiAgent Systems \(AAMAS\)\. pp\. 1149–1156\. IFAAMAS, Valencia, Spain \(Jun 2012\)\. https://doi\.org/10\.5555/2343776\.2343861
- \[15\]Singh, M\.P\., Christie V, S\.H\.: Tango: Declarative semantics for multiagent communication protocols\. In: Proceedings of the 30th International Joint Conference on Artificial Intelligence \(IJCAI\)\. pp\. 391–397\. IJCAI, Online \(Aug 2021\)\. https://doi\.org/10\.24963/ijcai\.2021/55
- \[16\]Singh, M\.P\., Christie V, S\.H\., Chopra, A\.K\.: Langshaw: Declarative interaction protocols based on sayso and conflict\. In: Proceedings of the 33rd International Joint Conference on Artificial Intelligence \(IJCAI\)\. pp\. 202–210\. IJCAI, Jeju, Korea \(Aug 2024\)\. https://doi\.org/10\.24963/ijcai\.2024/23
- \[17\]UCP: Universal commerce protocol \(Jan 2026\),[https://ucp\.dev](https://ucp.dev/), last accessed: 2026\-02\-20

## Appendix 0\.ACheckoutCapability

Table[5](https://arxiv.org/html/2606.05043#Pt0.A1.T5)gives the complete specification of theCheckoutcapability\.

Table 5:TheCheckoutcapability \(extracted from\[[17](https://arxiv.org/html/2606.05043#bib.bib17)\]\)\.
## Appendix 0\.BMapping Between UCP Fields andSimpleUCPAttributes

Table[6](https://arxiv.org/html/2606.05043#Pt0.A2.T6)gives the complete field\-to\-attribute mapping used by theProxyAdapter\. Identity mappings use the same name on both sides\. Explicit mappings arise where UCP andSimpleUCPuse different names for the same data\. Fields marked*dropped*have no protocol equivalent inSimpleUCPbecause their information is either implicit in the action sequence or unnecessary for the Langshaw model\.

UCP FieldSimpleUCPAttributeMappingCheckout response fieldsucp—dropped \(protocol metadata\)idididentityline\_itemsline\_itemsidentitybuyerbuyeridentitystatus—dropped \(implicit in action sequence\)currencycurrencyidentitytotalstotalsidentitymessagesreasonpartial \(error messages→\\toFailed\)links—droppedexpires\_at—droppedcontinue\_url—droppedpaymentpaymentidentity \(inCreated\)orderorderidentity \(inCompleted\)Request fields \(sent inUpdate/Complete\)discountsdiscount\_codesexplicit \(route\(\)DSL\)fulfillmentfulfillment\_prefexplicit \(route\(\)DSL\)paymentpayment\_prefexplicit \(route\(\)DSL\)payment\_datapayment\_dataidentityrisk\_signalsrisk\_signalsidentityLangshaw\-internal \(not in UCP\)—cidenactment key; stripped by proxyTable 6:Mapping between UCP fields andSimpleUCPattributes\. UCP’spaymentfield is overloaded: in request context it carries payment preferences \(payment\_pref\); in response context it carries payment configuration \(payment\)\.
## Appendix 0\.CIncrementalCheckoutProtocol

The incremental protocol \(Listing[9](https://arxiv.org/html/2606.05043#LST9)\) generalizesSimpleUCPto support UCP’s multistep update flow\. Rather than submitting all information in a singleCreate,Platformmay issue separate actions for each concern:SetBuyer,ApplyDiscounts,SetFulfillment, andSetPayment, each carrying only its own attributes\.Businessresponds to each with a corresponding acknowledgment\. This decomposition makes data flow explicit—each action pair affects only the attributes it names\. Regarding optional attributes \(Remark[R3](https://arxiv.org/html/2606.05043#S3.I1.i3)\): each concern has its own action, so the agent simply omits any action it does not need\. No null values are required; the protocol specification itself captures which combinations of actions are valid\.

The incremental protocol introduces a second key,v, which serves as a version identifier\. Each mutation action and its response carryv, and since an attribute may only be bound once per composite key, successive mutations are distinguished by theirvvalues—each operates within its own subenactment\. This also addresses overwrite semantics \(Remark[R4](https://arxiv.org/html/2606.05043#S3.I1.i4)\): successive updates produce distinct bindings rather than overwriting previous ones, and agents can observe all bindings across subenactments to merge values and selectively override at the application level\. The version key does not itself impose ordering; however, the developer may choose sortable values \(e\.g\., ULIDs\) and operate on the latest version, achieving the sequential behavior that UCP assumes by convention \(Remark[R6](https://arxiv.org/html/2606.05043#S3.I1.i6)\)\. The protocol makes this design choice explicit\.

Listing 9:Incremental UCP checkout protocol in Langshaw\.IncrementalUCP

whoPlatform,Business

whateidkey,vkey,CompletedorCancelled

do

Platform:Create\(eid,line\_items,currency,buyer,payment\)

Business:Created\(eid,Create,id,payment\_config,messages\)

Business:StatusChange\(eid,Created,status,totals,messages\)

Platform:Update\(eid,v,Created,id,line\_items,currency\)

Business:Updated\(eid,v,Update,line\_items,messages\)

Platform:SetBuyer\(eid,v,Created,id,buyer\)

Business:BuyerSet\(eid,v,SetBuyer,buyer,messages\)

Platform:ApplyDiscounts\(eid,v,Created,id,discount\_codes\)

Business:DiscountsApplied\(eid,v,ApplyDiscounts,discounts\_applied,messages\)

Platform:SetFulfillment\(eid,v,Created,id,fulfillment\_pref\)

Business:FulfillmentSet\(eid,v,SetFulfillment,fulfillment,messages\)

Platform:SetPayment\(eid,v,Created,id,payment\_pref\)

Business:PaymentSet\(eid,v,SetPayment,payment\_config,messages\)

Platform:Complete\(eid,v,Create,id,payment\_data,risk\_signals\)

Business:Completed\(eid,v,Complete,order,messages\)

Platform:Cancel\(eid,v,Created,id\)

Business:Cancelled\(eid,v,Cancel,messages\)

Business:Shipped\(eid,Completed,order\_id,tracking\_number,tracking\_url,carrier\)

Business:Delivered\(eid,Shipped,order\_id\)

sayso

Platform:line\_items,currency,buyer,discount\_codes,fulfillment\_pref,payment\_pref,payment\_data,risk\_signals,payment

Business:id,status,totals,discounts\_applied,fulfillment,payment\_config,order,order\_id,tracking\_number,tracking\_url,carrier,messages

nono

CompletedCancelled

nogo

Cancel\-/\>Complete