We built the Condé Nast paywalls (New Yorker/Wired/Vanity Fair) using the 402 status code. A 402 indicates to the browser that no acceptable payment method was

We built the Condé Nast paywalls (New Yorker/Wired/Vanity Fair) using the 402 status code. A 402 indicates to the browser that no acceptable payment method was negotiated and the content returned is not the full url requested. We imagine clients sending an "Accept-Payment" header just as they send an "Accept" or "Accept-Language" header today. When the server is unable to satisfy their request, it returns a 402 indicating that no acceptable payment method was found. It's true that browsers may not be currently sending these Accept-Payment headers; we auto-create the headers at the edge based on other headers (cookies). Conceptually this simplifies our stack and gives us a way that we might be able to have more of a "conversation" between web users and the site about how they want to monetize our content. For instance a user may have ad-block enabled so why not tell the server that ("Accept-Payment: ads;q=0") and we'll serve the page based on this information. I envision a future where the web browser may have multiple payment methods built into it (micro-payments, subscriptions, ads, etc.) and a "conversation" happens between the client and server to figure out what the "best" way forward is for both parties. We don't need new headers or methods for this, we simply need to re-use existing status codes and headers.