payment authorization

On the stablecoin side the authorization is a typed message. Under x402's exact scheme on EVM networks — the chains that run Ethereum's virtual machine — it is an EIP-3009 transferWithAuthorization naming the payer, the recipient, the value, a validity window and a nonce. The payer signs it and sends the signature; nothing has moved at that point. A facilitator submits it afterwards, and that submission is the settlement.

MPP carries the same separation under a different name. The Internet-Draft behind it defines a Payment Credential as an Authorization header with the scheme Payment, containing payment authorization data, sent base64url-encoded on the retried request. The draft requires TLS for it, on the stated grounds that the credential carries authorization data that could cause financial loss if intercepted.

L402 reverses the order. Its credential is a macaroon paired with the preimage of a paid Lightning invoice — the bearer token, and the proof the paid invoice yields — so what authorises the request is a token plus evidence that a payment already happened. A signed authorization is a promise that has not yet been kept; a preimage is a receipt for one that has.

For anything reading endpoints from outside, the separation is what makes terms observable at all. The payment challenge states what an authorization would have to say before anybody signs one, so what an endpoint charges can be read without a payment being made.