PACT

Trust infrastructure for agent commerce: AI agents negotiate, and PayPal captures only when the work is verified against the contract.

Comment

Inspiration

AI agents can already negotiate a price and produce the work. What they cannot do is be trusted with the moment that matters: deciding that the work is done and money should move.

Payment rails assume a human makes that call. So agent commerce today has two bad options: pay up front and hope, or let the agent that did the work announce its own success. No finance team will hand a budget to either.

We wanted the missing layer between "the agents agreed" and "the money moved": something that holds the funds, checks the delivery against what was actually agreed, and releases payment only when the deal was kept — with a record a human can audit afterwards.

What it does

PACT (Programmable Agent Commerce Trust) is a trust and settlement layer for agent-to-agent commerce, built on PayPal.

  1. Intent. A human describes a task in plain language: "Get three landing-page illustrations for under $50 by tomorrow at 6 PM. I need both 16:9 and 1:1 versions and one revision."
  2. Negotiation. A buyer agent turns that into a mandate with a hard budget ceiling and negotiates with a seller agent, which quotes from its own private rate card. The two agents run on different model families. A rules engine clamps every offer: the buyer can never agree above budget, the seller never below its floor.
  3. Contract. The agreed terms are compiled into a strict machine-readable contract with its own verification rules, and hashed.
  4. Policy. A deterministic spending policy decides whether the agent may commit the money by itself, needs a human's approval, or is blocked.
  5. Authorization. PACT creates a PayPal order with intent=AUTHORIZE, carrying the contract hash. The funds are held on the buyer's PayPal account — not captured. With a connected agent wallet (PayPal Vault) this needs no login; otherwise the buyer approves in PayPal.
  6. Delivery. The seller agent delivers the work.
  7. Verification. Deterministic checks (counts, real aspect ratios, word counts, deadline, file safety, hidden-instruction scan) and an AI verifier that looks at the deliverables produce a report: for every contract condition a result, the evidence, and a confidence.
  8. Settlement. Only if every condition is verified does PACT capture the authorization. An explicit failure sends the work back for revision; an ambiguous result or a suspected manipulation attempt stops for human review; when revisions run out, the authorization is voided and nothing is ever captured.

Every step lands in a plain-language, hash-chained audit trail. An operations dashboard shows all contracts, held and captured amounts, verification outcomes, risk and policy flags, and an auditor agent can re-read PayPal's own record and reconcile it with the ledger.

Four one-click scenarios show every branch: a verified delivery that is captured, a delivery with a missing file that is captured only after revision, a purchase above the agent's limit that waits for a human, and a hostile delivery that hides instructions for the verifier and ends voided.

How we built it

Frontend. Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS 4 and a small design system on Radix primitives. The live deal view drives the lifecycle one step per request and shows the negotiation, the contract, the payment rail, the deliverables, the evidence table and the audit trail as they happen.

Agents. Vercel AI SDK 7 through the Vercel AI Gateway. The buyer agent and the verifier run on Google Gemini 2.5 Flash; the seller agent runs on OpenAI GPT-5 mini — deliberately different model families, because in real agent commerce the two sides are independent systems. Every model call is a schema-constrained structured generation validated with Zod. The verifier is multimodal: deliverables are rasterised and inspected as images.

Deterministic core. Negotiation rules, the contract compiler, the policy engine, the verification decision and the capture guard are pure TypeScript functions. Models only propose; these functions decide. The deal and payment lifecycles are closed, table-driven state machines.

PayPal. The PayPal Sandbox REST APIs, called directly so each request controls its idempotency key:

  • Orders v2 — create order with intent=AUTHORIZE, read order, authorize order
  • Payments v2 — read, capture (full and final-partial), void and re-authorize authorizations
  • Vault v3 — setup tokens and payment tokens for the delegated agent wallet
  • Webhooks v1 — registration and signature verification (RSA-SHA256 over the raw body)
  • PayPal Agent Toolkit — one read-only tool (get_order) for the auditor agent

Operations. AG Studio 3 for the dashboard (custom widgets, a theme bound to our design tokens, and the Studio Agent Framework with a custom auditor agent), AG Grid 36 for the ledger and AG Charts 14 for the charts.

Persistence. PostgreSQL (Neon) through Drizzle ORM, with version-controlled SQL migrations. The same schema runs on PGlite, an in-process Postgres, for local development and CI.

Quality. More than 2,700 unit and integration tests (Vitest), a live PayPal Sandbox suite, and 28 Playwright end-to-end tests covering every scenario, all run in GitHub Actions. Deployed on Vercel.

Challenges we ran into

  • Keeping stochastic agents away from the money. It is easy to give an agent a "pay" tool. We did the opposite: no model holds any capability that moves money. That meant designing every agent output as a proposal and writing a deterministic engine that can clamp it, veto it or escalate it.
  • Making "done" checkable. A contract is only useful if its conditions can be evaluated. We derive verification rules from the negotiated terms and split them into what code can measure (does a 1:1 file really have a 1:1 pixel ratio?) and what needs judgement (does the illustration match the brief?), and gave uncertainty its own path instead of forcing a yes or no.
  • Idempotent settlement. A double click, a second tab, a crashed function or a replayed webhook must never capture twice. Each step runs under a per-deal lease, every PayPal call has a deterministic PayPal-Request-Id recorded in a ledger, and "already captured" is reconciled against PayPal's record rather than retried.
  • Binding the payment to the agreement. We write the contract's hash into the PayPal order and re-read PayPal's own record before authorizing and capturing, so a payment can only settle against the contract it was created for.
  • Hostile deliverables. A seller can try to talk the verifier into passing. Deliverables are sanitised, measured rather than believed, and scanned for hidden instructions; a hit goes to a human.
  • A demo that cannot fall over. Models time out. Each call has a hard timeout, a fallback model and a scripted fallback, and a verifier outage can only ever lead to human review.

Accomplishments that we're proud of

  • A complete authorize → verify → capture lifecycle on the real PayPal Sandbox, including revision, partial release, void and human review — not only the happy path.
  • A capture guard that refuses to release funds unless the contract hash, the verification report, the amounts, the authorization and PayPal's own record all agree.
  • More than 2,700 automated tests, including concurrency tests that fire 50 simultaneous capture requests and prove exactly one capture happens.
  • Two different model families negotiating against each other inside hard limits neither can cross.
  • An operations surface a finance or risk owner could actually use, with an agent that can explain any deal and reconcile it against PayPal while being unable to change anything.

What we learned

  • The useful question is not "can the model do this?" but "what is the worst thing the model can cause?" Designing from that question made the system simpler: models propose, code decides.
  • PayPal's authorize-and-capture flow is a natural fit for outcome-based payment. Authorization is the commitment; capture is the consequence.
  • Confidence only matters if it changes behaviour. Routing low confidence to a human — rather than showing a number next to an automatic decision — is what makes AI verification acceptable for money.
  • Idempotency keys are a design tool, not a detail: deriving them from the deal and the contract made every retry safe by construction.
  • Treat everything a counterparty's agent sends as untrusted input, including its work.

What's next for PACT

  • Richer contracts. Milestones, staged captures, penalties and acceptance tests for code and data deliverables.
  • Seller discovery and reputation. A directory where sellers are matched by capability, price and verified first-pass rate.
  • Multi-agent marketplaces. Several sellers bidding for one contract, and contracts that split across them.
  • Cryptographic attestations. Signed contracts and verification reports that either side can present to a third party.
  • Seller payouts. Onboarding sellers as PayPal merchants so each capture is paid to the agent's principal.
  • Enterprise governance. Roles, approval chains, budgets per team and export to finance systems.
  • An open protocol. The HTTP API is already described in OpenAPI; the next step is letting third-party agents open and fulfil PACT contracts directly.

Links

Built With

  • ag-charts
  • ag-grid
  • ag-studio
  • drizzle-orm
  • gemini
  • gpt-5
  • neon
  • next.js
  • paypal
  • paypal-agent-toolkit
  • paypal-orders-api
  • paypal-payments-api
  • paypal-sandbox
  • paypal-vault
  • paypal-webhooks
  • playwright
  • postgresql
  • react
  • tailwindcss
  • typescript
  • vercel
  • vercel-ai-gateway
  • vercel-ai-sdk
  • vitest
  • zod
Share this project:

Updates

Submission history