PayPal AI Hackathon · Agentic Commerce

Guarded Agent Checkout

An AI agent that can pay is an AI agent that can be robbed. This is the guard that stands in front of the money.

01How it works

An AI agent proposes a purchase. Before any money moves, the guard runs two layers of checks and returns a verdict.

Layer 1Pre-flight checks

  • Merchant sanity — is the merchant known, or is it on a block list?
  • Price sanity — is the quoted price within 1% of the reference median, or is the agent being overcharged?
  • Quote consistency — does the total equal unit price × quantity + shipping?

Layer 2Spend policy

  • Per-transaction cap — no single payment above the owner's limit.
  • Daily limit — total spend per day stays inside a set budget.
  • Owner freeze switch — the owner can freeze all payments instantly.

The verdicts

ALLOW

The checks pass and the PayPal sandbox payment executes.

HOLD

Something needs a human. Nothing moves until a person approves.

BLOCK

Rejected outright. No PayPal call is ever made.

The checks are ported from the author's earlier agent-safety work: tgp-guard (pre-flight checks for autonomous agents) and Aegis (on-chain spend control for agents on Base). Same semantics, new rail: PayPal.

02Six scenarios

Every proposal the demo throws at the guard, and what the guard does with it.

Guard scenarios run locally against reference data. BLOCK and HOLD verdicts never reach PayPal.

Normal purchase

ALLOW

Scenario 1

Image generation credit, $42.00. Known merchant, fair price, policy clear — the payment goes through.

Block-listed merchant

BLOCK

Scenario 2

shady-deals.example

On the block list. No order is created. Nothing is charged.

Over-limit amount

BLOCK

Scenario 3

$450 against a $100 per-transaction cap. Over the line, payment refused.

Off-market price

BLOCK

Scenario 4

Quoted price is more than 1% off the reference median. The agent is being overcharged — blocked.

Unknown merchant

HOLD

Scenario 5

Merchant the guard has never seen. Not an automatic no — a human must approve before anything moves.

Policy frozen

BLOCK

Scenario 6

The owner has frozen the policy. Every payment is blocked until the owner unfreezes it.

03The real sandbox run

Scenario 1, run for real against the PayPal sandbox — not a mock-up.

paypal-guard — capture
REAL PAYPAL SANDBOX RUN — 5 NOV 2026 (SANDBOX TEST MONEY)
Guard verdictALLOW
Order created48492101JX0814434
Buyer approvalAPPROVED
Amount$42.00
Capture status: COMPLETED

Sandbox lesson 1Merchant country decides

The merchant account's country decides whether it can receive payments. A merchant in a send-only country gets seller-restricted on every checkout. The completed run used a US sandbox merchant.

Sandbox lesson 2Use the Pay Now flow

The default review checkout flow can hang. The Pay Now flow (user_action: PAY_NOW, NO_SHIPPING) completes. Funding source matters too: a card-funded approval captured COMPLETED, while a bank-funded one captured PENDING.

04Run it yourself

Clone the repo and run the demo locally.

terminal
node demo.mjs all --fresh
  # all six scenarios
node demo.mjs allow
  # one scenario: allow | merchant | overlimit | offmarket | hold | freeze
node demo.mjs capture <ORDER_ID>
  # capture an approved sandbox order

Zero dependencies. Node ≥ 20.

Without PayPal sandbox credentials the demo runs in a clearly labelled MOCK mode — simulated lines say SIMULATED. Mock output is never a PayPal result.

With sandbox credentials (PAYPAL_CLIENT_ID / PAYPAL_CLIENT_SECRET from a sandbox app at developer.paypal.com) the ALLOW path makes real sandbox calls.