The PayClaw Trust Constitution
Agents Are Not Bots
For twenty years, merchants built an arms race against bots. CAPTCHAs, device fingerprinting, behavioral analysis, IP reputation, rate limiting — billions of dollars answering one question: "Is this a human?"
It was the right question. Until now.
Because now there's a third category. Not human. Not bot. Something new: an authorized actor — trusted by a real person, acting on their behalf, with explicit consent, for a specific purpose, for a limited time.
PayClaw is the proof that your agent is not a bot. Not by fighting the merchant's defenses. Not by bypassing their bot detection. By giving your agent a way to declare what it is: an authorized actor, not anonymous traffic.
PayClaw is KYA infrastructure — Know Your Agent. The verification layer that answers: Who is this agent acting for? What does it intend to do? Is it authorized to do it?
Our Commitments
- Human-in-the-loop authorization at every step. Every agent action PayClaw enables carries a declared intent and explicit human approval — aligned to merchant standards as they evolve.
- No bypass. No workarounds. Ever. PayClaw does not promote, enable, or tolerate bot bypass, credential stuffing, or any workaround to merchant access controls. We prove identity — we don't circumvent defenses.
- Fintech-grade user security. Every user on PayClaw is protected by the same security standards applied to regulated financial products. No exceptions.
- Your data is yours. We do not use user data for marketing purposes. We do not sell data in any form, to anyone, for any reason.
- Your consent defines our data. PayClaw only tracks events tied to scopes you explicitly opted into. The identity declaration is the consent boundary — without it, nothing is recorded. No ambient tracking. No background collection. No orphan events.
UCP Identity Linking
PayClaw is a Credential Provider in the Universal Commerce Protocol (UCP) — the open standard for agent commerce co-developed by Google and Shopify. UCP is adopted by Target, Walmart, Wayfair, and Etsy.
UCP's extensible capability model allows any domain owner to publish extensions. PayClaw publishes io.payclaw.common.identity — a checkout extension that lets agents declare verified human authorization before acting at a merchant. Merchants who install PayClaw signal to every UCP-compliant agent that declared agents are preferred.
The extension is open source under the MIT license. The full merchant documentation is at /merchants. The UCP specification is at ucp.dev. The protocol repo is at github.com/payclaw/ucp-agent-badge.
Badge by PayClaw — The Skeleton Key
Badge is the mechanism by which an authorized actor proves it's not a bot. Before any action, the agent declares itself — and that declaration carries weight.
Think of it like a prescription pickup: you can authorize your mom to pick up your prescription, but that doesn't mean she can pick up all your prescriptions, forever, at any pharmacy. The authorization is specific: this action, this merchant, this session.
Badge works the same way. Your agent doesn't get broad, standing rights. It gets trip-level authorization — per action, at the moment of action, through the MCP server.
What Badge Declares
Every Badge-identified agent session carries:
- Agent type: Authorized actor — an automated system acting on behalf of a verified human
- Principal verification: OAuth-authenticated human authorized this session
- Per-action authorization: Every action carries explicit human approval
- Verification token: Cryptographic proof of principal identity (
pc_v1_...) - Contact path:
agent_identity@payclaw.iofor merchant verification
How Verification Works
- Agent calls
payclaw_getAgentIdentitybefore any shopping action - PayClaw issues an HMAC-SHA256 verification token tied to the authenticated principal
- Agent presents the disclosure and token to merchants during the session
- Merchants can verify the token and contact
agent_identity@payclaw.ioto confirm principal identity (with user consent)
No card is issued. No money moves. Badge is the identity layer — the skeleton key that lets authorized agents through while bot defenses stay intact.
Badge Token Lifecycle
Badge verification tokens are issued per shopping session and expire after 24 hours. Each token is:
- Cryptographically signed (HMAC-SHA256) — cannot be forged
- Tied to the authenticated principal — cannot be transferred
- Scoped to the declared action — cannot be reused for different purposes
- Time-bounded — expires automatically, no standing authorization
Consent-Scoped Observability
Badge tracks what happens to your agent — but only within the boundaries you set.
- Every event is tied to a declaration. No identity declaration, no tracking. The
pc_v1_token is the consent boundary. - Outcome tracking, not surveillance. After your agent presents its identity, PayClaw records the outcome: was the agent accepted, denied, or was the result inconclusive? Four explicit outcome buckets —
accepted,denied,inconclusive,no_sampling— with no interpretation baked into storage. Raw truth, stored as-is. - Your scopes define the data. In V1, Badge tracks
[BROWSE]declarations and outcomes. When additional scopes are introduced (search, cart, checkout), each scope introduces its own event tracking — only when you opt in. - Attribution risk is disclosed. Any observation beyond your explicit consent scope is flagged as attribution risk on this page.
Design Principles
Badge is designed with merchant agent policies in mind — including those of Amazon, Shopify, Walmart, Instacart, and others. We do not claim compliance with any specific merchant's policy. We build for the pattern: declared identity, declared intent, verified principal, traceable action.
Spend by PayClaw — The Last Mile
When an authorized actor needs to pay, Spend issues a virtual Visa card scoped to a single, human-approved task. Badge identity is included automatically — the agent that pays has already declared who it is.
Zero Trust by Design
PayClaw doesn't ask anyone to trust the AI agent. It makes trust unnecessary by ensuring an agent architecturally cannot spend money without real-time human authorization, and architecturally cannot accumulate financial credentials between tasks.
The agent doesn't need to be trusted. The architecture enforces correct behavior.
The Five Pillars
1. Zero Standing Access
An agent connected to PayClaw has no persistent financial state. It cannot query wallet balance, view card numbers, or access transaction history. Until the user approves a specific task, the agent knows nothing about the user's financial position.
2. Single-Intent Authorization
Every dollar that flows through PayClaw requires a discrete, human-approved intent:
- Merchant: Where the purchase will be made
- Amount: Estimated spend (validated against actual at settlement)
- Description: What is being purchased
- Expiry: Intent window is time-bounded — the intent cannot be used after expiry
The human approves each intent via the MCP client's interactive prompt (approve/deny). This is an inline confirmation within the agent's tool-calling flow — the agent proposes a purchase, and the MCP client presents the details for human review before proceeding. The agent cannot bypass this step.
Merchant restrictions are available as a restrictive control — users can limit which merchants their agent is allowed to shop at. These restrictions reduce the agent's scope; they do not enable autonomous spending. Every purchase still requires individual human approval regardless of merchant restrictions.
One task. One human approval. One card.
3. Ephemeral Card Credentials
A fresh virtual Visa is issued for each approved intent, used for the purchase, and destroyed. The agent never accumulates card credentials between tasks. Each task is financially isolated. Your real card never enters the chat.
4. Atomic Authorization Flow
The complete lifecycle of an agent purchase is a single, unbroken chain:
Badge Identity → Intent Declaration → Human Approval (MCP prompt) → Card Issuance → Purchase → Settlement → Audit
Every step is time-bounded, user-scoped, audit-logged, and reconciled. The agent cannot self-approve — only the human, responding to the MCP client's interactive prompt, can authorize a purchase. For dashboard operations (viewing transactions, managing settings), MFA authentication is required.
5. Immutable Audit Trail
Every event is logged: identity declaration, intent creation, human approval, card issuance, transaction settlement, and intent reconciliation. Audit logs are scoped per user via Row-Level Security.
Spend Token Lifecycle
Spend intents are time-bounded with a 15-minute expiry window. Each intent is:
- Tied to a specific merchant and declared amount
- Human-approved via the MCP client's interactive prompt
- Fulfilled by a single-use virtual Visa card
- Automatically reconciled against the actual transaction at settlement
- Audit-logged at every stage
Comparison to Alternatives
| Capability | Give Agent Your Card | Crypto Wallet | PayClaw (Badge + Spend) |
|---|---|---|---|
| Agent identity declared to merchants | No | No | Every session (Badge) |
| Agent standing access to financial data | Full (card number) | Balance visible | None |
| Human authorization per transaction | None | None | Every transaction (MCP prompt) |
| Card credential lifespan | Permanent | Permanent | Single use |
| Maximum fraud exposure | Unlimited | Wallet balance | One approved amount |
| Works at existing merchants | Yes | No (DoorDash doesn't accept USDC) | Yes — existing Visa rails |
| Audit trail granularity | None | On-chain | Full lifecycle |
For Merchants
How PayClaw Works With Your Defenses
Your bot defenses work. PayClaw adds one signal on top of them.
PayClaw publishes io.payclaw.common.identity as a UCP checkout extension. Merchants who install PayClaw inject this capability into their /.well-known/ucp manifest. Every UCP-compliant agent at your store discovers it automatically.
When an agent carries a PayClaw declaration, it presents verified identity, declared intent, and a traceable human principal. You get one new column in your decision matrix: declared or undeclared. Nothing changes in your infrastructure. Your fraud systems stay intact.
What a Declared Agent Carries
- Agent type: Authorized actor — not a human, not a bot
- Principal verification: OAuth-authenticated human authorized this session (Google or Apple sign-in)
- Declared intent: Per-action authorization — every action was explicitly approved
- Verification token: Cryptographic proof of principal identity (
pc_v1_...) - Contact path:
agent_identity@payclaw.iofor merchant verification
How to Verify
Programmatic (recommended): Use standard OAuth 2.0 token introspection (RFC 7662). Send the Bearer token to POST /api/oauth/introspect. Returns {active: true} or {active: false}. One HTTP call. No PayClaw account required. Non-blocking. Discover the endpoint via /.well-known/oauth-authorization-server (RFC 8414).
Manual: Contact agent_identity@payclaw.io with the token to verify principal identity (requires user consent).
Install
Shopify merchants: PayClaw KYA Shopify app — coming soon. One-click install. No configuration. No code changes.
Non-Shopify merchants: Email merchants@payclaw.io for manual manifest injection.
Full merchant documentation: /merchants
PayClaw agents do not bypass access controls. If your site requires login, CAPTCHA, or human verification — that is between the user and your platform. PayClaw declares identity on allowed actions. Nothing more.
For Developers
PayClaw is MCP-native. One install. Your agent declares itself. Badge tokens are UCP-compatible — merchants that implement the Universal Commerce Protocol read them natively.
| Tool | What It Does |
|---|---|
payclaw_getAgentIdentity | Declare agent identity → get verification token (Badge) |
payclaw_getCard | Declare purchase intent → get virtual Visa card (Spend) |
payclaw_reportPurchase | Report transaction outcome → auto-audit against intent |
Get Started
Badge + Spend (full stack):
clawhub install payclaw-io
Badge only (identity, no payment):
clawhub install payclaw-badge
Sign up at payclaw.io to get your API key. Five-minute setup.
For Card Issuers
Your BIN is protected by multiple architectural layers:
- Identity-first: Every agent session is declared and verified via Badge before any card is issued
- Bounded exposure: Single-use cards. One merchant per card. Human-approved amount.
- Human authorization: Every card issuance has a corresponding human approval event via the MCP client's interactive prompt. Dashboard access requires MFA.
- No agent accumulation: Agents cannot build up a portfolio of active cards or stored credentials.
- Full audit trail: Every identity declaration, intent, approval, issuance, and settlement is logged and reconcilable.
- Intent reconciliation: Automatic comparison of declared intent vs. actual spend — mismatches are flagged and logged.
The question isn't "do you trust the AI agent?" The answer is: the agent doesn't need to be trusted. The architecture enforces correct behavior.
KYA — Know Your Agent
KYA is the framework for verifying AI agent identity, intent, and authorization before agents interact with merchants and services. It answers three questions:
- Who is this agent acting for? — Principal identity, verified via OAuth
- What does it intend to do? — Declared scope and intent, per action
- Is it authorized to do it? — Consent key, trip-level token, human approval
PayClaw is KYA infrastructure. Every declaration creates a verified, user-consented record of agentic commerce behavior. What agents browse. What they intend to buy. Where they get blocked. Where they get through.
Security Infrastructure
Authentication & Authorization
- Dual auth: API key (agent path) + session cookie (dashboard path)
- API keys: cryptographically hashed with timing-safe comparison, per-user limits enforced
- Agent purchase approval: MCP client interactive prompt (approve/deny per intent)
- Dashboard access: MFA (TOTP AAL2) mandatory for Spend-enabled accounts
- Badge: OAuth-only authentication (DQ-49) — no MFA required for identity declarations
- CSRF: Origin validation on all state-changing session requests, fails closed
Data Protection
- Card numbers never stored — transient API response only
- Badge verification tokens: HMAC-SHA256 signed, 24-hour expiry, not reversible to user identity without server-side secret
- Spend intents: 15-minute expiry, single-use card credentials
- Supabase Row-Level Security on all user-facing tables
- Admin operations use service role key, isolated from user sessions
- All API communication requires HTTPS (enforced at MCP client level)
Infrastructure Security
- Vercel auto-deployment from protected branches only
- Content Security Policy: no unsafe-eval, strict script sources
- HSTS with 2-year max-age, includeSubDomains, preload
- Rate limiting: tiered via managed store, financial endpoints fail closed if rate-limit service is unavailable
Continuous Security
- AI code review on every pull request (CodeRabbit)
- Secret scanning on every commit (gitleaks)
- Daily automated dependency auditing
- Append-only security changelog and audit trail
PayClaw LLC · payclaw.io · security@payclaw.io