Emerging Payment Protocols#
Agents can already call APIs. The harder part is paying for them without human checkout, account creation, or long-lived billing setup. Hightop supports x402 and MPP so payment can happen inside the same machine-to-machine request flow.
These protocols matter because they let agents pay external services programmatically from the same Hightop account and control lane they already use for the rest of their money workflows.
The broader landscape is larger than x402 and MPP. Other work is happening around delegated commerce protocols like the Agentic Commerce Protocol and the Universal Commerce Protocol, trust layers like Visa's Trusted Agent Protocol, and wallet standards like the Open Wallet Standard. x402 and MPP are the clearest machine-payment protocols to anchor this page because they are already concrete ways agents can pay from Hightop.
The Mental Model#
x402andMPPare supported payment protocols for machine-to-machine requests, not separate wallet or account systems.- Both try to make "access the service" and "pay for the service" happen in the same HTTP flow.
- They sit at the edge of Hightop, not at the center of it.
- Their presence does not change Hightop's role. Hightop still provides the funded account, the lane, and the limits around that agent.
Why This Matters#
Most web commerce still assumes a human:
- create an account
- generate API keys
- choose a pricing tier
- enter card details
- manage credits or subscriptions
That model works for humans. It works much less well for agents that need to buy one API call, one tool invocation, one browser session, or one dataset query.
Emerging payment protocols try to shrink that gap by making payment part of the access request itself.
What x402 Is#
x402 is an open payment protocol developed by Coinbase and built around HTTP 402 Payment Required. A service can return payment requirements, the client can pay programmatically, and the request can continue in the same HTTP flow.
It is most naturally associated with crypto-native, pay-per-request access to APIs, content, and other HTTP services.
What MPP Is#
MPP, short for Machine Payments Protocol, is a newer machine-payments protocol introduced by Stripe and Tempo. Like x402, it is meant for machine-to-machine payment flows. MPP covers more than simple API paywalls and includes both crypto and fiat-style payment models.
The simplest way to think about it is that MPP is another attempt to make agent payments native to the request flow rather than a separate billing setup.
Where Hightop Fits#
Hightop is not itself x402 or MPP. Hightop is the account and control layer your agents use to hold funds, operate inside lanes, and stay under control while they interact with the outside world.
That means Hightop is not trying to declare which protocol wins. The goal is to stay useful across the payment standards that become real in practice.
These protocols are not mutually exclusive. Hightop can support multiple payment surfaces at once inside the same account and control model.
Hightop already provides:
- one funded account
- one lane per agent
- permissions, limits, and approved payment behavior
- monitoring, alerts, and revocation in the app
x402 and MPP plug into that existing model. An agent still pays from the same Hightop account, through the same lane, under the same permissions and limits.
A simple example helps. Imagine your research agent needs to pay per request for a data API that supports x402. Instead of opening a separate billing account with that provider, Hightop lets the agent pay through its Hightop lane. The payment still draws from the same account balance and stays subject to the permissions and budgets you configured.
In other words, these protocols are additional payment surfaces, not a second money system inside Hightop.
What to Expect#
This area is still early even though it is already usable.
- standards are still evolving
- provider support is uneven
- payment methods and chain support vary by implementation
- support matrices can change quickly, so builders should still check current provider docs before designing around one protocol
- builders should treat the ecosystem as early rather than as a settled replacement for every existing billing flow
This is the right time to understand where things are heading, not to assume the ecosystem has fully converged on one stable pattern already.
Where to Go Next#
- Build on Hightop for the practical integration pattern for existing agents
- API Overview for how the Hightop API relates to the app and the rules model
- How Hightop Works for the broader product model
- Architecture for how the app, API, control layer, wallet, and protocols fit together