payment challenge

In x402 the challenge travels in headers. The current HTTP transport states that all protocol information is communicated through headers, naming PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE, and leaves the response body to the server. The PAYMENT-REQUIRED value is a base64-encoded object whose accepts array holds one entry per payment option the endpoint will take.

MPP puts its challenge in the WWW-Authenticate field under a Payment scheme, with parameters naming the challenge id, the realm it protects, the payment method, the payment intent and an encoded request. Its specification requires the server to bind that id to the challenge's own terms, so that a client cannot present an identifier back against terms it has altered.

L402 uses the same WWW-Authenticate field under a scheme name of its own, pairing a macaroon — a bearer token — with a Lightning invoice. Its credential is that macaroon and the invoice's preimage presented together. Cloudflare's pay per crawl answers an unpaid crawler with HTTP/2 402 Payment Required and a crawler-price header. The crawler answers with a price header of its own, which has to sit inside the components its request signature covers.

What the forms share is the status code and little else. RFC 9110 reserves HTTP 402 without defining a format for it, so each protocol supplies its own. A client fluent in one can therefore receive a challenge from another and find nothing in it to act on, though both responses carry the same status. Anything reading endpoints from outside meets that directly: the status says a payment is expected, and the shape of the answer says which vocabulary it is expected in.