Agentic Payments: How AI Agents Will Pay, and Who Stands Behind the Bill

An AI agent buying something on your behalf used to be a demo. In 2025 the major card networks and several platforms announced agentic commerce and agentic payment programs, and the idea moved from slideware toward pilots. The plumbing to let an agent initiate a purchase is arriving. The harder question is the one a payment rail does not answer on its own: when an agent pays, who stands behind the bill?

A quick note on what follows. Some of this is live, some is still being designed. We will say which is which.

What "agentic payments" actually means

Strip away the marketing and an agentic payment is a transaction initiated by software acting for a person or business, without a human approving each step in real time. You tell an agent to keep the office stocked, book travel under a policy, or rebalance a budget, and it transacts when conditions are met.

That covers a range of designs:

• An agent that holds or is issued a payment instrument (a card, a token, a wallet handle) and pays directly.
• An agent that proposes a purchase and hands a structured request to a checkout that completes it.
• An agent that operates inside a platform's own commerce flow, where the platform is both the rail and the referee.

What these share is automation of the decision to pay. What they do not share, yet, is a common way for the other side to know who the agent answers to. The card networks are building the money movement. The identity layer underneath is the part still under construction, and it is the part that decides whether agentic payments are safe to scale.

Why the missing piece is identity, not a rail

It is tempting to treat agentic payments as a payments problem. Get the agent a card or a token, route the authorization, settle the funds. That solves how money moves. It does not solve the question every counterparty actually has: should I accept this instruction at all?

Consider a refund dispute. A charge appears, initiated by an agent, for an amount the cardholder did not expect. The network can trace the funds. But the substantive question is whether the agent was authorized to spend that much, in that category, at that moment, on behalf of an identifiable person who can be held accountable. A payment rail answers "did the money move." It does not answer "should it have." That second question is an identity and authorization problem.

This is the same gap we wrote about in Know Your Agent: the counterparty needs to know whether an agent is authorized, whom it acts for, and within what mandate. Agentic payments make the gap financial. The cost of getting it wrong is now denominated in dollars and chargebacks, not just bad data.

The shared-secret trap

The fastest way to give an agent spending power is also the most dangerous: hand it a secret. An API key, a stored card number, a password to a logged-in session, a long-lived token. The agent presents the secret, the system assumes the secret means consent, and the purchase goes through.

This works in a demo and fails in production for a few reasons:

• A secret proves possession, not authority. Anything that can read the key can spend. A leaked log, a compromised dependency, a prompt-injection attack that exfiltrates the token, and the spending power leaks with it.
• Secrets do not carry limits. A raw card number does not know it was meant for a 200 dollar grocery run. Whoever holds it can try to spend anything, anywhere the instrument is accepted.
• Secrets are hard to scope and revoke cleanly. Rotating one key often breaks every agent and integration that shared it, so teams avoid rotating, and stale credentials accumulate.

An agent acting on a shared secret is indistinguishable, to the merchant, from an attacker who stole that secret. That is the core problem. Possession of a credential is being treated as proof of legitimate, scoped authority, and those are not the same thing.

Authority should trace to a verified human

The alternative is to stop asking "does this agent hold a valid secret" and start asking "does this agent's authority trace to an accountable principal, within an explicit mandate." That changes the shape of the credential an agent carries.

A workable structure looks like a chain:

1. A verified principal. A person or business completes identity verification once and holds the result as a credential. This is the reusable KYC model that exists today.
2. A scoped, revocable mandate. The principal authorizes the agent with a credential that encodes what it may do: a spending cap, allowed categories or merchants, a time window, and conditions under which it expires or can be pulled.
3. A verifiable presentation at the point of sale. When the agent transacts, it presents proof that its authority resolves to a verified principal and that the requested action falls inside the mandate.

The merchant or rail checks the signatures and the scope. If the agent asks for something outside the mandate, the check fails before the money moves, not after. Crucially, the principal can revoke the mandate and the agent's spending power dies with it, everywhere, without rotating a shared secret that other systems depend on.

None of these primitives are exotic. Power of attorney, corporate signing limits, and OAuth scopes all express "this entity may act for that one, within these limits." Agentic payments need the same idea, made machine-verifiable, portable across services, and anchored to verified real-world identity. Selective disclosure matters here too: an agent should be able to prove "I act for a verified adult with a 500 dollar monthly mandate" without broadcasting who that person is to every merchant it touches.

Deployed today versus emerging

Honesty about the state of play:

• Deployed. Reusable identity verification, where a person verifies once and holds a credential, exists now. Payment networks have launched agentic commerce and agentic payment initiatives. Tokenization that limits a card credential to a context is mature and widely used.
• Emerging. A standard, cross-platform way to bind an agent's spending authority to a verified principal, with a scoped and revocable mandate that any merchant can verify, is being worked on by standards bodies and industry groups but has not settled. Expect competing schemes before a common one wins.

There is also a compliance question waiting in the wings. Anti-money-laundering and know-your-customer rules were written for humans and legal entities. When agents initiate payments at scale, regulators will ask who performed due diligence on the principal behind the agent. The distinction between verifying a customer, a business, and an agent is worth understanding directly, and we lay it out in KYC vs KYB vs KYA. Firms that can already trace an agent's authority to a verified principal will find that question much easier to answer.

Where OpenKYC fits

OpenKYC is building a reusable KYC marketplace on open standards (W3C Verifiable Credentials, OpenID4VC): verify once, hold the credential in your own wallet, reuse it everywhere, and earn every time it is used. A verified human credential is the natural root for agent authority, the thing a scoped, revocable payment mandate should trace back to. That root is the foundation we are laying. Join the waitlist at openkyc.org.