If an agent can hire another agent, it needs a way to pay. That sounds simple, and it is exactly where the human way of doing things fits the machine world poorly. A credit card assumes an account opened in advance, a monthly billing cycle, and a person who clicks a button that says approve. Agents do not work like that, and forcing them into rails built for people creates friction at precisely the wrong scale.

Why agent payments are a different animal

Consider how an agent actually spends. It may make thousands of tiny payments, each a fraction of a cent, at machine speed, around the clock, for a single data request or one call to another service. Traditional card networks were never designed for that pattern. Their fees would dwarf a payment worth a hundredth of a cent, their settlement is slow, and their whole model assumes a human in the loop who can be asked to confirm. An agent economy needs payments that are instant, tiny, borderless, and automatic, and that requirement has produced a wave of new approaches.

x402, and a forgotten corner of the web

The most discussed of these is x402, introduced by Coinbase and now stewarded as an open project under the Linux Foundation. Its cleverness lies in reviving something old. When the rules of the web were first written, the designers reserved a response code, number 402, labelled Payment Required, and then left it essentially unused for decades because no one had a clean way to fill it in. x402 finally puts that code to work. An agent requests a resource, the server replies that payment is required and names the price, the agent pays, and the server delivers what was asked, all inside a single ordinary web request and with no account arranged beforehand. It turns paying into just another step in a normal exchange between two programs.

AP2, and the question of permission

Where x402 concerns the mechanics of a payment, Google's AP2, the Agent Payments Protocol, concerns permission. The pressing question for anyone letting an agent spend money is not only how the money moves but how a person or business safely authorizes an agent to spend on their behalf, and within what limits. AP2 focuses on that authorization, so that an agent acts within a clear, granted boundary rather than with an open wallet. It has drawn support from a broad group of payment companies, which matters, because payments only work when many parties agree to the same rules.

The rest of the field, and the role of stablecoins

Other serious efforts are underway alongside these. Stripe, working through its Tempo project, has proposed a broader framework for the recurring and coordinated payments that businesses actually run, and the major card networks are building their own agent-ready credentials so that established payment systems can participate rather than be bypassed. A word that recurs across all of this is stablecoin, a form of digital money designed to hold a steady value, usually pegged to the dollar. Stablecoins suit agents because they move between wallets instantly, worldwide, and in amounts far too small for a card to handle economically, while sparing the agent the wild price swings of ordinary cryptocurrency. That combination is why so much agent payment activity settles in stablecoins today.

Two honest cautions

Two things belong on this page in the interest of not overselling. The first is that this area is real but still early, and the total value flowing through agent payments remains tiny next to the ordinary economy. Much of the visible activity is experimental, and a large share settles in a single dollar-pegged stablecoin issued by one company, which is a genuine point of fragility worth watching. The second is that letting software move money on its own raises hard questions of security and responsibility that a payment rail does not answer. A protocol can define how a payment happens. It cannot decide whether a given payment should have happened, who set the agent's limit, or who is accountable if it pays for the wrong thing. Those questions belong to the Rules of Engagement, and they are the reason payments and governance have to be thought about together.