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, so it can still be charged if the data request fails.

For a one-off API call, start with x402. Choose MPP when your agent's wallet and tooling live on Tempo and you accept paying before the run.

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.

Both rails buy the cheapest source only

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

AnyAPI quotes both rails at the cheapest eligible price. The paid amount caps the run to sources covered by that payment. If the cheapest path is unavailable and the next source costs more, the request fails instead of silently spending more. On x402 nothing settles; on MPP the payment has already moved.

Neither rail buys automatic fallback: x402 and MPP both authorize the cheapest eligible attempt, and the advertised price is that source's price.

The live transcript example shows the same $0.002 amount on both rails, and the amounts stay equal on endpoints with differently priced sources, because both rails read the same floor. Wallet-billed API key calls are the path that funds a dearer source automatically.

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 agent already settles on Tempo and its policy accepts paying before the run. The challenge amount is the cheapest source's exact price for that request, the same figure x402 asks for.

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 your existing payment network 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 no-fallback 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.