Piko

Inspiration

AI agents are starting to call paid APIs and tools on their own. But a single API call is worth a fraction of a cent, which is less than any card or wallet fee, and nobody wants to hand an autonomous agent an open credit card. We wanted PayPal to be the default way an agent pays, and the default way an API gets paid, with real controls for the humans who own the money.

What it does

Piko puts two sides on one append-only ledger:

Wallet (buyers): a solo developer tops up with PayPal and gives their agent a Key. A company gets an Org console with teams, Budgets, deterministic Policies, a circuit breaker that freezes a runaway agent, a kill switch (freeze an agent, a team or the whole org) and a spend grid with CSV export.
Gateway (sellers): any HTTP API or MCP tool can be listed with a per-call price. Agents call /g/{seller}/..., get an HTTP 402 challenge, pay through /api/pay, retry with a signed Receipt, and the gateway forwards the request to the seller. If the seller fails, the Call is refunded automatically.

Also built: seller payouts to PayPal through the Payouts API, approvals (an agent paying above a policy threshold gets 202 approval_pending until an admin approves it in the Org console), a plain-English policy compiler (Gemini turns "block Cheap Reviews for Marketing" into a policy, and an admin confirms it before it applies), and a live simulated-traffic toggle.

A Playground agent (Gemini, with Groq as fallback) searches the Directory, pays per call for product data under its budget, then checks out the product it picks with PayPal.

How we built it

One Next.js (App Router, strict TypeScript) app on Render, with Postgres plus pgvector on Neon through Drizzle.
Money is stored as integer micro-USD. Every paid Call writes three balanced ledger entries (buyer, seller, platform fee) in one transaction, and a refund is three reversing entries.
PayPal is used at the edges: Orders v2 and the JS SDK for Wallet top-ups and the final checkout, the Payouts API for seller withdrawals, and verified, idempotent webhooks (PAYMENT.CAPTURE.COMPLETED). Per-call money stays on the ledger, so sub-cent calls are viable.
An x402-style flow with a paypal-ledger scheme, where Piko acts as its own facilitator, plus a paid MCP server at /mcp/{seller}.
Enforcement is plain code, not AI. The pay pipeline runs key, frozen, challenge, breaker, policy, budget, funds and receipt checks in that order. The LLM only drives the demo agent and the directory embeddings.

Challenges we ran into

Making sub-cent payments correct under concurrency (row locks, reservations and refunds), keeping the ledger append-only, an SSRF guard for seller URLs, and making the demo data honest. Seeded traffic is labelled simulated, while every flow that moves money uses the real PayPal sandbox.

What we learned

Agents need payment rails with brakes. Budgets, policies and a kill switch matter as much as the payment itself.

What's next

Org billing through PayPal Invoicing (invoices are calculated today but not yet sent through PayPal), acting on payout status webhooks, and seller analytics.