BlackRock Says Agents Need Sub-Cent, Always-On Money. Stripe And Tempo Already Shipped The Wire Format: Metering Market Data For Agents With MPP And HTTP 402, With Spend Caps, In Code

BlackRock's report is the demand side of a story whose supply side arrived quietly in March. 'The Machine-Native Economy' argues that as agents book travel, buy data and rent compute on their own, they need payment systems that never close and can settle transactions worth fractions of a cent; that card networks and clearing houses, with human onboarding and fees that make tiny payments uneconomic, cannot do it; and that stablecoins as transactional money and crypto rails for high-frequency, sub-cent, machine-to-machine settlement are the natural fit. Whatever one thinks of the asset-allocation conclusion, the engineering premise is right: agents are already the majority of API traffic at many providers, and almost none of that traffic can pay for itself.

The Machine Payments Protocol is the protocol built to fix that. Co-authored by Stripe and Tempo and released on 18 March, MPP standardises HTTP 402 Payment Required with a challenge-credential-receipt flow. An agent requests a paid resource; the server returns 402 with payment requirements; the agent pays - cards through Stripe's shared payment tokens, stablecoins through x402-style transfers on Tempo and other chains, buy-now-pay-later through partners - and retries with a payment credential; the server verifies and returns the resource with a receipt. Sessions, added in April, let an agent authorise a spending cap once and stream micropayments against it. Stripe's documentation describes minimums of $0.50 for card tokens and $0.01 for USDC, an open-source server library, and a validator that exercises a server's discovery, challenge format, error handling and full payment flow.

Serving A Paid Endpoint

The server side is small. Using Stripe's open-source library, a handler declares the price, and the library produces the 402 challenge, verifies credentials and attaches receipts. Below is a per-request option-chain endpoint priced in cents, with the bank-grade additions: an allow-list of agent identities permitted to pay, idempotency on the receipt, and metering records for reconciliation.

import crypto from "node:crypto";
import StripeClient from "stripe";
import { Mppx, stripe } from "mppx/server";

// Challenge-binding secret, as the Stripe docs recommend: derived, not stored in plain text.
const mppSecretKey = crypto.createHmac("sha256", process.env.STRIPE_SECRET_KEY!).update("mpp-challenge-signing").digest("base64");
const stripeClient = new StripeClient(process.env.STRIPE_SECRET_KEY!);
const payments = stripe.create({
  client: stripeClient,
  networkId: process.env.STRIPE_PROFILE_ID!,
  livemode: !process.env.STRIPE_SECRET_KEY!.includes("_test_"),
  depositAddresses: { tempo: process.env.TEMPO_DEPOSIT_ADDRESS! },   // enables USDC alongside card tokens
});
const mppx = Mppx.create({ methods: payments.defaultMethods(), secretKey: mppSecretKey });

const PRICE_USD = "0.02";   // per chain request; cheaper than any seat, more than free

export async function optionChainHandler(request: Request): Promise<Response> {
  const url = new URL(request.url);
  const symbol = url.searchParams.get("symbol") ?? "";
  if (!/^[A-Z.]{1,8}$/.test(symbol)) return Response.json({ error: "bad symbol" }, { status: 400 });

  const result = await mppx.charge({ amount: PRICE_USD })(request);
  if (result.status === 402) return result.challenge;             // tells the agent how much and how to pay

  // Paid: serve the data, record the metering event, attach the receipt.
  const chain = await marketData.optionChain(symbol);
  await metering.record({ symbol, amountUsd: PRICE_USD, receiptId: result.receipt?.id, at: Date.now() });
  return result.withReceipt(Response.json({ symbol, asOf: chain.asOf, expiries: chain.expiries }));
}

• Run Stripe's validator against the endpoint in sandbox and live modes before publishing it; it exercises discovery, challenge format, error handling and a round-trip payment.
• Price per unit of work, not per call where calls vary wildly in cost: a full chain and a single quote should not cost the same.
• Keep licensing in mind: redistributing exchange data by the request still needs the exchange's agreement. MPP changes the billing mechanism, not the licence.

Letting Your Agents Pay - With A Cap They Cannot Exceed

On the consuming side, the danger is obvious: an agent that can pay can overspend, and a loop that retries a paid call ten thousand times is a five-figure invoice. BlackRock's always-on, sub-cent world is also an always-on, sub-cent leak unless spend is governed outside the agent. The client below wraps an agent's HTTP calls so that every 402 is settled through a payment session with a hard cap, a per-vendor allow-list and a per-run budget - and the agent never holds the payment credential itself.

interface SpendPolicy {
  runBudgetUsd: number;                  // e.g. 5.00 for one research run
  perVendorCapUsd: Record<string, number>;
  allowedVendors: Set<string>;           // hosts the agent may pay
  maxSingleChargeUsd: number;            // refuse surprising prices
}

export function payingFetch(policy: SpendPolicy, wallet: PaymentWallet, ledger: SpendLedger) {
  return async function fetchPaid(input: string, init?: RequestInit): Promise<Response> {
    const host = new URL(input).host;
    let res = await fetch(input, init);
    if (res.status !== 402) return res;

    if (!policy.allowedVendors.has(host)) throw new Error("402 from non-allow-listed vendor " + host);
    const challenge = wallet.parseChallenge(res);              // amount, currency, methods, binding
    const amount = Number(challenge.amount);
    if (amount > policy.maxSingleChargeUsd) throw new Error("single charge above cap: " + amount);
    if (ledger.runTotal() + amount > policy.runBudgetUsd) throw new Error("run budget exhausted");
    if (ledger.vendorTotal(host) + amount > (policy.perVendorCapUsd[host] ?? 0)) throw new Error("vendor cap exhausted");

    // The wallet - not the agent - holds the credential and signs the payment.
    const credential = await wallet.pay(challenge);
    res = await fetch(input, { ...init, headers: { ...(init?.headers ?? {}), Authorization: credential } });
    if (res.ok) ledger.record(host, amount, res.headers.get("payment-receipt"));
    return res;
  };
}

// The agent receives fetchPaid as its only HTTP tool. It cannot see the wallet, raise the caps,
// or pay a vendor you did not name. When the budget is gone, the tool fails closed.

The policy object is infrastructure, like the budgets and egress rules we described for agent containment. The agent can ask for more budget in its final report; it cannot grant it. And because every receipt is recorded against a vendor and a run, reconciliation is a query rather than a mystery when the month's stablecoin or card statement arrives.

Design Choices For Financial Firms

1. 01Card tokens or stablecoins? Stripe's implementation supports both behind the same 402 flow; a UK firm can start with card tokens and existing treasury processes, and add stablecoin rails when its policy and the UK's qualifying-stablecoin regime allow.
2. 02Sessions for bursty agents. A research agent that will make hundreds of calls should open a session with a cap rather than paying each call; it is cheaper and the cap is enforced by the vendor as well as by you.
3. 03Receipts into the ledger. Treat MPP receipts as invoices: store them with the run ID, the vendor and the data returned, and reconcile against statements automatically.
4. 04Vendor side, publish prices in the challenge and nowhere else. Agents read challenges; they do not read pricing pages.

“BlackRock describes a world where machines pay machines at any hour for any amount. The protocol for that is already an HTTP status code. The missing piece in most firms is the budget the machine cannot change.”

The Bottom Line

BlackRock's 'Machine-Native Economy' report sets out the demand - agents that buy data and compute need always-on, sub-cent payments that cards and clearing houses cannot provide - and the Machine Payments Protocol from Stripe and Tempo supplies the mechanism: HTTP 402 with a challenge-credential-receipt flow across card tokens and stablecoins, plus sessions for capped streaming spend. For financial data vendors it is the first metering model that fits agent traffic; for the firms whose agents consume data it is pay-per-use with a receipt for every call. The engineering that makes it safe is a server that prices per unit of work and validates its flow, and a client that settles every 402 through a wallet the agent cannot see, under run, vendor and single-charge caps the agent cannot change. That is the agentic workflow automation we build for financial firms in London, and the rails for it are already live.

References & Further Reading

• Bitcoin Magazine - BlackRock says AI could be driver of crypto demand (The Machine-Native Economy, 6 October 2026). bitcoinmagazine.com/news/blackrock-says-ai-to-drive-crypto-demand
• Stripe Docs - MPP: accept payments from agents (mppx server example). docs.stripe.com/payments/machine/mpp
• Tempo - Machine Payments Protocol specifications (GitHub). github.com/tempoxyz/mpp-specs
• Forrester - Why Stripe's Machine Payments Protocol signals a turning point for micropayments. forrester.com/blogs/why-stripes-machine-payments-protocol-signals-a-turning-point-for-micropayments
• Openfort - Agentic payments: MPP, x402, ACP and AP2 compared. openfort.io/blog/agentic-payments-landscape
• Zuplo - How Stripe MPP lets AI agents pay for your API. zuplo.com/blog/stripe-mpp-for-agentic-payments
• MDN - 402 Payment Required. developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information