Inspiration

AI agents are starting to shop and pay on their own. That's exciting and a little terrifying: who actually controls the money? We wanted to build the smallest possible proof that an agent can do real commerce - browse, cart, checkout - while a human stays the only one who can approve an actual payment. PayPal's sandbox is the perfect place to prove that safely, with real approval flows and zero real money at risk.

What it does

acp-sandbox is a hosted mock merchant that speaks the Agentic Commerce Protocol (ACP) - the open checkout standard from OpenAI, Stripe, and Meta. It's also a hosted MCP server, so any MCP-capable agent (Claude, Cursor, ...) can connect to it directly with zero setup on the agent side.

The agent gets five tools: list_products, create_checkout / update_checkout, request_paypal_payment, wait_for_payment_approval, and complete_checkout. It can browse the catalog, build and edit a cart, and ask a human to pay - but it can only ever hand over a PayPal approval link. The payment is captured only after the human approves it on PayPal, and only for the exact cart total. The agent cannot charge anything on its own, change the amount after approval, or reuse an approval for a different cart.

How we built it

A small Node/TypeScript service exposing two surfaces over the same checkout session model: a REST implementation of the ACP checkout API (create, retrieve, update, complete, cancel), and an MCP server wrapping the same operations as agent tools, plus the PayPal-specific steps (request_paypal_payment, wait_for_payment_approval). PayPal integration uses real Orders v2 sandbox calls - create order with an idempotency key, then capture only after independently confirming on PayPal's side that the buyer approved and the capture is COMPLETED for the exact amount and currency of that session. A dashboard shows every checkout session and every request an agent sent, with the sandbox's response, for debugging and for judges to verify a run actually happened.

Challenges we ran into

Keeping the human genuinely in control, not just in appearance, took the most care: the agent only ever gets an approval link, never a way to trigger a capture itself, and the server re-verifies the PayPal order against the session's exact total before marking anything paid - a stale or foreign order id, or a mismatched amount, is rejected. We also had to make the MCP tool flow feel natural for an agent to drive without any custom client code - just a connector URL and a plain-English ask ("buy X and pay with PayPal") - which took a few iterations on tool descriptions and error messages until a real agent (Claude) could complete the whole flow unassisted except for the human approval step.

Accomplishments that we're proud of

This isn't a mocked demo. A real agent (Claude, connected over MCP with zero custom code) listed products, built a real cart, requested a real PayPal sandbox payment, waited for a human to approve it, and placed a real order - order number, real receipt, every step logged. We ran this live: a demo mug and two notebooks, $30.97, approved on a PayPal sandbox buyer account, captured, order placed. The whole loop, start to finish, with no step faked or skipped.

What we learned

The hard part of agentic commerce isn't getting an agent to want to buy something - it's building a protocol boundary an agent literally cannot cross on its own. Every design decision came back to: what's the one thing only a human can do here, and how do we make the agent's tools physically incapable of doing it instead.

What's next

Broaden beyond the mock catalog to let any merchant plug their real product data into the same ACP + MCP surface, and add more payment methods behind the same approve-it-yourself boundary.

Built With

Share this project:

Updates

Submission history