The credit card is the wrong interface for AI agents

Take a credit card apart as an interface and count the human assumptions. A sixteen digit number typed by a person. An expiry date read off plastic. A three digit code from a physical card. A redirect to a bank page where a person answers a challenge. An address chosen from a dropdown. AI agent payment infrastructure inherits every one of those assumptions, and each of them is a place where an agent stops or lies.

The three steps an agent cannot take

• Reading a code from a message. Strong customer authentication is designed around a human who can receive and type a one time password. An agent can neither receive it nor ask a user to type it without becoming an inbox. Where this has to work, the answer is issuer configured: the issuer decides whether the transaction gets a challenge, a re-route, or neither, and that decision lives on their side, not in the agent's.
• Answering a challenge. Mastercard's description of agent payments mentions strong customer authentication leveraging on device biometrics. Visa's developer documentation describes tokens bound to user devices, secured with passkeys, with every user instruction authenticated. Both assume a person who is present and holding something.
• Choosing from a form. An address, a shipping option, a saved cart. Every one is a dropdown, and every dropdown is a point where the agent has to guess or ask, and asking is the thing we are trying to stop doing.

None of this is an argument against the card. For a person buying something, this interface is thirty years of optimisation and it works. The argument is narrower: an agent cannot use it as designed, so the parts of the flow that have to be automated end up being automated by pretending there is a person.

What is being built instead

The direction is visible in the primary documents, and it is the same direction every time: bind the credential to something other than the account. Visa describes agent specific pass through payment tokens, bound to the agent making the purchase. Stripe documents a Shared Payment Token as a credential bound to a mandate rather than to a card number. Reap publishes a credential minted at the moment a payment intent is created, capped to the approved amount and restricted to the merchant, with the claim that it needs no one time password, no phone tap and no human.

Google's protocol work is the clearest statement of the shape. The payment mandate in the Agent Payments Protocol authorises a payment against a specific instrument and is shared with the credential provider, the networks and the merchant payment processor. That is an interface contract between four parties, written down before the transaction, which is the opposite of what a card number is.

It is worth noticing how unsettled this area still is. Visa's own developer page for these services says the product is in the process of development and deployment, that the depictions are representations of potential features, and that the final version may not contain all of the features described. A solutions page adds that it is a representation of the potential features of the fully deployed product. Nobody in this category can tell you what the final interface is, including the people building it.

The interface should carry intent, not instrument

Here is the distinction I keep testing my own designs against. A card interface asks which instrument to charge. An agent interface asks what was authorised. The instrument is then chosen, in the last possible moment, by something that can change without breaking anybody's expectations, which is exactly the property you want from a layer that has to survive a change of provider.

Concretely, the request that crosses the boundary should say: this agent, acting for this principal, under this mandate version, is asking to pay this merchant this amount for this purpose, and here is the evidence that the instruction existed. Everything else, which credential, which rail, which token, which network, is an implementation detail below that line. Every product in this category that puts the instrument in the request and the intent somewhere else is going to rewrite the request the first time a provider changes.

A working version of this interface looks like four agreements instead of one form. The agent presents an authorisation, signed, with a mandate reference and an amount and a merchant. The merchant accepts an authorisation and gets a promise of settlement. The issuer honours a token that carries the authorisation inside it. The processor moves money and returns a reference that lands back in the same record. Four parties, one object, and no step where a person's attention is required to translate between them.

The reason this is hard is not the cryptography. Every piece of it exists in production somewhere. The hard part is that it requires four companies to agree, and the only reason they will agree is if one of them is unwilling to do the work alone. That is the entire commercial strategy of this category, and it explains why the interesting companies are the ones building a mandate rather than a checkout.

The part I am still arguing about

There is a version of this argument that becomes an argument for rebuilding payments, and I do not support it. The rails are excellent, the tokenisation is excellent, and the failure above the card is a failure of authority, not of pipes. The right amount of work is a layer that reads like a mandate and settles like a card, not a new network. Two of the mandate layer companies I have written about publicly make the same bet from opposite directions: one mints a licensed card credential per payment intent, the other refuses to be a processor at all and sells the mandate instead.

I am building the middle of that at Noesia: not a network, not a licence, an authorization layer that an existing processor can sit behind. The credential argument is in an AI agent should never have your credit card, the record that makes the interface auditable in what an agent authorization record should contain, and the wider case in the money layer for AI agents. If you have built the interface the other way and it works, write to me. That is the argument I want. The moment it started for me is the moment my AI agent asked for my credit card.