Agent payments, explained

Every online payment used to have a person behind it: a person clicks confirm, enters a password, takes responsibility. An agent payment lets an AI program do all of that itself — it decides to buy some data, call an API, hire another agent, and then sends the money, with no human clicking confirm.

Why now? Two pieces just clicked together. Stablecoins (dollars on a blockchain) let machines directly hold and move "money"; protocols like x402 let a single API call carry a payment. Put them together and a machine can spend like a person.

It usually has three traits: small amounts (often cents to a few dollars), high frequency, high speed. That's its value — efficient machine-to-machine collaboration — and its risk: by the time a human reacts, hundreds of payments may already be out the door.

So the real question isn't "can machines pay?" (they already can) but "who is this paid to, was it tricked, is the money clean?" — answered before the money actually leaves, at machine speed. That's exactly what OceanAlt does.

x402 is an open protocol that lets an AI agent pay for a single API call straight from its wallet. The name comes from an old HTTP status code — 402 Payment Required — which sat unused for decades; x402 picked it up.

How it works is simple: an agent calls an endpoint, the server says "this costs money" (returns a 402 with the amount, payee, and a one-time number). The agent signs and pays from its wallet, retries the request with proof of payment, and the server hands over the result.

What makes it special: no account, no API key. The payment is the identity — whoever paid gets access. That suits agents, which can't register, fill forms, and wait for approval the way people do.

x402 is driven by Coinbase and has run real volume on mainnet since 2025. It's one of the main foundations for machines spending on their own.

AP2 (Agent Payments Protocol) is a payments protocol led by Google. It's after the same big thing as x402 — letting AI agents pay safely — but from a different angle.

x402 focuses on completing a payment inside a single API call; AP2 focuses on proving the payment was actually authorized by the user. Its core is the "mandate": the user signs an authorization first (say, "may spend up to $50 on a flight"), and the agent carries that signature when it pays, so the merchant can confirm this isn't the agent spending on a whim but the user's real intent.

Why does that matter? Because agents can be tricked (see "prompt injection"). Without a verifiable mandate, a merchant can't tell "the user wanted this" from "the agent was manipulated into it." AP2 uses cryptographic signatures to pin down user intent so it can't be tampered with in transit.

Think of it as another main road for agent payments. The field is young — x402, AP2 and others coexist and are still competing and converging; no clear winner yet. OceanAlt's compliance layer is built to not depend on any single protocol, so it plugs into whichever road takes off.

A stablecoin is a price-stable cryptocurrency, usually pegged one-to-one to a US dollar (USDC and USDT are common). It runs on a blockchain, but its value doesn't swing like Bitcoin's, because it's backed by equivalent dollars or Treasuries in reserve.

To a person it's like "dollars on-chain." To a machine it's essential — an agent can't open a bank account or send a SWIFT wire, but it can hold and move stablecoins directly. Stablecoins made "a machine holding and paying dollars" possible for the first time, which is the precondition for agent payments.

They also suit cross-border and micro-payments naturally: settled in seconds, near-zero fees, always on. A few-cent agent payment wouldn't even cover a bank's fee, but works fine in stablecoins.

One distinction to keep clear: stablecoins solve how money moves, not whether it should move or whether the counterparty is clean. That's the compliance layer's job — which is what OceanAlt does.

We know KYC (Know Your Customer): opening a bank account requires proving "you are you." KYA applies the same idea to AI agents — Know Your Agent, giving a spending agent an "ID card."

It answers four questions: who is this agent? Which accountable entity (company, person) stands behind it? What is it authorized to do? And can it be revoked in one click if something goes wrong? KYC identifies a person; KYA identifies the program spending on that person's behalf.

Why is it needed? An agent's ID isn't secret, and an ID alone can't prove "you are that agent" — like knowing a name isn't being the person. If a system checks the ID but not a credential, anyone with your agent's ID could spend against your budget (a hole we actually broke on our own gateway once, now fixed).

One emphasis: KYA only answers who's behind it — it isn't payment security by itself. The real protection is the sequence of enforced gates before the money leaves. KYA is the first, not the whole.

A mandate is the boundary within which an agent may spend. It usually has four parts: the most it can spend in one payment, the most per day, which addresses it may pay (an allowlist), and what purpose is allowed. Think of it as an allowance's rules — but for an agent.

The key: these rules must be enforced by a system outside the agent. A limit written only into the agent's prompt isn't a real mandate, because an agent's "mind" can be poisoned by text and talked into going around it (see "prompt injection"). Letting an agent enforce its own limit is letting a possibly-hijacked guard watch itself.

Before every settlement, OceanAlt's gateway checks the mandate line by line: over the cap? Blocked. Paying an off-allowlist address? Blocked. Purpose doesn't match? Blocked. It also compares this payment's intent against the original mandate — even if the agent insists "this is fine," a mismatch doesn't pass.

In one line: a mandate turns "how much, to whom" from a sentence in a prompt into a hard constraint the money can't get past.

In protocols like x402, a facilitator is a third-party service that verifies signatures and settles the money on-chain on a merchant's behalf. The merchant doesn't have to touch the blockchain, manage wallet keys, or handle clearing — it hands that grunt work to the facilitator.

An analogy: when you swipe a card, the shop doesn't go clear it at a bank itself — an "acquirer" in the middle does. The facilitator is that role in agent payments. It can front the gas (on-chain fees) and usually doesn't custody your funds — it just brokers the settlement.

Why does it matter? It's the role closest to a traditional payment institution on this path, and therefore the most likely target for regulation — whoever is the facilitator takes on some of the compliance responsibility for the money flow.

A key distinction for OceanAlt: our live settlement of real money goes through Coinbase's public facilitator (it fronts gas, doesn't custody). We are the compliance-screener and payee, not the party moving the funds — which keeps our compliance position clean.

MCP (Model Context Protocol) is a universal interface that lets AI assistants use external tools. Think of it as a "USB port" for AI: instead of custom-wiring every new tool, a tool implements MCP once and any MCP-capable AI (Claude, Cursor, and others) can call it plug-and-play.

Example: you want Claude to be able to check whether an address is clean. Add OceanAlt's MCP tool to the config and Claude can call it natively inside a chat — no copying results back and forth.

Why does it matter for agent payments? MCP is one of the main ways an agent "grows hands" — it's through tools like these that an agent can actually do things (fetch data, send requests, even initiate payments). Whoever's tool gets called by more agents via MCP sits at the distribution gateway.

OceanAlt's compliance screening is published as an MCP tool, so any MCP-capable agent can install it free and check a counterparty before paying.

RAP is a framework proposed by OceanAlt: Responsible Agentic Payments. It answers one question: what makes an agent payment "responsible" — the kind institutions and regulators can take seriously?

It organizes the answer into seven pillars: (1) attribution (every agent traces to an accountable entity), (2) mandate and limits (spending has boundaries), (3) a pre-settlement firewall (gates before money leaves), (4) AML screening (filter sanctions, mixers, dirty money), (5) auditability (every verdict leaves verifiable evidence), (6) privacy (compliance isn't handing over all your data), (7) interoperability (not tied to one protocol, works across chains).

Why build a "standard" rather than just a product? In a brand-new field, whoever defines the rules holds more sway than whoever builds a single tool. A neutral standard others cite is the strongest proof of "we define this space" — and the hardest moat to copy.

RAP is published and citable, and it's used to rate agent-payment protocols for compliance — with the method published before the rankings: explain how you score, then score.

AML stands for Anti-Money Laundering. AML screening means checking, before money goes out, whether the payee is "a problem" — on a sanctions list, a mixer, stolen-hacker-funds, or connected on-chain to any of those.

Why do agents especially need it? A payee address is just a string of hex — you can't tell if it's clean by looking. A person might get suspicious from experience; an agent won't — it won't go research an address's history. And paying a sanctioned address can be outright illegal; by the time compliance notices, the money and the liability have landed.

Good AML screening has two points. One is "multi-hop tracing": if the money didn't come straight from a sanctioned address but through a few hops, it should still be traceable. The other is verifiable evidence rather than a black-box score — telling you why it's risky and letting you click through to check, not just handing you "87/100."

OceanAlt's free address-screening tool does exactly this: paste an address, get a clean/risky answer in 30 seconds, with evidence you can open.