Agents Can Pay. They Can't Buy. An MPP Update?

In January I argued that the end state of AI in finance is not smarter agents processing dumb documents. It is documents that process themselves: an invoice that carries its own terms, notices when it goes unpaid, and acts.

This spring it shipped as a protocol.

The Machine Payments Protocol is an open specification, co-authored by Stripe and Tempo, that lets software agents pay for things without a checkout page. An agent requests a paid resource. The server answers with an HTTP 402 response carrying the payment requirements. The agent authorizes, retries the request, and gets back both the resource and a receipt in the response headers.

Read that as a finance person instead of an engineer. A 402 challenge is a demand for payment. It is machine-readable. It is signed and bound to the specific thing being sold. It travels in-band on the transaction itself. And it settles with no human, no email, no PDF, and no portal.

That is an invoice. A self-enforcing one. The prediction is no longer a prediction.

So I read the specification for what it does with terms.

An invoice is not a request for payment

The spec covers three billing patterns. Charge intents for one-time payments. Session intents for metered payments. Subscriptions for recurring access. It supports a long list of rails, from tokenized cards to stablecoins on several chains. The listed future work covers custom payment methods, identity workflows, refunds, and payment hooks.

Deferred payment does not appear. Neither do net terms, invoicing, credit, or purchase orders. Every pattern in the protocol is pay-before-access.

This is the distinction the entire agentic commerce conversation keeps missing. An invoice is not a payment request. An invoice is an extension of credit. The document exists precisely because the money has not moved and both parties agreed that was acceptable. Strip out the delay, and you no longer have an invoice. You have a receipt with better timing.

The protocol built the request and skipped the credit.

Prepaid is the easy half

In prepaid commerce, the hard problem is credential security, and the industry has solved it well. Every agent wallet launched this year issues a one-time credential scoped to a single approved amount, so the agent never touches a real card number. This is good engineering. It is also a variation on a problem payments has been working on since tokenization.

In post-paid commerce, the hard problem is judgment. Will this counterparty pay? How late. What happens when they remit a few hundred dollars short with no explanation attached, and the deduction turns out to be a damaged pallet from a shipment six weeks ago that nobody logged?

That is not a payments problem. Nothing in a wallet answers it. It is a credit problem and a dispute problem, and answering it at scale is the entire reason accounts receivable departments exist.

The industry keeps announcing that agents can now buy things. Agents cannot buy things. Agents can pay for things. Buying means entering an obligation and being trusted to honor it later. No agent on the market today can owe anyone money.

The curfew came back

A second tell repeats an argument I made in January about human-in-the-loop.

Every agent purchase running through a consumer wallet today requires a person to approve the total in a chat window. Meta’s Muse does it. Grok Bot does it. Google’s shopping surfaces do it.

For a consumer buying a pair of shoes, that is correct design. For a business, it collapses on contact. A mid-sized company pays hundreds of invoices a month against contracts it already negotiated, purchase orders it already approved, and prices it already agreed to. Re-approving each payment in a chat window is not governance. It is data entry with a nicer interface.

I wrote in February that finance leaders deploy agents like teenagers, with curfews and check-ins and no real decisions, and then wonder why the agents deliver so little. Agentic commerce just repeated it at the protocol layer. The agent got a wallet and kept the curfew.

The correct model already exists in AR and has for decades. You do not approve each payment. You approve a counterparty, a limit, a set of terms, and a tolerance, then you review the exceptions. That is a standing entitlement, and it is what a business wallet needs to grant. Nobody has built it.

Where the credit actually lives

Here is the part that turns this from a gap analysis into a market call.

Credit is a judgment about behavior, and the behavior that matters happens after settlement fails to happen on time. Who paid late. Who short-paid and why. Which deductions were legitimate and which were a buyer stretching. Which disputes closed in the seller’s favor. A payment rail sees the money that moved, and the day it moved. It rarely sees the day the money was due, the reason it came up short, or the argument that came before it.

The systems that see all of that are the ones that issue the obligation. The billing system and the receivables ledger, where an invoice is born, ages, gets disputed, gets partially paid, and finally closes. That is where payment behavior with predictive value accumulates, and it is the raw material a credit product is made of.

This is the same argument I made about the context layer eating SaaS, aimed at payments. Christensen’s law says profits migrate away from whatever becomes modular and toward whatever stays scarce and integrated. Tokenized credentials are becoming modular fast. An open protocol, a public CLI, and a validator make that clear. The scarce, integrated thing is knowing who pays late, and the party that moves the money is not the party that holds that knowledge.

Three additions

The distance between what exists and what business buying needs is smaller than it looks. The protocol is open, so the additions don’t have to come from its authors. Three changes, in order.

First, terms in the challenge. Add a 402 variant where the seller returns the resource along with an obligation instead of a paywall. The response carries the number of days, whether a purchase order is required, and the tolerance band for price and quantity. The agent presents an entitlement rather than a credential. An invoice object settles on the due date.

Second, remittance in the receipt. The protocol already returns a receipt. Make it say which invoices, which line items, what was deducted, and why. The oldest problem in cash application is that the money and the explanation travel on separate rails and arrive on different days. Fix that in the protocol, and agent-paid invoices reconcile at rates human-paid invoices never reach. That gives a seller a real reason to prefer agent traffic, which is how a rail gets adopted.

Third, dispute as a verb. Real business payments arrive short. Give the protocol partial payment and dispute with reason codes, so a deduction becomes a structured object at the moment of payment instead of a mystery in a bank file three days later.

None of this needs new cryptography. It needs someone who already understands the obligation to decide that the protocol is worth extending.

The part everyone has backward

The consensus view is that agentic commerce starts with consumers and works its way into business over time. Checkout first, procurement later, because consumer is simpler and the volume is bigger.

I think that reads the difficulty backward. Consumer agent checkout is where the problem is easy, and the value is thin, because the credential was already solved and the margin on a tokenized card payment is a few basis points. Business buying is where the problem is hard, and the value is thick, because what’s being sold isn’t a credential. It is trust, priced.

Agentic commerce will arrive through accounts receivable. It will arrive there last, because that is where the difficulty is concentrated, and it will be worth more than everything that arrives before it.

The prediction people keep repeating is that agents will buy things. They already can pay. What no agent can do is owe. Commerce runs on obligation, not on settlement. The first party that gives an agent the ability to owe money, and gives a counterparty a reason to accept that debt, will own this category.

It will not look like a checkout button. It will look like an accounts receivable department.