MPP and agentic payments: HTTP negotiation across payment methods

Start with scope

MPP makes payment negotiation an HTTP authentication flow

Machine Payments Protocol formalizes a pattern around HTTP 402 Payment Required. A client requests a protected resource, the server responds with a Payment challenge in WWW-Authenticate, the client satisfies one offered method, and the request is retried with a Payment authorization credential. After verification, the response can carry a Payment-Receipt alongside the resource.

That shape is useful for agentic payments because it lets a tool, API, page, or stream describe price and supported methods at the moment of access. The client does not need a bespoke checkout integration for every merchant. The server does not need to place payment instructions inside unstructured text that a model must interpret.

Choose charge, session, and method as explicit policy inputs

MPP distinguishes a one-time charge from a session that can support streaming or usage-based payment. A server may offer stablecoin, card, wallet, Lightning, or a custom method through the same protocol surface. That flexibility is an execution feature; the agent should not silently choose the cheapest-looking or fastest method if it changes recourse, custody, finality, or the principal's approved rail.

The challenge parser should treat price, currency or asset, destination, expiry, method, and resource binding as typed inputs. Compare them with the mandate before requesting a credential. If the server changes those fields on retry, evaluate the new challenge instead of assuming it represents the same purchase.

• Authorize a maximum unit price and an aggregate task or session budget.
• Keep acceptable methods and networks inside deterministic policy.
• Bind the credential to the challenged origin, resource, amount, and expiry.
• Require step-up approval when method choice materially changes reversibility or risk.

Keep principal authority outside the payment handshake

A valid MPP challenge proves what a server requests, not that the server is eligible or the purchase advances the principal's goal. A valid payment credential proves that one payment method accepted a specific flow, not that the agent was entitled to obtain it. The authorization system still has to bind principal, agent, merchant, purpose, resource, amount, method, expiry, and cumulative spend.

Similarly, Web Bot Auth, API authentication, or MCP identity can help identify the calling software without granting it financial authority. Preserve separate evidence for client identity, mandate evaluation, payment verification, settlement, and fulfillment rather than collapsing them into one paid response.

MPP can standardize the payment conversation; the mandate must still determine whether the conversation is allowed to produce money movement.

Operate retries, sessions, receipts, and settlement uncertainty

HTTP clients retry, proxies duplicate requests, and an agent may re-plan after a timeout. A production implementation needs idempotency at the logical purchase, payment, and resource-redemption layers. When a response is lost after settlement, inspect the receipt or method-specific state before authorizing another charge.

For sessions, record authorized budget, metering increments, replenishment rules, close conditions, and the final settlement result. A Payment-Receipt is useful evidence, but the verifier must define exactly what it means for each method. Provider acceptance, onchain inclusion, card capture, and merchant fulfillment are different states and should remain different in the ledger.