git clone https://github.com/stateset/stateset-ucp-handler.gitcd stateset-ucp-handlerUCP_REQUIRE_UCP_AGENT=false UCP_REQUIRE_REQUEST_SIGNATURE=false cargo run# listens on http://0.0.0.0:8081
Those two flags disable caller authentication and are for local testing only. In production the
Request-Signature header is what authenticates writes — see the
integration guide for the signed setup.
One well-known document advertises what the merchant supports:
curl http://localhost:8081/.well-known/ucp
You get back the capability list — checkout, fulfillment, discounts, orders. A client should branch
on this rather than assuming; that is the point of the discovery step.
The response carries the session id and its state. Update it (address, shipping option, discount
code) with PUT /api/checkout-sessions/{id} as many times as needed.
curl -X POST http://localhost:8081/api/checkout-sessions/{id}/complete
Completion emits an order webhook — that, not the HTTP response, is the durable record of the
purchase. Check /api/webhook-deliveries to see it.
Enable the iCommerce backend to make this real: the session then reserves actual inventory and
creates an order in the embedded engine, instead of a protocol-level stub. See
UCP.
./demo_test.sh # exercises discovery → session → complete → order
The handler requires UCP-Agent on every request and Request-Signature on
writes. The local-testing flags that relax them turn off the only thing
authenticating the caller, so a handler started with them accepts a checkout
from anyone who can reach the port. Never set them on anything reachable
beyond your own machine.
