Can an AI agent pay for something on its own?

Yes. Several rails support it today: delegated mandates on card networks, HTTP-native payment schemes, stablecoin settlement, and simple prefunded balances. What none of them fully solves is who is responsible when the agent buys the wrong thing.

Why can’t agents just use a credit card?

They can, within limits, but card systems are built around a cardholder confirming a total. Remove that step and fraud scoring, strong customer authentication and chargebacks all lose their anchor. There is also a hard cost floor per transaction, which makes sub-cent payments impossible.

What is an agent payment mandate?

A verifiable credential stating what an agent may spend, on what, and until when - issued when the person authorises the agent, and presented to the merchant at the time of payment so it can be checked without contacting the principal.

Are agent payments safe for consumers?

Partly. Where the payment runs on card rails, existing protections largely carry over. Where it runs on stablecoin or HTTP-native rails, payment is final and there is no dispute mechanism at all - which is acceptable for very small amounts and not for anything else. Cap what an agent may commit to accordingly.

Can AI Agents Make Payments?

Technically, yes, and several rails already handle it. That answer is also close to useless, because moving the money is the easy part. The hard parts are authorisation, dispute handling and liability, and they are hard for reasons that have nothing to do with payments technology.

Why existing rails struggle

Card payments are built around a cardholder who can be shown a total and asked to confirm. Nearly every protection in the system derives from that moment: fraud scoring assumes a person and a device, strong customer authentication assumes someone to challenge, chargebacks assume a cardholder who can say "I did not authorise this".

Remove the confirmation step and the whole apparatus loses its anchor. This is why agent payments are not a matter of plugging an existing API into a loop - the authorisation model has to change, not the transport.

There is a second, more mundane problem: fixed per-transaction cost. An agent that pays a tenth of a cent for a structured answer, several thousand times a day, is economically impossible on rails with a per-transaction floor measured in cents.

The four approaches in play

1. Delegated mandates on existing rails

The card networks' answer. The cardholder authorises once, and the agent receives a credential describing exactly what it may spend, on what, within what window. The merchant sees a transaction marked as agent-initiated with a verifiable mandate behind it, and the network can route disputes accordingly.

Strength: works inside a system that already has fraud handling, consumer protection and universal acceptance. Weakness: inherits the cost floor, so the sub-cent case remains impossible. Competing incompatible schemes at present.

2. HTTP-native payment

Treating payment as a property of a request rather than a separate checkout: a resource responds "payment required", the client attaches proof of payment and retries, the resource is served. The idea is old - the HTTP status code has been reserved since 1997 - and became practical once settlement got cheap enough to be worth doing per request.

Strength: no account, no session, no signup. An agent can pay a service it has never encountered, mid-request. Weakness: no dispute mechanism at all. Payment is final, which is fine for a tenth of a cent and unacceptable for anything larger.

3. Stablecoin settlement

Account-to-account transfer in a stable unit, settling in seconds with costs low enough that micro-amounts survive. Frequently the layer underneath the HTTP-native approach.

Strength: granularity and counterparty reach - parties with no relationship, no shared bank and no contract can settle. Weakness: irreversible by design, uneven regulatory treatment, and it moves the consumer-protection problem rather than solving it.

4. Prefunded accounts and credit

The boring one that most production systems actually use: the agent operates against a balance topped up in advance, or a post-paid account with a limit. All the trust questions were answered once, by humans, when the account was opened.

Strength: works today, everywhere, with no new standards. Weakness: requires a pre-existing relationship with every counterparty, which is exactly what agents are supposed to make unnecessary.

Approach	Sub-cent amounts	No prior relationship	Dispute path
Delegated card mandate	No	Yes	Yes, inherited
HTTP-native payment	Yes	Yes	None
Stablecoin settlement	Yes	Yes	None
Prefunded account	Yes	No	Contractual

No row has all four properties. That is the current state of the field stated as compactly as it can be, and it explains why deployments pick a rail per use case rather than adopting one.

The three questions that are not about payments

Authorisation. How does a merchant verify that this agent may spend this much on this, right now - without calling the principal? That is an identity and mandate problem, and it is upstream of every payment rail.
Dispute. A consumer who buys badly has chargebacks, withdrawal rights and a regulator. A consumer whose agent bought badly falls into a gap: the transaction was authorised, the outcome unwanted, and the protections were written for a click nobody made.
Liability. The agent books a non-refundable flight to the wrong city. User, deployer, or model provider? Unsettled everywhere. This is why every serious deployment caps what an agent may commit to, and why the cap is usually low enough that the answer never has to be found.

Agent payments are not blocked by cryptography or by banking rails. They are blocked by the absence of anyone to blame.

What to build now

If you are on the paying side: use prefunded balances with hard caps, log every authorisation decision in a form you could show a third party, and keep human approval above a threshold you set deliberately rather than inherit.

If you are on the receiving side: be able to tell an agent-initiated payment from a human one, record the mandate you were shown, and decide in advance what you will do when someone claims their agent was not authorised. That decision is coming whether or not you have made it.

The wider commercial picture is in autonomous commerce; the protocol layer is covered in the protocols the agentic web runs on.