MPP and x402: A Price Tag for the Internet

Imagine you ask a travel assistant to plan a weekend away. It finds a weather service with a better forecast, a local guide with a useful map, and a small tool that can translate the train schedule, but it only needs each service once.

Today, each stop might ask the assistant to create an account, choose a monthly plan, enter billing information, and collect an API key. It is like walking into a market to buy one apple and being told to join three warehouse clubs first.

This is the problem MPP and x402 are trying to solve. Both give the internet something surprisingly basic: a machine-readable price tag. A service can say, “This request costs two cents. Here are the ways you can pay.” The assistant can decide whether the purchase fits its budget, pay, and continue its work.

That leaves an important question: what does the assistant actually pay with? Neither protocol creates money or gives an assistant an unlimited wallet. They standardize the conversation at the checkout counter, so there is no pricing page, annual plan, or human stopping to fill out a form. The protocols differ, but the shared idea matters more than the rivalry: payment moves closer to the thing being purchased.

#When a website answers with a price

The web already has a simple vocabulary for common problems. A 404 means a page cannot be found. A 403 means you are not allowed through the door.

There is also a 402, which means “Payment Required.” It has existed for decades, but the web never agreed on what should happen next. The sign said payment was required without explaining the price, the acceptable payment methods, or how to prove that payment happened.

MPP and x402 fill in that missing conversation. Instead of ending at “payment required,” the service can explain the price and the acceptable ways to pay. The basic exchange looks like this:

1. An assistant asks a service for something.
2. The service responds with 402 Payment Required and a digital price tag.
3. The assistant checks the price against its rules and budget.
4. If the purchase is allowed, it pays and repeats the request with proof of payment.
5. The service opens the door and returns a receipt.

Think of a toll road. The car approaches, sees the toll and the accepted payment options, pays, and continues without signing a twelve-month contract. That does not mean the car can spend without limits. A useful assistant still needs a budget, rules about where it may shop, and perhaps a person’s approval for larger purchases. The protocol handles the toll booth; it does not decide where the car is allowed to go.

#Where the money comes from

Imagine a restaurant bill with a QR code. The code can tell your banking app who should be paid and how much is owed, but it does not put money in your bank account. MPP and x402 work in roughly the same way: they can carry the price, accepted payment options, and proof that a payment was authorized, while the funds still come from somewhere the buyer already controls.

The word “wallet” can make this confusing because it describes several different things. A crypto wallet controls assets such as USDC, a digital token designed to track the value of the US dollar. A consumer wallet such as Stripe’s Link can hold a saved card or bank account. A programmatic wallet can sit between an assistant and either kind of money, keeping sensitive credentials hidden while enforcing spending rules.

The important distinction is between the money, the permission to spend it, and the protocol that carries that permission to the seller.

The word “token” is doing two different jobs here. In “USDC token,” it means the asset being spent. In “Shared Payment Token,” it means a temporary credential that grants permission to charge some other source of money. The same word does not mean the same thing.

#Paying with x402

Suppose the travel assistant asks for a two-cent weather report and the service accepts USDC on a particular blockchain network.

The x402 price tag tells the assistant which asset the seller accepts, which network to use, and where the payment should go. The assistant then asks its connected wallet to authorize the payment. That wallet must already control the right asset, just as a transit card must already have a balance before it can open the gate.

The owner might have funded the wallet earlier from a company treasury, transferred USDC from an exchange, or bought it through a separate on-ramp. x402 does not perform that funding step. If the wallet has no compatible balance, the assistant cannot pay until another system funds or converts it.

The wallet signs the payment instructions. In plain language, it adds a tamper-resistant approval that says, “This wallet authorizes this payment under these terms.” The seller or an optional facilitator can verify that approval and complete the transfer. A well-designed setup lets the assistant request that signature without ever seeing the wallet’s private key, much as an employee can use a company card without having access to the company’s bank account.

#Paying with MPP and Stripe

Now imagine the same assistant buying a train ticket from a seller that accepts Stripe payments through MPP.

The buyer might use Stripe’s Link wallet for agents, backed by a card or bank account already saved in Link. After the buyer approves the purchase, Link can produce a Shared Payment Token, usually shortened to SPT.

An SPT is not a cryptocurrency and it does not contain money. It is closer to a sealed, single-use permission slip. It tells Stripe that a particular seller may charge the underlying payment method, within limits such as the currency, maximum amount, and expiration time. The assistant passes that permission slip to the seller. The seller uses it in its normal Stripe payment flow, and Stripe charges the card or bank account behind it without exposing the raw account details to the assistant or seller.

This is where the restaurant-bill analogy stops fitting. A payment credential does more than repeat the price. It can also constrain who may collect the money, how much they may collect, and how long the permission remains valid. Stripe, not the prose in the assistant’s prompt, enforces those limits.

SPTs are one MPP payment method, not the definition of MPP. The same MPP checkout conversation can offer a stablecoin wallet, a card-based method, or another compatible payment rail. If it uses a stablecoin method, the source of funds looks much more like the x402 example: the buyer needs a funded wallet and authorizes a transfer from it.

So the clean mental model is this: the wallet supplies access to money, the payment credential grants limited permission to use it, and MPP or x402 carries the checkout conversation. The protocol is the language spoken at the counter, not the bank account behind the buyer.

#How MPP handles checkout

The Machine Payments Protocol, designed by Tempo and Stripe, treats payment a little like the way websites already ask for passwords or access tokens.

A service presents a payment challenge. The buyer returns a payment credential. The service checks it and returns a receipt. The technical version uses familiar web headers such as WWW-Authenticate, Authorization, and Payment-Receipt, but the useful idea is simpler: the request and the payment speak the same language.

MPP has to answer two questions. The first is what kind of purchase is happening. It might be a one-time charge, like buying a train ticket, or a session, like opening a tab at a cafe. With a session, the buyer authorizes a limit once, then the tab grows as it consumes tokens, API calls, or computing time. The service can settle the bill later instead of stopping for a new payment after every sip of coffee.

The second question is how the buyer will pay. MPP supports different payment methods, including cards, payment processors, blockchains, stablecoins, and the Lightning Network. The core protocol provides the shared checkout conversation, while each payment method explains how the money actually moves.

This flexibility is useful, but it creates a practical requirement. A universal phrasebook only helps when both sides know at least one of the same languages. Buyers, sellers, wallets, and payment providers still need compatible implementations.

MPP’s core document is also an Internet-Draft, not a finished internet standard. It describes a direction that is still being tested and revised.

#How x402 packages a payment

x402 starts from the same 402 response but organizes the payment differently.

Imagine the payment as a package. The envelope explains what is owed. The payment scheme explains how the package should be handled. The network explains which road it travels on.

The seller can check and settle the payment itself, or it can use a facilitator that works like a payment concierge. The facilitator understands different networks, verifies the buyer’s payment, and helps complete settlement so the seller does not have to build every connection itself. Facilitators are useful but optional; a seller can do the work directly or run its own.

x402 grew from stablecoin and blockchain payments, where small payments can move without a traditional card checkout. Its current scope is broader than one coin or one chain. It also supports several ways to pay:

• exact is the simple toll. Pay a known amount for a specific resource.
• upto is a capped meter. Approve spending up to a limit, then settle the actual usage.
• batch-settlement is a jar of receipts. Record many tiny purchases and settle them together later.

The last two matter because a two-cent service stops being attractive if processing the payment costs more than the service itself.

x402 is evolving too. Its second version made it easier to add new networks and payment models, and it began laying the groundwork for reusable access. In July 2026, the x402 Foundation became operational under the Linux Foundation after Coinbase contributed the protocol. That gives the project a neutral governance home. It does not guarantee that the market will choose one technical approach.

#Two routes, one checkout

MPP and x402 are often presented as a race, but that framing hides the more useful comparison. MPP begins with the checkout conversation: what kind of purchase is happening, and which payment method can satisfy it? x402 begins with the payment envelope: which scheme describes the transfer, and which network will carry it? Both now handle more than a separate payment for every request. MPP has the running tab of sessions, while x402 has capped payments and batched settlement.

They can also coexist. MPP’s mppx software now supports compatible x402 payments. A seller can offer both, then accept the option a buyer understands. This is less like choosing one global credit card and more like a shop accepting cash, cards, and mobile wallets at the same counter.

The wire formats are still different, so compatibility does not happen by magic. Software has to support or translate them. But the existence of that translation suggests that protocol choice may become an implementation detail rather than a permanent dividing line.

#What changes when software can pay

If this pattern works, some online services may stop requiring a relationship before every transaction. An assistant could buy one useful result from a service it has never seen before. A small developer could sell one specialized operation without inventing subscription tiers. Prices could become more closely tied to the work itself: one search, one minute of compute, one translation, or one completed task.

Payment could also become more separate from identity. A receipt can prove that someone paid the toll, but it does not necessarily prove who was driving, who gave them permission, or whether they should receive access again tomorrow. For a small purchase, that may be enough. It looks a lot like guest checkout.

Other relationships still need identity. Refunds, subscriptions, regulated purchases, reputation, customer support, and long-term access all benefit from knowing who is involved. A machine-readable payment does not make those questions disappear. It makes the boundary easier to see.

The same is true for trust. A receipt can show that money moved. It cannot show that the seller delivered what was promised, that an answer is reliable, or that the transaction can be repaired when something goes wrong. Payment protocols can settle a charge. They do not create reputation, guarantees, customer support, refunds, or dispute resolution. Those layers still have to be built around the payment.

MPP and x402 solve one part of a larger system. They give machines a clearer way to discuss price and payment, while identity, permission, quality, and recourse remain separate problems. That is why the future does not appear to depend on one protocol defeating the other. The more durable change is the digital price tag itself.

The internet has always been good at moving information. It may finally be learning how to attach a price to a single piece of work, let a machine decide whether it is worth paying, and keep the whole conversation moving.