Guides · Hackathon walkthrough

Trailhead Outfitters: a merchant's agent that runs the whole sale on PayPal

Our entry for the PayPal AI Hackathon is a small storefront whose only employee is Avo, an AI agent that sells gear, does the pay-in-4 math, takes payment through PayPal Buttons with Pay Later and Venmo, and treats post-purchase as part of the sale: shipment tracking and dispute evidence included. This page walks a judge or a curious builder through the live demo in five minutes, with copy-paste commands for every claim.

Live · always-on Worker PayPal sandbox · no real money GLM 5.3 Flash agent Zero dependencies
Start here

A store where the employee is an agent

One sentence: everyone's agent can check out; ours handles the whole sale.

Trailhead Outfitters is Post Oak Labs' entry for the PayPal AI Hackathon. The storefront's only employee is Avo, an AI agent running on GLM 5.3 Flash from Z.ai that works the PayPal sandbox end to end: it sells from the catalog, does the pay-in-4 arithmetic, creates and captures orders, and answers questions after the sale. The shop is live on a Cloudflare Worker and the full source is on GitHub under MIT.

Everything on the site is sandbox money (fake accounts, fake balances), which is the best part: approve anything, click everything, then inspect the receipts in the sandbox business account's activity. The catalog is ten items on purpose; the point is the agent and the lifecycle, not the inventory.

The sale lifecycle: ask Avo, order, approve, capture, track 1 ask Avo 2 order 3 approve 4 capture 5 track
Fig 1 · the sale lifecycle: conversation → order → approval → capture → post-purchase
On this page
  1. The walkthrough · five steps in the live demo
  2. Hand test · copy-paste commands against the live endpoints
  3. Two MCP servers · storefront and PayPal, cross-verifying
  4. Under the hood · a zero-dependency server with a gate per behavior
The walkthrough

Five steps from conversation to capture

Everything below runs against the live deployment; the PayPal side is the sandbox, so any purchase is safe and fully inspectable afterward in the sandbox business account's activity.

  • 1

    Open the store and talk to Avo

    The storefront is a chat. Ask it something a real customer would: "I need a tent under $300". Avo searches the catalog, quotes the Scree 2P at $289, and, because the purchase is over $100, volunteers the pay-in-4 arithmetic: four payments of $72.25, zero fees.

    Under the hood: Avo is a GLM tool-calling loop over search_catalog, compute_financing, create_order, and get_order, with a permanent scope gate that keeps the event path from regressing.
  • 2

    Say yes and watch the wallet appear

    Confirm, and Avo creates a real PayPal sandbox order and renders the card with the full wallet: PayPal, Venmo, Pay Later, and card, plus a Pay Later message banner with the installment offer.

    Under the hood: the order is created through PayPal's Orders v2 API from the server; the buttons are the PayPal JS SDK in-context flow, which sidesteps the sandbox's redirect-approval phone wall.
  • 3

    Approve as the buyer

    Pay with the sandbox personal account (or any sandbox wallet option). The approval is a real PayPal flow: fake money, real screens.

    Points at: the capture the server performs on approval, and the order rail flipping to COMPLETED with the capture id.
  • 4

    Check PayPal's own books

    Log into the sandbox business account's activity and find the captured payment: the amount, the buyer, the timestamp. Our order rail and PayPal's ledger agree because they are the same events seen from two sides.

    Points at: the sandbox activity page, independent of anything we render.
  • 5

    Ask about it afterward

    "Where's my order?" Avo calls get_order and reports live PayPal status. Post-purchase is part of the sale; the agent that took the money can answer for it.

    Under the hood: refund and dispute-evidence clients ship in the same repo: the dispute reason → evidence mapping (proof of fulfillment, proof of refund) is implemented and unit-gated, awaiting its webhook wiring.
Pay in 4: four payments of $72.25, zero fees Pay in 4: $289 → 4 × $72.25 · zero fees $72.25 today $72.25 +2 weeks $72.25 +4 weeks $72.25 +6 weeks
Fig 2 · the pay-in-4 schedule Avo quotes: four equal payments, zero fees, verified arithmetic
Hand test

Copy-paste commands against the live endpoints

No credentials needed for any of these: the health check, catalog, and read-only MCP tools are public by design. Mutating MCP tools are bearer-gated and fail closed.

  • 1

    Check the health endpoint

    curl -s https://trailhead-shop.postoaklabs.workers.dev/healthz
    Expect: {"ok":true,"env":"sandbox",...}, the Worker on Cloudflare's always-on runtime.
  • 2

    Fetch the machine-readable catalog

    curl -s https://trailhead-shop.postoaklabs.workers.dev/api/catalog
    Expect: the ten-item JSON catalog Avo sells from: the same file the storefront rail renders.
  • 3

    The storefront speaks MCP

    curl -s -X POST https://trailhead-shop.postoaklabs.workers.dev/mcp -H 'Accept: application/json, text/event-stream' -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

    Four tools: trailhead_search_catalog, trailhead_create_order (returns a live PayPal approve URL), trailhead_get_order, trailhead_refund_order. Any MCP client (Claude, Postman, Inspector) can run the store's commerce lifecycle. Mutating tools require a bearer token and fail closed without one; that is deliberate, and the demo's chat path shows the ungated, human-approved side of the same lifecycle.

    Points at: an agent-addressable storefront: the same checkout a human gets, offered to the agent ecosystem.
Two MCP servers

Our books and PayPal's agree, cross-verifiable

The storefront runs its own MCP server, and PayPal runs one too: mcp.sandbox.paypal.com, authenticated per business account. Orders Avo creates through the REST API are the same orders PayPal's hosted MCP server reports: connect it in any MCP client, log in as the sandbox business, and read our transactions through PayPal's native agentic protocol. Two independent ledgers, one truth, and no code from us on PayPal's side of the wall.

Two MCP servers, one order: the storefront ledger and PayPal's ledger agree trailhead-shop storefront MCP · 4 tools mcp.sandbox.paypal.com PayPal hosted MCP order created · live approve URL same order, read back one order · two ledgers
Fig 3 · two MCP servers, one order: the storefront ledger and PayPal's hosted ledger report the same events

For the same receipt-over-MCP idea applied to public financial computation, see the Agentic Commerce MCP Hub, the deterministic calculator server this team operates at mcp.ainumbers.co, where every tool call returns an independently verifiable execution hash.

Under the hood

A zero-dependency server with a gate per behavior

The server is pure Node built-ins (no npm, no frameworks), so the whole shop is auditable in an afternoon. State lives behind one storage seam: SQLite locally, Cloudflare D1 in the Worker, the same schema and the same calling code, with webhook idempotency modeled as a first-class table. The chat is session-isolated (two tabs never see each other), captures are session-bound, mutating MCP tools fail closed without a bearer token, and every behavior named on this page is enforced by a mechanical gate in the repository, including the one that exists because the event path behind the PayPal button once regressed silently.

For developers: the storefront drives the PayPal Orders v2 REST surface with the JS SDK's query-parameter integration and paypal.Messages, and the repo ships the Add Tracking and Disputes-evidence clients today; their webhook triggers are the next build. The full source, the gates, and the smoke suite are public: github.com/PostOakLabs/paypal-agent-shop (MIT).

Authored 2026-10-05 · verified against the live deployment 2026-10-06 · Post Oak Labs