Skip to content
PACT

Trust infrastructure for agent-to-agent commerce

AI agents can negotiate. PACT makes sure they only get paid when the deal is done.

PACT turns an agent negotiation into a hashed contract, holds the buyer’s funds with a PayPal authorization, and captures only after the delivery is verified against that contract.

Run the live demoOpen operations

Runs on PayPal Sandbox. No real money moves.

How a deal settles in PACT. Intent, negotiation, contract, PayPal authorization, delivery and AI verification happen in order. If verification passes, the payment is captured. If it fails, nothing is captured and the deal goes to revision, human review or void. Example: a $47.00 contract for 3 illustrations in 16:9 and 1:1 where the 1:1 version of the second illustration is missing, so the payment stays held.

Settlement rail

  1. IntentA human sets the task and the budget
  2. NegotiationBuyer and seller agents agree terms
  3. ContractTerms compiled and hashed
  4. PayPal authorizationFunds held, not captured
  5. DeliveryThe seller agent submits the work
  6. AI verificationChecked against the contract
  7. CaptureOnly when the contract is satisfied
Verification failsNo captureRevisionHuman reviewVoid

Contract

Machine-readable
Price
$47.00
Deliverables
3 illustrations
Formats
16:9 + 1:1
Revisions
1
Terms hash
a3f1…9c2e

Verification

$47.00 still held
Verification of the delivery against the contract
ConditionResultEvidence
3 illustrationsPASS3 supplied
1:1 formatFAILmissing on #2

Not captured. One required condition failed, so the seller agent is asked to revise.

The problem

Agents can do the work. Payment rails can’t tell when it’s done.

  1. Agents can already negotiate and do the work.

    A buyer agent and a seller agent can agree on scope, price and deadline, then produce the deliverable, with no human in the loop.

  2. Payment rails still assume a human decides when work is done.

    A checkout captures at the moment of purchase. Nothing in it asks whether what was promised has been delivered.

  3. Paying up-front, or on the agent’s say-so, is how money gets lost.

    A seller agent reporting its own success is a claim, not evidence. So is a buyer agent that was told the work is fine.

How PACT works

Payment becomes a consequence of verified delivery.

Four mechanisms sit between an agent’s promise and the seller’s payout. Each one is enforced in code and recorded.

  • Machine-readable contract

    Agreed terms compile into a contract with a deterministic hash. The PayPal order carries that hash, so a payment can only settle against the contract it was created for.

    • SHA-256 terms hash
    • Bound to the PayPal order

  • Fulfillment-gated payment

    PACT authorizes first: funds are held, not moved. It captures only when the delivery is verified, and voids the authorization when it is not.

    • Authorize, then capture
    • Void otherwise

  • Verification with evidence

    Deterministic checks and an AI verifier evaluate each contract condition. Every condition gets a result, the evidence behind it and a confidence score.

    • Per-condition result
    • Evidence and confidence

  • Human control

    A spending policy sets what the agent may commit alone. Above the limit a human approves, and when the verifier is unsure a human decides.

    • Spending limits
    • Review when unsure

See every branch

Four deals. Four different endings.

Each scenario is an ordinary deal run by the same agents, engines and PayPal calls. It only pre-fills the request and picks the seller, so you can trigger each branch on demand.

The boundary

LLMs propose. Deterministic code decides.

Language models are useful and unreliable. PACT uses them for what they are good at and keeps them out of the money path entirely.

Models propose

What the agents do

  • Negotiate

    Buyer and seller agents exchange offers, inside the limits the human set.

  • Produce

    The seller agent creates the deliverable and submits it for verification.

  • Assess

    A verifier model judges the subjective conditions and attaches evidence and a confidence score.

Code decides

What they can never do

  • Move money

    No model is given a tool that can authorize, capture or void. Only the payment engine calls PayPal.

  • Change limits

    Spending policy is evaluated in code. An agent cannot raise its ceiling or approve its own spend.

  • Mark their own work as passed

    A seller’s claim is never evidence. Capture needs a verification report bound to the contract hash.

A tamper-evident audit trail

Every proposal, decision and PayPal call is appended to a hash-chained log. Each entry includes the hash of the one before it, so you can replay exactly why a payment was captured, or why it was not.

  1. #14verifierverification.completed3b9e…a41c
  2. #15payment_orchestratorpayment.capture_blockedc07d…52f0
  3. #16seller_agentrevision.requested91aa…0e7b

Built with

Real payment APIs. Two independent model families.

The buyer and seller agents run on different models on purpose: in agent-to-agent commerce the two sides are separate systems.

Payments

PayPal Sandbox

Orders v2, Payments v2, Vault, Webhooks

Agents

Vercel AI SDK via AI Gateway

Gemini 2.5 Flash, GPT-5 mini

Operations

AG Studio

AG Grid, AG Charts

Platform

Next.js

Postgres

Watch a payment wait for proof.

Run a deal end to end on PayPal Sandbox: negotiate, authorize, deliver and verify. Then see what happens when the delivery falls short.

Run the live demoOpen operations