Two ways an AI agent pays for a data API inline: x402 vs MPP

AI agents can find tools, choose APIs, and make requests on their own. Paying a new service is where that autonomy usually ends.

Traditional API billing requires a human to create and fund an account before issuing an API key. An agent can spend from accounts you've prepared, but it can't independently buy one result from a service it just discovered.

x402 and the Machine Payments Protocol (MPP) are agentic payment methods that change this. They let an API quote a price in HTTP, then let the agent pay and retry without a pre-existing billing relationship.

The difference is when money moves. With AnyAPI's x402 flow, payment settles after a successful data request. With its current MPP Tempo flow, the agent pays first, which can fund a more expensive fallback but can still leave the agent charged if the data request fails.

For a one-off API call, start with x402. Choose MPP when automatic fallback matters more than post-success settlement.

Read both payment offers from one 402 response

I sent this unauthenticated request to the live AnyAPI gateway on July 31, 2026. It asks for a YouTube transcript, but it doesn't include an API key or either payment credential.

curl -i -X POST \
  https://api.getanyapi.com/v1/run/youtube.video_transcript \
  -H "Content-Type: application/json" \
  -d '{"url":"https://www.youtube.com/watch?v=jNQXAC9IVRw"}'

The gateway returned 402 Payment Required. No paid data request ran.

HTTP/2 402
cache-control: no-store
payment-required: <base64 x402 v2 challenge>
www-authenticate: Payment realm="api.getanyapi.com",
  method="tempo",
  intent="charge",
  request="<base64 MPP request>",
  expires="2026-07-31T23:14:34.652Z"

After decoding the two base64 values, these are the terms an agent needs for its decision:

{
  "x402": {
    "version": 2,
    "challengeHeader": "PAYMENT-REQUIRED",
    "credentialHeader": "PAYMENT-SIGNATURE",
    "scheme": "exact",
    "network": "eip155:8453",
    "amountAtomic": "2000",
    "asset": "USDC on Base"
  },
  "mpp": {
    "challengeHeader": "WWW-Authenticate",
    "credentialHeader": "Authorization: Payment",
    "method": "tempo",
    "intent": "charge",
    "chainId": 4217,
    "amountAtomic": "2000",
    "asset": "USD stablecoin on Tempo"
  }
}

Both offers quote 2,000 atomic units of a six-decimal USD stablecoin, which is $0.002. The amount is the same in this example. The chain, asset contract, headers, and settlement path differ.

The x402 v2 terms sit in PAYMENT-REQUIRED. This follows the current x402 request flow, where the client retries with PAYMENT-SIGNATURE and receives PAYMENT-RESPONSE.

MPP uses the HTTP authentication framework instead. Its protocol overview puts the challenge in WWW-Authenticate: Payment, the credential in Authorization: Payment, and the receipt in Payment-Receipt.

Here is a runnable Node.js script that reads both offers without paying either one:

const endpoint =
  "https://api.getanyapi.com/v1/run/youtube.video_transcript";

const response = await fetch(endpoint, {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({
    url: "https://www.youtube.com/watch?v=jNQXAC9IVRw",
  }),
});

if (response.status !== 402) {
  throw new Error("Expected 402, got " + response.status);
}

const encodedX402 = response.headers.get("payment-required");
const mppChallenge = response.headers.get("www-authenticate");

const x402 = JSON.parse(
  Buffer.from(encodedX402, "base64").toString("utf8"),
);

console.log({
  x402Version: x402.x402Version,
  x402Amount: x402.accepts[0].amount,
  x402Network: x402.accepts[0].network,
  mppOffered: mppChallenge?.startsWith("Payment "),
});

This is a useful preflight for an agent policy. It can reject an unknown network, an amount above its per-call cap, an expired challenge, or a resource URL that doesn't match the request before a wallet signs anything.

Compare what the agent sends back

The headers differ, but the outer control flow is the same: request, challenge, pay, retry, receipt.

AnyAPI also places an x402 v1 challenge in the response body for older clients. Those clients retry with X-PAYMENT and receive X-PAYMENT-RESPONSE. New code should read the v2 header unless it must support a v1-only client.

The two success paths look similar from the agent's call site. The order behind the API is where the decision changes.

MPP and x402 aren't sealed ecosystems. The MPP project's June 2026 interoperability update shows one mppx client selecting between MPP challenges and compatible x402 exact challenges. A client library can support both even though the wire credentials remain distinct.

Decide when the API is allowed to charge

Settlement timing decides who absorbs a failure after payment has been authorized.

On AnyAPI's x402 path, the gateway verifies the signed payment, runs the data request, and settles only after that request succeeds. If the data request fails, the gateway doesn't settle the payment.

On the current MPP path, the agent completes a Tempo charge before sending Authorization: Payment. The gateway verifies that settled charge and then runs the data request. If the data request fails after settlement, the gateway records the charged-but-undelivered result, but it can't undo the on-chain push inside that request.

Settlement timing decides who carries failed-run risk. With x402, AnyAPI carries the cost of a rare settlement failure after successful work. With its current MPP charge, the agent carries the risk of a data failure after payment.

This is an implementation comparison, not a claim that MPP can only work this way. MPP defines several intents and payment methods. Its official docs cover sessions, subscriptions, cards, and other settlement designs. AnyAPI currently exposes the Tempo charge intent.

Price failover before choosing a rail

A unified data API can have several eligible providers behind one endpoint. They don't always cost the same.

AnyAPI quotes x402 at the cheapest eligible price. The signed amount caps the run to providers covered by that payment. If the cheapest path is unavailable and the next provider costs more, the request fails without settlement instead of silently spending more.

The MPP charge takes the opposite approach in the current gateway. It quotes the highest eligible price before the run. That settled amount can fund a fallback to a more expensive provider.

Failover changes the amount an agent must authorize: x402 buys the cheapest eligible attempt, while AnyAPI's MPP charge buys the full failover ceiling.

The live transcript example shows the same $0.002 amount on both rails because its eligible price is the same across the available path. On an endpoint with differently priced providers, the two challenge amounts can diverge.

Choose the rail for this agent job

For a single data call, I would start with x402. It gives the agent a precise quote, keeps settlement after successful work, and limits the authorization to the cheapest eligible path.

I would choose MPP on AnyAPI when the request matters enough to fund automatic failover and the agent's policy accepts pre-settlement. The agent should treat the challenge amount as a ceiling it has deliberately approved, not as a rough estimate.

There are also cases where the service makes the choice for you. If only one rail is advertised, use a client that supports that rail or fall back to an API key and wallet billing. If both are present, evaluate them in this order:

1. Confirm the resource, currency, network, recipient, expiry, and amount.
2. Reject any offer above the agent's per-call or task budget.
3. Decide whether post-success settlement or funded failover matters more.
4. Send only the credential for the selected rail.
5. Store the receipt beside the API result for reconciliation.

For the x402 mechanism itself, including the signature and facilitator roles, read the sibling guide on how an AI agent pays for one API call.

Keep the comparison inside its limits

The live request verifies the unpaid challenge, exact headers, networks, assets, and $0.002 quote. I didn't send a payment credential or execute a paid transcript request for this article.

The failed-run and failover behavior comes from AnyAPI's current gateway implementation. Another x402 or MPP service can choose different pricing, payment methods, settlement timing, and refund handling within its own design.

Protocol support is also moving quickly. The x402 Foundation launched under Linux Foundation governance in July 2026, while MPP publishes its core HTTP authentication work as open specifications. Recheck the service's live challenge and current client docs before fixing a rail choice in long-lived code.

Once your policy is clear, inspect the endpoint's input schema and USD price before wiring payment into the agent.