Kumar McMillan
Oct 28, 2015 · 1 min read

I think what you’re describing is already possible all across the web. Instead of a 402, the site can respond with a 301, render a payment page, and process the payment :) Honestly, what is the difference? The difference is that the site (the vendor) must implement their own payment flow. Well, there are lots of great services that vendors can plug into their sites for this this: Stripe, Braintree, Shopify, PayPal, and so on.

Let me back up. The tricky part you didn’t mention with the 402 idea is that a vendor must opt-in somehow so that funds can flow securely into their bank account. This is typically done first when a vendor signs up and enters bank account details on Stripe, Braintree, or wherever, and secondly when they process each transaction (usually there is a token exchange and a signature verification). Let’s say a browser implements the server components necessary for this. Okay, now each vendor has to sign up their bank account details with the browser. Would this be any better than relying on third party drop-in solutions such as Stripe or Braintree?

Historically, browsers have been bad at implementing end to end user experiences (such as a payment flow). They have been more successful at providing lower level primitives that enable web developers to create the best experiences for their users. With that said, one helpful primitive would certainly be request autocomplete. Chrome and Safari already support auto-completing credit card numbers, Firefox does not (but it should!).

Kumar McMillan

Written by

I make web things at Mozilla. Also dancing.