PayPal Handshake: Cryptographic Checkout & Bounded Authority for Autonomous AI Agents

"AI proposes, deterministic backend verifies, policy plane controls money. Nothing is charged unless the final deal matches exactly what the shopper approved."

Inspiration

People increasingly want AI assistants that can research products, compare deals across merchants, negotiate bundles, and complete purchases on their behalf.

Bringing AI agents into commerce creates a clear security problem: how do you let an autonomous agent negotiate and shop without handing it unrestricted access to your credit card or PayPal account?

Large Language Models are probabilistic by nature. They are susceptible to prompt injections, merchant-side manipulation (such as hidden fees, bait-and-switch substitutions, or category drift), and simple hallucinations. Relying on an LLM prompt to protect payments is unsafe. At the same time, asking a human to manually approve every search query or counter-offer defeats the point of using an autonomous agent.

We built PayPal Handshake to solve this problem. Using zero-trust principles and bounded authorization, the system places a strict mathematical boundary around AI commerce: an agent can negotiate freely within pre-approved limits, but it cannot change the terms, exceed spending caps, or move money without deterministic, cryptographic proof.

What It Does

PayPal Handshake is an agentic negotiation and checkout platform that connects shoppers, AI agents, merchant catalogs, and the PayPal Sandbox gateway through a verifiable chain of custody.

Bounded Intent Mandates (MandateV2): Before shopping starts, the shopper sets clear boundaries (such as a $450.00 budget cap, the allowed product category electronics.monitors, a trusted merchant merchant.example, and a 2-hour expiration window). Process C signs this mandate with an isolated Ed25519 private key.
Autonomous Multi-Merchant Negotiation (Process A): The shopper's AI agent searches merchant catalogs via the Channel3 integration, finds eligible items, negotiates bundles or volume discounts, and puts together a candidate deal.
Independent Catalog Verification (Process C): Process C independently checks the Channel3 product registry using authoritative API credentials to confirm that each item is real, in stock, and accurately priced, then generates signed ProductReferenceV2 tokens.
Deterministic 14-Gate Verification (Process B): Before any payment is processed, the candidate deal goes to an isolated, stateless verification service. Process B runs 14 mathematical and cryptographic checks against the mandate and product tokens—verifying price ceilings, merchant identity, timestamps, product categories, and digital signatures.
Durable Consent & PayPal Capture: Once verified, the shopper reviews the cryptographic evidence. When they give final approval, the mandate is atomically claimed and marked as used in PostgreSQL 16 (preventing replay attacks), and the funds are captured through the PayPal Sandbox API.

How We Built It

PayPal Handshake uses a three-process microservice architecture designed to enforce strict separation of duties and keep secrets isolated:

┌────────────────────────────────────────────────────────────────────────┐
│                        Shopper & Web Dashboard                         │
│                  Next.js 14 / TypeScript / Tailwind CSS                │
└────────────────────────────────────┬───────────────────────────────────┘
                                     │
                                     ▼
┌────────────────────────────────────────────────────────────────────────┐
│                    Process A: Agent Orchestrator                       │
│                        (FastAPI - Port 8001)                           │
│  • Autonomous deal assembly & Channel3 catalog discovery               │
│  • UNTRUSTED: Holds zero private keys, never assigns categories        │
└──────────────────┬─────────────────────────────────┬───────────────────┘
                   │                                 │
         Proposes Candidate Deal                     │ Requests Signed References
                   ▼                                 ▼
┌──────────────────────────────────────┐  ┌──────────────────────────────┐
│       Process B: Mandate Gate        │  │  Process C: Payment Policy   │
│        (FastAPI - Port 8002)         │  │     (FastAPI - Port 8003)     │
│  • 14 deterministic invariant checks │  │  • Sole Ed25519 signing key  │
│  • Pure stateless RFC 8785 verifier  │  │  • Trusted Category Registry │
│  • Holds ONLY public key             │  │  • Channel3 & PayPal Sandbox │
└──────────────────┬───────────────────┘  └──────────────┬───────────────┘
                   │                                     │
                   │          Verified Decision          │
                   └─────────────────►◄──────────────────┘
                                     │
                                     ▼
┌────────────────────────────────────────────────────────────────────────┐
│                   PostgreSQL 16 Persistence Layer                      │
│   • 9 Core Tables (negotiations, mandates, consent_evidence, etc.)     │
│   • Replay Prevention: mandate_consumptions unique single-use locks    │
│   • Strict Integer Minor Units (BIGINT cents) & ISO 4217 currencies  │
└────────────────────────────────────────────────────────────────────────┘

Key Technical Pillars

RFC 8785 Canonical JSON & Ed25519 Cryptography: Mandates and product references are serialized with sorted keys, compact separators, escaped Unicode, and UTF-8 encoding to guarantee exact byte-level consistency across services.
Fail-Closed Security Model: There are no synthetic fallbacks or mock capture IDs. If credentials are missing, timestamps expire, or a signature fails to match, the system immediately rejects the transaction.
Integer Minor Units: All monetary values (budget_cents, price_cents, authorized_cap_cents, amount_cents) are stored as 64-bit integers (BIGINT) paired with ISO 4217 currency_code (VARCHAR(3)), eliminating floating-point rounding errors.
Durable Replay Protection: Single-use consent is enforced through atomic database transactions in PostgreSQL. Once a mandate is used, any duplicate attempt immediately triggers a MandateAlreadyConsumedError.
Interactive Dashboard: A Next.js 14 web interface displays live negotiation progress, an inspection matrix for the 14 verification gates, and a real-time cryptographic audit log.

Challenges We Faced

Cross-Service Canonical Determinism
Challenge: Cryptographic signatures require exact byte-level reproduction. Minor differences in JSON formatting—like whitespace, key order, float formatting, or Unicode escaping—break Ed25519 signature checks.
Solution: We built golden-byte canonicalization test fixtures (test_protocol_compatibility.py) following RFC 8785, locking exact byte representations into automated tests across all services.
Concurrency & Replay Prevention Under Network Latency
Challenge: In an automated workflow, an agent or shopper might accidentally submit a checkout request twice or trigger network retries, creating the risk of a double charge.
Solution: We implemented an atomic record_and_claim function in PostgreSQL using row-level locks and a unique constraint on mandate_consumptions.mandate_id. Duplicate requests abort before reaching the payment gateway.
Eliminating Floating-Point Imprecision
Challenge: Early prototypes used floating-point decimals for currency, which caused off-by-a-penny discrepancies between the agent's math, database records, and PayPal's API.
Solution: We refactored the entire data and serialization pipeline to use integer minor units (cents). Every financial value stays an integer from the API schemas down to the database columns.
Maintaining Zero-Trust Boundaries
Challenge: Microservices often lose clear boundaries over time when shared database connections or config files blur responsibilities.
Solution: We enforced strict isolation: Process A has no signing keys; Process B has no database access and only holds the public verification key; Process C exclusively holds the private signing key and PayPal Sandbox credentials.

What We Learned

An LLM is not a security boundary: Prompt engineering cannot protect financial accounts. Reliable agentic commerce requires separating responsibilities so the AI proposes deals, a deterministic engine verifies them, and an isolated policy service controls the money.
Fail-closed design is essential in payments: Falling back to default approvals or placeholder IDs hides security bugs. If a single signature fails or an external catalog API goes down, the system must halt and refuse payment.
Transparent audit trails build trust: Showing shoppers an exact, tamper-evident record of their mandate, the merchant's verified offer, and the 14-point checklist makes them far more comfortable letting AI handle purchases.

What's Next for PayPal Handshake

Multi-Merchant Autonomous Auctions: Letting AI agents negotiate simultaneously across dozens of merchants in real time to find the highest-rated, lowest-cost bundle.
Dynamic Conditional Escrow: Expanding MandateV2 to support milestone-based payouts—such as releasing 20% upon order confirmation and the remaining 80% once carrier tracking confirms delivery.
Standardizing the Agent Mandate Protocol (AMP): Packaging our Ed25519 canonicalization and bounded mandate contracts into an open-source SDK for developers building on the PayPal Developer Platform.