Proposal: Microformats for Easy Mobile Checkout

Right now, purchasing on a mobile device is, frankly, a nightmare. You’ve got your phone in one hand, trying to read the figures off a credit card in the other, and barely able to peck out the data.

Now, there tend to be a lot of over-engineered “answers” to this problem– usually in the form of elaborate new third party systems or complete shopping cart re-engineering. This frequently involves liability-intennsive situations like “we’ll store the customer’s credit card number”, or solutions that only solve the problem one vendor at a time.

I’d like to introduce a better proposal. Using a technology we already have– microformats– mobile checkout could be made far simpler. All we need to do is define and popularize a microformat for “purchase form fields”. The browser can be configured to detect appropriately marked up fields, and present a simple “Do you wish to populate this form with your Billing Address” or “Would you like to fill this form in with a credit card stored inside the browser?”

<input type="text" name="b_address" rel="checkout_form:billing_address">

This is a bit more elaborate than the conventional “form autofill” technologies for two reasons:

1. It’s not based on field names, but rather the “rel” attribute. This way, the browser doesn’t have to realize “BAddress”, “Billing_address”, “Address1” and “b_address” all refer to the filling address.

2. It’s not domain-specific. If I store my address on the Newegg checkout form, it doesn’t magically appear on Rakuten. Here it will.

The original form can still be displayed, so customers can feel confident in what they’re submitting, but they no longer have to be trying to enter long address and credit card strings in real time.

Because this takes place at the browser level, there’s no liability on the merchant’s part for storing account details, and it can be adopted easily by any site that wants to mark up their form fields accordingly.

A second phase could extend this to support “out of band” payment methods– services like PayPal or bank “direct pay” applications, or even cryptocurrency– by using a hidden field to support just a transaction ID in lieu of the usual credit card details.

<input type="hidden" name="PayPalTxn" serviceuri="paypal://" amount="49.94" currency="USD" memo="Order #123456">
<input type="hidden" name="BitcoinTxn" serviceuri="btc://1sEWjkgfry......" amount="0.0546" currency="BTC" memo="Order #123456">

These fields would hint the browser to display a “Pay with PayPal” or “Pay with Bitcoin” button, outside the HTML display.

The browser can associate different “serviceuri” paramaters with payment apps, launch the appropriate app, recieve a transaction confirmation from the app, fill the hidden field, and submit it. The website can validate the transaction number with the appropriate payment provider, and then proceed to process the order.

All this can be done by the browser vendors themselves, without having to explicitly ask for support from a payment service provider, and with the only retooling a site owner having to do be add a few lines of additional markup. The conveninence is real and demonstratable, and the technology is trivial. Who will be the first to jump on this bandwagon?

comments powered by Disqus