Google Chrome OS: what does it mean for commerce?
If you have followed the technology news as of late, you will have (undoubtedly) read many stories of the launch of Google’s Chrome OS. If you have not, then I would recommend beginning with the Google Chrome OS – FAQ.
If you are interested in the marketing surrounding the launch, then I’d recommend a glance at the videos on the Google Chrome Channel on Youtube. In particular:
There, now we are all on the same page. So, the question at hand is, what does Chrome OS mean for commerce?
Quite simply, very little.
That is, perhaps, a bit glib. Or, actually, excessively glib…
In truth, the announcement of the browser as OS (in essence) should serve as confirmation to those of us in the payments industry that a trend we have discussed at length is now occurring.
If you have spent much time in conversation with me, you have likely heard the statement “blurring the line between the desktop and the cloud”. In essence, the traditional dichotomy of the “desktop” yielding certain workflows and capabilities while the “internet” has a different set of capabilities has blurred dramatically. This has already occurred…it is not a trend, it is fact.
For instance, how many of you leverage SalesForce.com?
You may have a SalesForce plugin for your mail client…or running on your phone…or you may interact with it solely in the browser. But, you are using a “cloud” application to manage your CRM. Or, for my marketing colleagues, when was the last time you ran a traditional mail merge between Excel and Word* and then queued an obscene number of messages to send for an e-mail campaign. Probably not terribly recently. Instead, you leverage a tool like VerticalResponse…a “cloud” application.
To be clear, I am not going as far as a quote attributed to Marc Benioff from SalesForce.com
The future of computing is on the Internet. What we’re witnessing is the end of of software.
Instead, I’m emphasizing that the cloud-based delivery of applications will impact the way in which payment applications are developed and delivered. Nay, it has impacted the way in which they are developed and delivered and will continue to in an increasing fashion.
Consider if you will the traditional Point-of-Sale (PoS)**, it was not all that long ago that the concept of the PoS was relegated to a hardware device that sat on a merchant’s counter. The humble, and still widely used, terminal was the sole paradigm for retail payment acceptance. In fact, as few as 5 years ago, I had discussions (periodically heated) with industry professionals that software could, would, and was displacing these devices with integrated solutions providing a range of tender acceptance and higher-value services (including management capabilities).
In a similar fashion, the paradigm of software can, will, and has changed. The delivery of this PoS software is being done via hosted mechanisms. These Software as a Service (SaaS) offerings have the same functionality (in most, not all, cases) and address important management, maintenance, availability, and cost concerns for the merchant customers leveraging them.
My discussions now are no longer software vs. hardware. But instead about the mechanism of software delivery. For example, I recently met with a company that provides a Virtual-PoS…fully hosted, fully branded…that also provides a wireless acceptance device for PIN Debit transactions and support for Level III card data when necessary. Available whenever, wherever.
Are these delivery mechanisms displacing traditional installation/acceptance methods? Yes. Undoubtedly. Are they displacing them to a degree that the terminal will disappear in 6 months? Not hardly. However, ignoring the delivery equation in addressing the commerce development community would be unwise (at best).
What does ChromeOS mean for payments?
Perhaps an increased focus on eCommerce acceptance and virtualized delivery of PoS applications…perhaps not. More than anything else, it is simply another data-point in the acknowledgement of, and recognition of the import inherent in cloud-based payments offerings.
With all that said, I have downloaded and spent some time with the open source version of the Chrome OS (Chromium OS). I recognize, and acknowledge, that is extraordinarily early in the beta cycle…but it has been less than impressive. My workflow and requirements blend desktop applications, cloud applications, and service based applications that leverage local processing power with online data storage***.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…
* Insert your open office product of choice
** Or, Point-of-Service…if you insist.
*** We can leave the conversation of cloud vs. SaaS vs. S+S for another day
November 24, 2009
4 responses to Google Chrome OS: what does it mean for commerce?
Interesting article. I noticed your PIN Debit reference. I no longer make the Hardware vs. Software argument either. There isn't one. The only way to do PIN Debit is to capture the magnetic stripe. Software can't do that. Only Hardware can.
I agree…in part.
The reason that what you/I would call hardware is required for PIN Debit
transactions is, truly, nothing more than a requirement from processors for
keyed firmware. If that requirement wasn't in place, the process of
transaction encryption could easily be done “on the wire”.
I think the bigger issue…and that to which I refer when I speak of
hardware vs. software….is the question of “intelligence”. It's sort of a
poor choice of words, but the best I can come up with at present.
The traditional terminal device was “it”. The end-all/be-all of acceptance
methodologies. Over time, the software based acceptance methods (be they
online, hosted, or local) were positioned as value-add for the features they
provide. And yet, there is still a benefit (financially) in performing a
swiped transaction.
So you leverage a USB card swipe. Is that hardware? Yes…but it is
hardware in the same fashion that a keyboard is hardware. Hardware, of some
sort, is required to run and interact with software.*
PIN Debit is a great example. I need a certified PED if I'm going to
perform PIN Debit transactions in a safe/compliant fashion. The hardware,
however, is truly just an encryption and input device….designed to
interact with the software that is providing connectivity, routing,
transaction qualification, and business management functions.
* At least until the Google OS Brain implant is released
Interesting article. I noticed your PIN Debit reference. I no longer make the Hardware vs. Software argument either. There isn't one. The only way to do PIN Debit is to capture the magnetic stripe. Software can't do that. Only Hardware can.
I agree…in part.
The reason that what you/I would call hardware is required for PIN Debit
transactions is, truly, nothing more than a requirement from processors for
keyed firmware. If that requirement wasn't in place, the process of
transaction encryption could easily be done “on the wire”.
I think the bigger issue…and that to which I refer when I speak of
hardware vs. software….is the question of “intelligence”. It's sort of a
poor choice of words, but the best I can come up with at present.
The traditional terminal device was “it”. The end-all/be-all of acceptance
methodologies. Over time, the software based acceptance methods (be they
online, hosted, or local) were positioned as value-add for the features they
provide. And yet, there is still a benefit (financially) in performing a
swiped transaction.
So you leverage a USB card swipe. Is that hardware? Yes…but it is
hardware in the same fashion that a keyboard is hardware. Hardware, of some
sort, is required to run and interact with software.*
PIN Debit is a great example. I need a certified PED if I'm going to
perform PIN Debit transactions in a safe/compliant fashion. The hardware,
however, is truly just an encryption and input device….designed to
interact with the software that is providing connectivity, routing,
transaction qualification, and business management functions.
* At least until the Google OS Brain implant is released