x402 vs AP2 vs MPP: Compare Roles, Flows and Requirements

Compare the problem each protocol solves

An agent buying a resource has several problems to solve. It needs permission to spend, a seller offer it can understand, an accepted way to pay, and evidence that the requested resource was delivered. A protocol may handle one of these well without defining the others. Begin with a diagram of your transaction and assign an owner to each responsibility.

x402 makes a paid resource discoverable through an HTTP payment challenge. Its V2 transport carries payment requirements, a client payment payload and a settlement response. That fits services where a client can inspect an offer and make a programmatic payment for access. The HTTP 402 response is the start of negotiation, not an instruction that every receiving agent should immediately spend. [3]

AP2 v0.2 describes a security layer within commerce, with checkout and payment mandates and verification responsibilities. The commerce APIs themselves sit outside its scope. It does not replace a seller's catalog, stock rules, fulfillment system or payment rail. Its purpose is to establish what the agent was authorized to purchase and pay for. [1]

MPP means Machine Payments Protocol in this comparison. It provides machine-payment negotiation with method-specific execution. The AP2 specification also abbreviates its Merchant Payment Processor role as MPP. That is a role inside AP2, not a statement that AP2 requires the separate Machine Payments Protocol. Spell out the name in integration documents when both appear. [2] [1]

Map authority, payment and settlement separately

Authority answers whether the agent may commit this purchase. Payment negotiation answers what the seller accepts and how the client proves an accepted payment action. Settlement answers how the corresponding funds reach the payee. Delivery answers whether the seller supplied what was bought. These states should remain distinguishable in logs and user interfaces.

For a hypothetical $0.25 financial-data report, a wallet balance of $10 only shows available funds. It does not establish permission to buy the report, permission to disclose a client's information or acceptance of the report's license. Those conditions belong to the task and its approved purchase boundary. The amounts are synthetic examples, not provider prices.

AP2's checkout mandate is tied to the merchant's signed checkout. Its payment mandate links payment authority to that checkout. Direct mode involves approval of the specific purchase; autonomous mode uses approved constraints to support a later concrete checkout. The integration must implement the relevant deterministic verification. The agent's own explanation that a purchase fits the user's wishes is not a substitute for the verifier. [5] [6]

For x402, inspect the selected scheme and network together. The current scheme documentation distinguishes fixed-price authorization, a maximum with actual usage, accumulated payment authorizations and escrow-style capture. Those semantics change the point at which money is committed or released. Check the actual SDK and facilitator support instead of inferring implementation from the protocol's list of network bindings. [4]

For MPP, inspect the payment method and intent offered by the endpoint. A card credential and a stablecoin authorization are not the same object merely because both participate in a challenge-and-credential exchange. The server and client need a supported combination, and the application needs a clear account of the final receipt and any outstanding obligation. [7]

Walk through the same fixed-price API purchase

Use the same synthetic task for every comparison: obtain one licensed financial-data report for at most $0.25, from an approved seller, with no recurring commitment. The report must contain the requested date and format. If the seller changes the price or returns a different license, the task is no longer the same purchase.

On an x402 path, the agent requests the resource and receives payment requirements. The application checks the offer against the task, selects an accepted requirement and prepares the payment payload with an authorized signer. In V2 HTTP transport, the retry carries PAYMENT-SIGNATURE and the response can carry PAYMENT-RESPONSE. Preserve that response alongside the delivered report. [3]

Do not assume one settlement order across all x402 schemes. In the documented default authorization flow, verification happens before resource handling and settlement afterward; other flows differ. Your failure handling needs to identify whether an error happened before the handler, during delivery or during settlement. A diagram that always puts an onchain transfer before every resource execution would hide these distinctions. [4]

On an MPP path, the endpoint offers a payment challenge and the client uses an accepted method to provide a credential. The application still checks the report, price, counterparty and permitted task. Compare the method's execution and receipt behavior, not just the fact that a server returned a payment challenge. A client with only one supported method may be unable to complete an otherwise valid offer. [7]

AP2 addresses a different question in this example. If the purchase is represented through a compatible commerce flow, mandates can establish authority for the checkout and its payment. AP2 does not by itself turn the report URL into a paid endpoint or make an x402 or MPP wallet available. You still need the commerce representation and the selected payment integration.

After any of these paths, inspect the report before declaring the task complete. Keep its purchase reference, delivery status and entitlement together. If the response disappears after a payment action, reconcile the original purchase. A fresh payment request is not a safe way to discover whether the first one succeeded. This recommendation follows from the uncertainty of distributed operations; it is not a promise that all three protocols expose an identical status endpoint.

A retail order needs checkout authority and fulfillment

Consider a second synthetic task: buy one replacement laptop charger for a total of at most $45, including delivery, from either of two approved merchants. The exact item and delivery address matter. A protocol that can move $45 does not alone determine whether a charger is compatible or whether the delivery option meets the user's request.

AP2's checkout mandate documentation defines merchant and line-item constraints for open authorizations. This is useful evidence when an agent later assembles the concrete purchase. The merchant needs to verify the actual checkout, and the payment path needs authority bound to that purchase. Do not reduce the user's constraint to an amount alone. [5]

x402 or MPP may be part of a supported payment route, but a payment challenge is not a complete retail order lifecycle. The surrounding commerce system must handle item choice, tax, delivery, stock, cancellation and the seller's order reference. Identify that system explicitly. Otherwise, the architecture can describe a payment precisely while leaving the purchase itself undefined.

The comparison changes when the buyer must approve each order. A customer-present checkout and an unattended purchasing task have different consent timing. Do not label both autonomous merely because an agent selected the product. Write down when the person approves, what they see, and whether the agent may continue after the price or item changes.

A metered session needs an exposure limit

A third synthetic task lets a research agent query a service repeatedly during one investigation. The owner approves a $3 ceiling for the session, not an unlimited series of small requests. The design needs to track accrued usage and outstanding commitments, including concurrent calls that have not yet produced a final result.

MPP session documentation describes a usage-based lifecycle within an authorized session. x402 offers schemes intended for usage-based requests or repeated authorizations. These are different mechanisms with specific implementations; neither label guarantees that every client and endpoint can share a session or reuse the same payment credential. [8] [4]

Compare when exposure increases, when it is settled and when access ends. Ask what happens if the agent disconnects, the process restarts or a final receipt is delayed. The operational budget should count commitments already made, rather than freeing the entire ceiling because the model no longer remembers the earlier calls.

AP2 can supply relevant authority in an integrated purchase flow, but the current specification leaves delegation from one shopping agent to another outside its scope. Do not use an AP2 label as evidence that an arbitrary chain of subcontracting agents inherits the user's budget. Such a design needs an explicit authorization model and verified enforcement at each handoff. [1]

Combine layers only through a documented binding

A useful combination might pair a commerce authorization layer with a machine-payment mechanism. That is an architectural category, not proof that two libraries can be connected without additional work. The integration must bind the same seller, amount, currency, resource and purchase identifier across the layers. If those fields describe different transactions, each layer can appear valid while the overall purchase is wrong.

Start with the actual implementation guide and supported version. For AP2, exact mandate type versions matter. For x402, specify the transport version, scheme, network and asset. For MPP, specify the accepted method, intent and relevant SDK behavior. Avoid writing simply supports agent payments in a requirements document when the procurement decision depends on these details.

Do not translate credentials by changing their names. An AP2 mandate is not an x402 payment payload, and an MPP credential is not automatically a card token accepted by any merchant. A shared payment asset can make settlement compatible while the surrounding authorization and message formats remain different. The adapter, if one exists, must perform and preserve the required checks.

Also compare data disclosure. A seller may need evidence for one checkout without receiving the owner's entire research task or unrelated account history. Keep authorization evidence, payment credentials and application data in their appropriate channels. Before logging a payload, identify whether it contains a reusable credential or personal information; encoding a value for transport does not make it safe to publish.

Choose a path that answers the missing responsibility

Use the decision tree to identify the first documentation branch. If you sell a paid API, begin with the machine-payment offer and compatible client. If you need evidence that a shopper can make a particular purchase, begin with AP2 and the commerce flow. If you need metered use, inspect the selected session or scheme lifecycle rather than assuming fixed-price retry behavior.

A selection is incomplete until the system also names the signer or credential provider, the policy enforcement point, the seller's delivery obligation and the recovery process. Unknown is a useful result when a provider has not documented the required combination. It tells the engineering team what to verify without inventing a match.

This comparison uses AP2 v0.2 and current x402 V2 and MPP documentation checked on 8 October 2026. It is not a benchmark, security certification or claim of successful interoperability testing. Use the individual protocol guides for details and the stack selector to preserve your requirements and unresolved eligibility questions.