Machine Payments Protocol and HTTP Authentication

Machine Payments Protocol, or MPP, borrows HTTP authentication's challenge and credential shape for payment. A server returns 402 Payment Required with a Payment challenge in WWW-Authenticate; after satisfying those terms, the client retries with an Authorization: Payment credential and can receive Payment-Receipt on success.

The settlement rail stays open. Stablecoin, card, Lightning, or another registered method can sit behind the same core exchange, which means the route must validate the chosen method without pretending the HTTP fields define its financial system.

This work remains in draft form. The Payment HTTP authentication scheme is an active individual Internet-Draft, not an RFC. The separate Payment Discovery draft was published July 11, 2026 with intended status Informational. A production implementation would need pinned versions and a migration owner.

The runtime challenge controls the purchase

An MPP exchange starts with the resource request. If payment is the primary barrier and the server can provide usable terms, it returns a 402 response like this:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="ch_123", realm="api.example", method="stripe", intent="charge", request="<base64url-json>"

The required challenge parameters identify the challenge, protection space, payment method, intent, and method-specific request data. Optional parameters can bind the challenge to a request-body digest, set an expiry, or provide a display description. A client shouldn't treat that description as a value to verify. Amount and recipient checks belong to the structured method data.

After fulfilling the method-specific requirement, the client retries:

Authorization: Payment <credential>

The server verifies the credential and settlement rules before releasing the resource. A successful response may include Payment-Receipt, which lets the client retain a structured reference to the accepted payment. Failed payment verification returns a fresh 402 challenge. Ordinary login failures still use 401, and a valid payment followed by a policy denial uses 403.

That distinction is valuable. A payment credential should never become a substitute for product authorization. If a customer must be entitled to a dataset in addition to paying, authenticate first, authorize the account, then issue terms appropriate to that account.

OpenAPI discovery describes payable operations in advance

Runtime challenge handling can work without discovery. The July 2026 draft adds an optional way for clients to find a paid API before calling it. A participating service publishes an OpenAPI 3.x document at /openapi.json over HTTPS with application/json.

The optional top-level x-service-info object can list service categories and documentation links. Each payable operation carries x-payment-info, using either a single offer or an offers array. New documents should use the array so an operation can advertise alternatives.

{
  "x-payment-info": {
    "offers": [
      {
        "intent": "charge",
        "method": "stripe",
        "amount": "25",
        "currency": "usd"
      }
    ]
  }
}

An offer requires intent, method, and amount. amount is a string of digits in the currency's smallest denomination, or null when runtime inputs determine the price. currency and a human-readable description are optional fields in the draft.

Discovery is advisory. If the document advertises 25 cents and the live challenge asks for 30, the client must assess the live challenge. It must not reuse the cached OpenAPI price as payment authority. The mismatch should also produce telemetry because stale discovery can mislead service selection even when the wire protocol remains correct.

Publishing the document reveals routes, request schemas, and prices to unauthenticated readers. That may be intentional for a public API. It is a poor fit for an internal service whose paths or rates are account-specific. Review disclosure, cross-origin access, cache duration, and retirement behavior before placing it at a fixed origin path.

Charge and session intents solve different billing problems

A charge represents a one-time payment. Use it when the server can state the amount for a bounded operation, such as one conversion, one export, or one fixed data query. A retried request needs idempotency so the same business operation doesn't create a second charge or a second result.

A session supports metered use over a continuing interaction. The client authorizes a spending relationship, and the accepted amount can increase as the server delivers units such as tokens or bytes. This can reduce settlement overhead for streaming or high-frequency workloads.

Sessions add state. The service needs a durable store, usage measurement, a maximum authorization, close behavior, reconciliation, and recovery when either party disconnects. A route whose cost is known before execution usually doesn't need that machinery.

Choose from the product's billing unit. Starting with the preferred SDK method and bending the product around it is backwards.

SDK middleware stops at the application boundary

The MPP project publishes SDKs, including mppx for TypeScript and pympp for Python, with adapters for common web frameworks. Middleware can parse challenges and credentials, invoke a configured payment method, and decorate a successful response with its receipt.

The route still owns the work after payment. It must bind the accepted challenge to the exact request, prevent concurrent duplicate execution, decide whether settlement precedes fulfillment, and retain enough state to repair a paid request that failed during delivery.

Use a durable operation key. Store challenge ID, credential outcome, receipt reference, fulfillment state, and the response locator in one record. Don't log complete payment credentials. Lifecycle hooks should record amounts and method identifiers only when policy allows, with secrets and personal data excluded.

Server-side controls also include rate limits before expensive verification, bounded credential sizes, strict method allowlists, body-digest validation for mutating requests, and a refusal to follow payment or metadata URLs supplied by an untrusted client. The draft warns that payment credentials are bearer-like secrets and require TLS.

A 404 is the accurate discovery response

TKOResearch does not operate a paid public API. TARE is the flagship LabSecOps platform, but this publishing site doesn't expose TARE operations as per-call products. Its contact endpoint processes inquiries and has no payment challenge, billing unit, or fulfillment receipt.

Payment-annotated OpenAPI for that form would advertise a service that cannot complete the documented exchange. /openapi.json should return 404, while ordinary site routes continue returning their normal responses. If a bounded TARE operation later gains a posted price and a supportable delivery contract, MPP can be assessed against that product.

Prove the billing unit before choosing middleware

Start with the thing being sold. A charge needs a delivered unit, completion state, fixed or dynamic price in the currency's smallest denomination, client-visible limit, tax treatment, and remedy for incomplete fulfillment. A session needs all of that plus usage measurement, an authorization ceiling, close behavior, and recovery after disconnect.

Next comes the API contract: request schema, account authorization, version strategy, error model, idempotency behavior, and a body digest for mutations where the profile requires one. Only then should the team choose payment methods, currencies, settlement providers, credential handling, reconciliation, and charge versus session intent.

The durable record must join challenge ID, receipt, API request, customer account, settlement state, and fulfillment without retaining the payment credential. Support needs to find that record. Refund and credit authority must be named before a paid failure occurs.

Finally, exercise the hard cases through TLS: replay, concurrent retries, expired challenges, discovery mismatches, provider timeouts, dynamic price changes, rate limits, budget enforcement, secret rotation, OpenAPI disclosure, and dependency updates. Measure credential failures, settlement timing, duplicate execution, and session usage.

Middleware is the last step. Otherwise the server can collect money and still have no defensible answer for what the buyer received.