Machine Payments Protocol (MPP)
stripe.com
stripe.com
MCP was just a glorified way of tool calling but generated so much hype (and it eventually died down). Now we have MPP. Which again - could have just been another tool call exposed to the agent.
Imagine you hire someone who claimed to have invented a new protocol and you're thinking of something like TCP or UDP, but all they share is just a markdown file.
I almost was going to point it out as evidence there was thought put into it. Nope, it's flimsy and AI generated.
Also, it contains provisions for scamming customers:
> 403 indicates the payment succeeded but access is denied by policy
No, it doesn't explain how to refund payments for customers you deny access to.
> Servers MAY return 402 when:
> * Offering optional paid features or premium content
This implies that a successful GET request to a resource that user already does have access to, might still return 402 instead of 200. This makes 402 basically unworkable.
Are you open to contributing to this RFC?
On topic though, Stripe is trying to make themselves the Visa/Mastercard of crypto. They're in position to do so and it seems like Coinbase is their other half. I don't trust or like it though.
Every time I see one of these I think "You are just describing an API".
there's nothing wrong with calling this a protocol. the problem is in hyping it up as though every protocol is going to be world-changing on the level of TCP.
And as to use cases, if I want quality outputs for automated research and discovery of a topic, in a world where quality journalism/scholarship should be compensated and does use tools like Cloudflare to block automated access, and where AI-generated content is everywhere, it's optimal for me to want to spend some amount of the money I spend on tokens, on the ability for my agent to access reputable primary and secondary sources as needed.
The challenge, of course, is that now there's an incentive for a spam source to try to get my agent to pay it, rather than the actual creator of the content. But there are interesting ways to solve this, because with these payment rails there's now an incentive for alliances of content creators to maintain indices of reputable sources and their canonical domains - perhaps even authoritative hashes of content. Lots of possibilities here.
I read this line and my (poor little) brain ran in a whole other direction for a moment. Because AI token management and "parental controls" aren't that far separated functionally.
How far are we from the AI companies selling token packs like video games sell premium currency? Buy NOW, 1.99 for 10,000 Anthropic gold...
And the gacha gaming industry knows exactly how to monetize this kind of trained instinct in a userbase. One might even call it a sense of pride and accomplishment...
(But, to my larger point, if agentic harnesses can offer their LLMs a source of reputable input tokens from professional content providers, as an alternative to just more token back-and-forth with the model provider... that harness can at least direct some of that money towards producers of well-researched content.)
There’s that, but it could also be adaptation to the fact users… just don’t know what to do with it.
Just like the prompt suggestions they added for new conversations a little time after releasing the first app. Those seem to be mostly gone now, at least on mobile.
> You're absolutely right! The transaction was submitted as $500,000 instead of $5.00. Since that's what was entered on your end, you'll need to contact your bank to resolve it. I will generate a letter for you to print, sign, and send to your bank if needed. Would you like me to generate a bankruptcy filing for you as well?
Is this an attempt to get multiple payment processors to adopt the same Payments API so that agents fail less often?
It's an API for making purchases instead of interacting with a website of unknown flow.
> We believe agents will become an integral part of the internet economy, and they need the ability to transact with businesses and one another.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, recurring payments, and more.Regulation E limits your losses for electronic banking. Is this new payment system covered by Regulation E? What is the maximum loss a consumer would experience?
How people here are handling this. When your agent hits a $35 API call, or gets stuck in a retry loop on a $0.50/req service, what stops it from draining the wallet?
Are wallet-level caps enough? Are you writing custom budget checks in your agent code? Or just not worrying about it yet?
We built an open source MCP proxy (github.com/policylayer/intercept) that enforces policy on tool calls. Thinking about extending it to read the -32042 payment challenge, check the amount against a budget, and allow/deny/hold for approval before the wallet pays.
Would love to hear if this is a real pain or a theoretical one.
A well thought out proposal for the long term, unlike MCP which is a complete joke of a "standard" and broken by design.
[1] https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment...
Please let us know if you have suggestions of what complex workflows you would like to build.
But then I also wonder if this attitude "Why should I waste time thanking it?" will also spread to human-human interactions?
https://www.tomshardware.com/tech-industry/artificial-intell...
Really, they _need_ it. How can we possibly live without computers spending money without supervision?
This MPP helps bridge the gap between the agent putting the product "in the basket", to actually completing the full purchase process.
Disclaimer: I'm not in any way advocating for this use case, but it's part of my job to understand how it works. Part of what I do is try to help Agents understand, for example, what is "an efficient dishwasher" using actual data, and not hallucinated info.
In other words, if Agents are able to navigate marketplaces, shouldn't that imply they can also navigate a subset of the marketplace, the payment section? Especially given that that section is "easier: theres no need for qualitative (or quantitative) judgement like there is for the shopping portion.
Perhaps its a matter of proper safeguards?
As I said, it doesn't have to make sense, but this is being pushed on us anyway...
It seems like this workflow suffers the same problem as Alexa and Amazon dash buttons: consumers don't typically want the computer to just go buy things for them with no oversight. At least I don't.
Adding a checkout step would make this more plausible to me. "Agent, go find the most efficient dishwasher under $600" where it adds its recommendation to a cart, or even "Find me the best dishwashers under $600" where it creates a catalog page with its recommendations and an easy checkout process with whatever store is actually providing.
Not trying to be snarky here, your problem space must be awfully complex.
Similarly with paywalled sites like the New Yorker or research journals - If the LLM came back to you and said "I've found these 5 articles. Do you want me to add them as sources to summarise (access cost: $0.05)?" or you give it a budget upfront "Access whatever you think is most useful, but don't spend more than $0.10"
At the moment, sites either allow bots full access or block them, but this could provide a middle ground.
(a) Transaction fees. Network fees make microtransactions prohibitively expensive. This is the real problem.
(b) 3DS & latency issues If (a) is still the same, then meaningful transactions (eg.new accounts) would require human validation of sorts, which tenders the MPP use case very small.
Let's say I wanted to ask an agent to use Google Maps APIs to produce a look-up of all bakeries in a city, say, and then find all their mentions across platforms - e.g. Twitter, Reddit, Yelp, etc etc.
Without something like this, I'd need to manually set up accounts across multiple platforms, all with different billing/subscription cycles. Go through account set-up/validation. Then give an agent an API key with potentially unrestricted access — it might run up a huge bill, or could get my account suspended if it goes a bit haywire and starts spamming calls, say.
If vendors decided to all support the protocol, I could give an agent $10, tell it the task and let it go without any of the manual handholding but with a hardcap on what it can spend if something goes wrong.
Yeah I read that copy too, did you read the spec?
Note the absence of invoices, bills of lading, and receipts, all the things you need when a vendor doesn't deliver. All it does is send money, one-way. So it's useless in a B2B context.