[HN Gopher] Machine Payments Protocol (MPP)
       ___________________________________________________________________
        
       Machine Payments Protocol (MPP)
        
       Author : bpierre
       Score  : 131 points
       Date   : 2026-03-18 15:24 UTC (7 hours ago)
        
 (HTM) web link (stripe.com)
 (TXT) w3m dump (stripe.com)
        
       | NoahZuniga wrote:
       | Didn't stripe already have a payments protocol?
        
         | LoganDark wrote:
         | MPP's supposed to eventually work with more than Stripe.
        
       | david_shi wrote:
       | It seems like this is designed for atomic purchases, could it be
       | extended for subscriptions?
        
         | jacobn wrote:
         | > MPP provides a specification for agents and services to
         | coordinate payments programmatically, enabling
         | microtransactions, *recurring payments*, and more.
        
           | david_shi wrote:
           | https://docs.stripe.com/payments/machine/mpp
           | 
           | Yeah I read that copy too, did you read the spec?
        
             | dabbz wrote:
             | I believe the Shared Payment Token is interchangeable with
             | a payment method id that you attach to a customer object,
             | but that link has very sparse information about how things
             | actually work end to end and what objects mean what.
        
         | lihorne wrote:
         | Hey, I'm one of the developers at Tempo. We're working on an
         | extension type for subscriptions to propose being added to the
         | spec as well! We're starting with the simple types, but
         | subscriptions are a natural extension. The subscription intent
         | will work similarly to a one-time charge--the server returns a
         | 402 with intent="subscription", and the client signs a
         | recurring authorization.
        
           | david_shi wrote:
           | Cool, would be nice to get specifics on how payments are
           | processed, failures, and cancellations re: the recurring
           | model.
        
       | codeulike wrote:
       | _You 're absolutely right! I should have sent $5.00 for that
       | transaction and not $500,000. I will generate a letter for you to
       | print and sign and send to your bank to notify them of my
       | mistake. Would you like me to generate a bankruptcy filing for
       | you as well?_
        
         | ezekg wrote:
         | LLMs rarely admit fault, you gotta shift blame onto the user:
         | 
         | > 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?
        
           | leptons wrote:
           | Claude always says it is sorry for screwing up when I point
           | out that it screwed up.
        
             | fragmede wrote:
             | "Never apologize" into the customized instructions seems to
             | work well for that specific issue.
        
         | leptons wrote:
         | This is the funniest (but seriously not funny at all) thing
         | I've seen on the internet since the start of the whole "AI"
         | craze. And it's all too true.
        
       | simonmales wrote:
       | I guess competition with the Bitcoin equivalent
       | https://www.l402.org/
        
         | jacobn wrote:
         | And https://www.x402.org/
        
       | danlitt wrote:
       | What does this actually have to do with agents? What does the
       | protocol include that makes this useful with AI rather than just
       | a boring old program?
        
         | uxhacker wrote:
         | And would it not be useful to have some kind of human in the
         | middle? For example what is to stop charge backs if no human
         | has actually authorized the transaction?
        
         | XzAeRosho wrote:
         | There's a slightly new topic called Agentic Commerce, where you
         | say for example: "purchase for me the most energy efficient
         | dishwasher with a budget of $600", and the agent will connect
         | via specialized via special MCP Servers and APIs to available
         | stores, and will do the full purchase process for you.
         | 
         | 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.
        
           | seanmcau wrote:
           | I'm probably overlooking something, but what makes the
           | problem of being able to get from item in basket to item is
           | shipping different from choosing which item(s) to put in the
           | basket?
           | 
           | 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?
        
             | XzAeRosho wrote:
             | It's not actually doing browser actions like Playwright or
             | other browser automation tools, rather than direct API and
             | MCP calls/actions. This is a whole new subset of API and
             | connections that are all contained within the Agent
             | context, no browser mocking. That's why they are creating
             | these new protocols, so the full governance can work within
             | the context of the Agent and its available tools.
             | 
             | As I said, it doesn't have to make sense, but this is being
             | pushed on us anyway...
        
               | pythonaut_16 wrote:
               | Thanks for sharing your insights!
               | 
               | 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.
        
           | twalla wrote:
           | As much as I detest having to look at ads or being
           | "influenced" in any way, shape or form, I think the
           | opportunities for exploitation with what you just described
           | is potentially orders of magnitude more harmful. Sure, let me
           | just hand my wallet to a stochastic black box with god-knows-
           | what RL'd biases and then hook it up to adversarial data
           | sources all vying to extract the most money from me - what
           | could possibly go wrong?
        
           | whalesalad wrote:
           | This still does not answer the question. What makes this
           | different from any other API request to Stripe?
        
         | ezfe wrote:
         | That's why it's called Machine Payments Protocol, instead of
         | Agent Payments Protocol
        
       | naomi_kynes wrote:
       | MPP handles 'how do agents pay', but not 'did anyone authorize
       | this'. For low-value API calls that's fine. But once agents start
       | chaining transactions, you need a channel where the agent can ask
       | a human 'I'm about to spend $2k on this, still in scope?' before
       | the payment happens - not a fraud alert after. The authorization
       | layer is a separate infrastructure problem from the payment
       | protocol.
        
       | rvz wrote:
       | This is a good standard that I can get behind [0] since it's a
       | serious proposal and submitted to the IETF [1] for MPP for
       | machine-to-machine payments.
       | 
       | A well thought out proposal for the long term, unlike MCP which
       | is a complete joke of a "standard" and broken by design.
       | 
       | [0] https://paymentauth.org/
       | 
       | [1] https://datatracker.ietf.org/doc/draft-ryan-httpauth-
       | payment...
        
         | dbalatero wrote:
         | Curious since I haven't followed super closely: what's busted
         | about MCP?
        
       | btown wrote:
       | Jokes about wallet-draining aside, we're already giving our
       | agents a real cash budget that they use for tokens. Our harnesses
       | have mechanisms to manage that spend. And having an easily
       | detectable protocol would allow the harness to ensure that its
       | deterministic code is in play to make these payments - you'd give
       | your payment details to the harness, not to the agent itself.
       | 
       | 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.
        
         | zer00eyz wrote:
         | > we're already giving our agents a real cash budget that they
         | use for tokens.
         | 
         | 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...
        
           | ccozan wrote:
           | Last thing I heard: stock options are so last year, AI
           | companies award ... tokens now. Can't find the source now,
           | sorry!
        
           | btown wrote:
           | There was another comment I recall from today, discussing how
           | OpenAI is not-so-subtly adopting a social-network-esque
           | model, in how it's fine-tuned its chat system to always
           | suggest another question that the user might want to ask.
           | 
           | 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.)
        
       | vicchenai wrote:
       | the real question for me is what happens when agents start
       | hitting premium data APIs with MPP. right now if i want my agent
       | to pull realtime financial data it has to go through my API keys
       | with monthly billing. with MPP the agent could theoretically pay
       | per-query directly to data vendors. thats a much better model for
       | bursty workloads but the authorization problem naomi_kynes raised
       | is real - you need spending caps that the agent cant override,
       | not just logging.
        
       | xmly wrote:
       | Fascinating -- this is the future of decentralized finance.
       | Agents will be the entities that both earn and consume.
        
         | film42 wrote:
         | Maybe. When it comes to actual payments, fee structures don't
         | allow for this outside of the laboratory.
        
         | 4k0hz wrote:
         | "Decentralized" seems like a stretch for something developed
         | and promoted by monolithic payment processors.
        
       | gavinray wrote:
       | I fail to see how "API call" is anything inherent to Agents/LLMs?
       | 
       | Is this an attempt to get multiple payment processors to adopt
       | the same Payments API so that agents fail less often?
        
         | ezfe wrote:
         | It has nothing to do with Agents/LLMs which is why it's not
         | called "Agentic Payment Protocol."
         | 
         | It's an API for making purchases instead of interacting with a
         | website of unknown flow.
        
           | gavinray wrote:
           | The text literally starts with:                 > 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.
        
             | ezfe wrote:
             | Obviously agents are the big thing right now, but that
             | doesn't change the fact that MPP is an automation solution
        
       | neya wrote:
       | I feel like the word "protocol", is just abused like it is a
       | glorified marketing term. Kind of like how the word "hacker" was
       | abused in everything else that had nothing to do with hacking.
       | 
       | 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.
        
         | ai-inquisitor wrote:
         | The good ol' folks at Stripe's collaborators Tempo Labs tried
         | to make an RFC-style description page for MPP:
         | https://paymentauth.org/ (full doc on IETF draft page:
         | https://datatracker.ietf.org/doc/draft-ryan-httpauth-
         | payment...)
         | 
         | 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.
        
           | Xirdus wrote:
           | This one is even worse IMO
           | 
           | > 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.
        
             | pertsix wrote:
             | An RFC is a request for comments, contributions.
             | 
             | Are you open to contributing to this RFC?
        
               | pear01 wrote:
               | Was it AI generated? If so, should I just delegate my AI
               | to do so?
        
               | john_strinlai wrote:
               | that doesnt sound nearly as fun as getting upvotes, if im
               | honest
        
               | darkwater wrote:
               | Will they get a slice of the earnings in return by
               | Stripe?
        
           | brendan_j_ryan wrote:
           | Hey! [0]
           | 
           | Am the primary author of the core spec, alongside many others
           | at Tempo and Stripe [0].
           | 
           | As is customary with the IETF draft process, this is our
           | first submission and we expect that we will continue to
           | iterate with the broader community -- including yourself if
           | you are interested in contributing [1]
           | 
           | Thanks for feedback on those two points.
           | 
           | Re: Refunds: This is a payment method specific implementation
           | detail. e.g. this looks very different on cards vs. bank
           | accounts vs. stablecoins. We will provide stronger guidance
           | here to remove ambiguity in the spec
           | 
           | Re: 403: This provision comes from the ability to have
           | _multiple_ Authentication headers, which we view as a
           | necessity for real-world utilization and also compatibility
           | with the Authentication scheme. Similar to the above, we will
           | provide stronger guidance for servers which may support a
           | plurality of authentication schemes and need to handle this
           | edge case.
           | 
           | [0] Had to create a new account since it turns out many years
           | ago I never set an email on my HN profile...
           | 
           | [1] https://github.com/tempoxyz/mpp-specs
        
           | NetOpWibby wrote:
           | I recently redesigned my blog to look like a modern RFC and
           | I'm loving the way they've decided to render tables in their
           | plain text, definitely gonna steal that.
           | 
           | 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.
        
             | ahnick wrote:
             | The best Visa/Mastercard of crypto already exists and is
             | called Flexa. (https://flexa.co/payments#pricing)
        
               | NetOpWibby wrote:
               | Oh wow, I never heard of this. I'm currently working on
               | something similar with the same 1% rate, haha! WELP
        
         | treyd wrote:
         | I think this started when "web3" cryptocurrency projects
         | started using the term to pretend that something which isn't
         | much more than a service that uses a blockchain network to move
         | money around was actually somehow "decentralized" and that that
         | made it more trustworthy.
        
         | devmor wrote:
         | I've been thinking this, but never really put it into words.
         | 
         | Every time I see one of these I think "You are just describing
         | an API".
        
       | sutib wrote:
       | "they need the ability to transact with businesses and one
       | another."
       | 
       | Really, they _need_ it. How can we possibly live without
       | computers spending money without supervision?
        
       | user3939382 wrote:
       | The more industrial activity and investment I see in "payments"
       | and ecommerce, is to me a signal of a hollow society that has
       | ceased creating real value. We have more to contribute than
       | materialism, skimming off of electronic transactions,
       | entertainment etc.
        
       | quantium1628 wrote:
       | the comments here are better than the article lol
        
       | Animats wrote:
       | "Creates a direct connection between your wallet and our bank
       | account!"
       | 
       | 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.
        
       | fhn wrote:
       | All payments are final. Cancellations and refunds will be charged
       | a 5% processing fee.
        
       | glitchc wrote:
       | It feels like an attempt to bypass PCI-DSS...
        
       | giovannibonetti wrote:
       | For those of you in Brazil, my company jota.ai has built a
       | financial AI-assistant that you can chat with to open a bank
       | account, connect with accounts from other banks, make instant Pix
       | payments with any of them, all of that through WhatsApp right
       | now. We're working hard to release long-running agents soon that
       | can do increasingly complex workflows involving payments and
       | whatnot.
       | 
       | Please let us know if you have suggestions of what complex
       | workflows you would like to build.
        
         | ImPostingOnHN wrote:
         | How do you keep customer information, credentials, and access
         | secure from your employees (including yourself)?
        
       | rickydroll wrote:
       | As soon as you have a fungible currency, I expect that, from past
       | experience, everyone who carries those packets will stick out a
       | hand for a piece of the action. From a brief read of the
       | description, I also expect attackers to work out a way to drain
       | your account without you noticing.
       | 
       | 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?
        
       | Christhepurr86 wrote:
       | old article but still relevant. some things don't change
        
       | grigio wrote:
       | There are more competing "payment protocols" than users
        
       | davidliu847386 wrote:
       | tldr for anyone skimming: the key insight is in section 3
        
       | vishnuharidas wrote:
       | Okay, I am NEVER letting an agent make payment autonomously. If
       | there's a payment that has to be made, tell me, I will do that
       | myself.
        
         | benced wrote:
         | This isn't incompatible with the agent placing the purchase. I
         | already let Claude Code do _most_ of what it wants but make it
         | ask permission before sending a message on Slack. An LLM having
         | the capability to do X is not incompatible with it being
         | deterministically forced to seek permission to do X.
        
       | Seventeen18 wrote:
       | Not everything must be a protocol. I believe we will see very
       | interesting attacks vectors in the incoming years, especially
       | when we see how unsafe are most of the agents harness.
        
       ___________________________________________________________________
       (page generated 2026-03-18 23:00 UTC)