A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 from March 18 through July 19, 2026.
On March 18, Tempo announced its mainnet, Stripe published the Machine Payments Protocol and the authors of Payment Auth published a new Internet-Draft. The timing made machine payments look like a single launch event.
The four months since then tell a more complicated story.
Implementation has expanded quickly. Payment methods, session models, discovery patterns and security guidance have all moved. Distribution has also reached major infrastructure through an announced integration between Stripe and AWS WAF.
Evidence of production adoption is much thinner.
That gap is the central finding from my review of the primary record. I examined official announcements, Payment Auth draft history and activity in the tempoxyz/mpp and tempoxyz/mpp-specs repositories from March 18 through July 19. I excluded social posts and treated catalog inventory as inventory rather than news.
The launch established a common HTTP pattern
Stripe’s MPP launch post described an open protocol co-authored with Tempo for machine-to-machine payments. Its examples included per-request charges, recurring payments and existing Stripe merchants accepting agent payments through PaymentIntents.
The related Payment Auth draft defines an HTTP authentication scheme for payments. In broad terms, a server can respond with 402 Payment Required, describe acceptable payment methods and let the client retry with payment credentials.
The distinction matters. Payment Auth is an individual Internet-Draft. It is not an approved IETF standard and the IETF does not endorse it. MPP is an implementation ecosystem built around this emerging HTTP payment pattern.
The launch therefore proved coordinated intent, working implementation and an initial provider path. It did not prove broad adoption.
Payment methods expanded beyond the launch story
The clearest post-launch movement is in the specification repository.
Merged work added or advanced charge methods involving Solana, Stellar, unified EVM, Hedera, USDC and NEAR Intents. The sequence matters more than the count. It shows MPP evolving toward a payment-method-agnostic layer rather than remaining tied to one chain or processor.
That broadening changes the strategic question for payment companies. The issue is no longer simply whether one machine-payment protocol wins. A more plausible future is an HTTP negotiation layer that can present several acceptable payment methods while providers compete underneath it.
This remains an implementation finding. A merged payment method proves that engineers defined and integrated a path. It does not prove transaction volume, merchant demand or production reliability.
Sessions became a major part of the design
The launch examples emphasized transactions such as a paid request. Subsequent repository work advanced session designs for Tempo, Solana and unified EVM.
Sessions matter because many useful agent interactions are not isolated purchases. An agent may need a sequence of model calls, browser actions, data queries or API operations. Paying for every request independently can add latency, signing work and operational cost.
A session model lets a client establish bounded payment authority for continued interaction. That opens more practical product patterns, but it also raises harder questions around spend limits, expiration, revocation and reconciliation.
The repository record shows that these problems are being addressed. It does not yet show which session pattern developers will adopt or how consistently providers will implement it.
Discovery and negotiation are becoming first-class
Another cluster of changes involved Accept-Payment negotiation, multiple payment offers, OpenAPI discovery and service-directory workflows.
This is important because a payment protocol is only useful to autonomous software if the software can determine what is accepted without a human reading a pricing page. A provider may support several methods with different currencies, networks, limits or trust assumptions. A client needs a structured way to choose.
The combination of multiple offers and payment-method expansion suggests a protocol moving from a launch demonstration toward a general negotiation layer.
That is an inference from the specification and implementation sequence. It is not evidence that agents are already selecting among payment methods at meaningful scale.
Security work became more concrete
The repositories also show work on challenge binding, validation ordering and challenge identifiers.
These changes sound less dramatic than a new payment rail, but they are better indicators of protocol maturity. Once an HTTP payment flow moves beyond a demo, implementers must prevent credentials from being replayed, attached to the wrong challenge or accepted before required validation.
The Payment Auth draft also moved from draft-00 in February to a new version on March 18 with more detail around protocol behavior and registries. Again, this is active specification work rather than standards approval.
For buyers, the key point is that security semantics are still part of the moving surface. Teams should not evaluate an integration only by whether a 402 response can be completed.
x402 looks more like an interoperability question than a binary rival
MPP repository work includes x402 proxy or compatibility examples. The broader design also allows negotiation among payment methods.
That does not prove convergence between MPP and x402. It does suggest that implementers expect more than one payment convention to exist and see value in bridging them.
This changes how I frame the market. “Which protocol wins?” is probably less useful than “Which discovery, credential and settlement patterns become portable across providers?”
Protocol teams should watch where compatibility becomes a maintained implementation rather than a one-off demo. Payment companies should watch which abstraction owns the merchant relationship. Investors should distinguish protocol mindshare from durable distribution.
Distribution reached AWS infrastructure, with an important caveat
In June, Stripe and AWS announced an integration with AWS WAF that lets content owners respond to AI crawlers with HTTP 402 and payment terms.
This is strategically important because AWS WAF sits at a distribution point that already protects web infrastructure. Payment negotiation there could make machine-payable access available without every publisher building a protocol stack from scratch.
The caveat is equally important. The announcement described the ability for content owners to receive funds as coming soon. It is evidence of a serious distribution commitment, not proof that the full commercial workflow was already operating at scale.
What the primary record does not show
From March 18 through July 19, the MPP repositories recorded hundreds of commits and merged pull requests. Most were documentation, tests, maintenance or incremental implementation work.
That activity is healthy. It is not a demand metric.
The primary sources reviewed here do not provide transaction volume, retained providers, payment success rates, repeat agent usage or merchant revenue. They also do not establish that a catalog entry is active or that a public demo has durable users.
The strongest conclusion is narrower: machine-payment infrastructure is becoming more capable, more payment-method agnostic and more operationally serious. Verified adoption has not yet caught up with the implementation narrative.
That is exactly why classification matters. A useful intelligence practice must preserve the difference between a proposal, an announcement, a merged implementation, a release and a verified deployment.
I built MPP Pulse to make that distinction repeatable. It is an open-source AWS agent that collects primary evidence, rejects unrelated links and drafts a cited weekly brief for human review.