Google – Core Dump

You got heart, kid.

A lifetime ago I used to be a developer. I started coding when I was in 9’th grade with GW-Basic on an IBM PC which ran an Intel 8086 processor with 256kb RAM. I have to admit this was the most fun I had as a 12 year old and I was hooked. I pushed the boundaries of the GW-BASIC interpreter by using commands like Peek and Poke which the elders told me to stay away from. In short Peek and Poke let you do some wild things with the language like prodding the brain of the computer. However you start to realize that as fine as an entry level language GW-BASIC was, you can only push the boundaries to an extent. (Developing a hotel management system entirely using Random Access Files in GW-Basic that used its own custom index scheme to locate records using B-Trees was quite painful).

This was all fun and good, but taking a full day to run all of the month end accounting sucked. Enter dBase III plus and Foxbase which rocked my world for the next couple of years. As I graduated high school, I got introduced to sexy Pascal and finally C – the mother of all languages. (I did dabble in some 8086 assembly, but I figured I wasn’t a masochist and gave that up).

C taught me the discipline to code right. You do not take anything for granted. You could not assume you “freed” a pointer. Or that array you allocated had enough space to capture that crazy user input which will someday cause a buffer overflow. In my first paid gig at caterpillar I had to write a symbol table implementation that created a memory manager for strings in C. This memory manager wrapped the alloc() and free() to keep track of all strings being handled within the application (that automagically built a service manual for a giant caterpillar earth mover).

At this stage I was starting to explore C++ but it seemed like an abusive relationship. It just didn’t feel very natural and I wasn’t too excited to switch my primary development tool of choice at that point in time. This is when a new kid on the block emerged- Java.

Java was touted as “Write once – Run Anywhere”. In fact, it was so hyped up at that time the whole world went crazy and tried to shove Java in places where it should not belong to. (I am looking at you Sony – for committing the crime of writing your entire blu ray spec/stack in Java which in my opinion is one of the worst conceived ideas ever).

By the time the world woke up and got to its senses, enough damage had been done in the form of Java applets. However, the one saving grace that came out of this debacle was server side Java. While Sun Microsystems was busy in a pissing match with Microsoft and others, the enterprise application server market started blossoming with players like BEA and IBM making good contributions on the Java Enterprise scene. (Remember the venerable pet-store application?)

Today, many of the commercial enterprise level applications and services are powered by software written in Java. The ecosystem and development tool chain are supported by a robust set of offerings by players like the Eclipse Foundation, JetBrains and Oracle.

Around this timeframe, the concept of n-tier application development hit main stream. Java borrowed some good ideas like MVC from Smalltalk and made it commercially successful. While Java did a great job on the Controller side, it did have some weakness on the Model and View side tools. The native database support for Java existed in the java.sql package. Any database developer worth his salt would let you know how much CRUD code you needed to develop in order to get the backend model represented properly and it was quite the chore.

Enter ORM mapping tools like Hibernate. They simplified the idea of building models in a more natural fashion by taking away the complexity involved in writing plumbing code. Java took note of this and introduced these features as part of the core language as Java Persistence API in future releases.

While the model side of the world settled with solutions like this, the View on front end was not a pretty scene. Java server pages technology was the recommended way to build the front end of web apps. This was not a great solution in many ways as the graphic designers would mock-up HTML and Java developers would take this and translate that into backend code. In order to perform front end dynamic validations you resorted to Javascript.

Now Java developers always looked down Javascript as an inferior development language. There was a philosophical difference between Java as a strongly typed language v.s. Javascript, which was interpreted at runtime. Javascript developers were called/treated as “script kiddies” and Javascript as a language was not being considered for any serious development (primarily due to its applications on the front end side in the browser).

This all changed in the last few years. A powerful set of libraries started emerging for Javascript and lot of serious development started to happen. With companies like Google, Yahoo and Facebook committing to Javascript development, we started seeing some new unique tools and features which are making web experiences more engaging and realtime.

The pivotal moment for this development can be attributed to the advent of Node.js (a Javascript runtime environment that allows JS code to be executed on client as well as the server using Google’s powerful V8 Javascript engine). JQuery created and abstract layer on the front end end for Javascript which took care of many of the browser level rendering idiosyncrasies.

In fact so much development is being done for Javascript these days that there is a rich array of options a developer can choose from:

Web Frameworks: Angular JS, ReactJS, EmberJS, Meteor.

Front End Development – This list is long, I am hyperlinking it here.

Compilers – Babel, traceur

Build/automation Tools – Grunt, Gulp

Package Managers – npm, bower, yarn

Mobile Cross platform Development – Sencha Touch, Phonegap, Ionic, Kendo UI, Mobile Angular UI, Intel XDK

Backend Development – Node.js, Express, Koa, Horizon, socket.io, Redux,

Javascript Databases – RethinkDB, TaffyDB, PouchDB, LokiJS

I was quite amazed by how rich the Javascript ecosystem has grown. Javascript is the #1 language in github with the most number of active repositories and commits as seen here at Githut.

To summarize, I have developed quite the respect for the Javascript ecosystem. As Captain America said – You got heart kid!

(Image Credit – Marvel Studios).

Digital Delight – How are you moved?

index-mobile 2007 was a watershed moment in technology. The iPhone redefined the concept of personal computing and the world as we knew it was never the same. In just a decade, we have seen the proliferation of smart devices in every aspects of our life. We take for granted the various conveniences offered by our smart phones.

However too much of a good thing can also create fatigue. Our smartphones are cluttered with apps which we download and use once or twice and never revisit again. Like a kid in a candy store, we hoard on apps and eventually get tired of it and settle on a few which truly make your everyday life easy. If you start filtering apps with this lens, I bet most folks don’t use any more than 10 to 15 apps in a repeating basis.

Apple and Google haven’t really done much to help solve this hoarding issue of the users. I have always thought a neat feature in an operating system level would be is to notify the user of an app dormancy – if I haven’t touched a thing in 3+ months, is there any possibility I would ever use it again? Recommend a list of these apps which I can get rid of and keep my sanity!

At the end of the the day, the few of the 10 to 15 apps we use may not be the best of the best but they may serve a utility which we cannot live without. A good example would be apps published by your banking and credit card providers. I counted a total of 10 apps in my phone representing my banking, credit card and investment/retirement account providers.

A fellow Fintech Mafia member Alex Jimenez mentioned the other day that most of the mobile banking apps are online banking shoved into a small screen. I tend to agree with his assessment. In a race to keep the mobile apps in feature parity, most financial institutions are in a rush to port the kitchen sink into their mobile apps. While I appreciate the swiss army knife of a mobile banking app, we really don’t need 48 features in a form factor meant to engage you for less than a few minutes to take care of quick and important banking transactions.

A mobile banking product manager’s wish is to figure out what makes the customer tick. Everyone wants to build the next Uber of the banking service. However, to get the formula right to digitally delight a customer is not an easy task.

What is Digital Delight you ask?

Digital Delight – if an online or a mobile product/service creates a pleasurable moment that makes an experience just a little more fun.

How can we can introduce this digital delight as a product designer? Not all of the apps can be digitally delightful as Monument Valley the game (which btw still blows my mind!). Sometimes the opportunity lies in taking the most mundane process workflow and integrating that into an informative notification that can make a huge difference.

Case in point – Delta launched a new redesigned app with a feature to track the status of your checked in bag.

delta1

(Image Credit – Delta)

From the moment the baggage gets tagged into the system, the Fly Delta app starts tracking the baggage in transit. You get notifications that your luggage has been loaded into your plane. It allows you to see where your bags are at any point in time even using a satellite map!

delta2

(Image Credit – Delta)

I want to send kudos to the Delta team for making an useful feature like this part of their app update. This is certainly one of those things where I was delighted to see in action. A nice video of this feature is available here.

What other apps surprise/delight you in this fashion? Share them in the feedback section below. As I see digital delights in the wild I will make sure I share them as well.

Happy New Year 2017!

Google wifi – Mother-in-Law Approved.

gwifi

I live in a three level home which is a terrible location for a wifi network to provide full home network coverage. Interestingly enough, the home I used to live prior was much larger but my good old 8 year old Linksys wireless N router never had any issues covering 4000 sq.feet between two levels. When I moved to the current home I live now, I chose to have my cable modem installed at the basement level (which was a terrible mistake). The walls of this home seem to have lead in it which almost makes the home sorts of a Faraday cage killing the signal strength on the top level.

Hence started my quest to find a router that worked across all three levels.

Setup 1:

My first move was to buy a cheap router (D-Link) and use it as slave to my primary Linksys router at the basement. I decided to buy a NetGear Powerline Adapter to extend the Ethernet connection to my third floor and then use the D-link router to setup a slave network. In theory this sounded fine, on implementation a few issues arose. I had two distinct wifi networks in my home and I had to switch between networks as I roamed around. Not to mention the fact both the Linksys and D-Link routers had dual-band radios for 2.4 Ghz and 5 Ghz, so I had 4 wifi networks in total!

Why can’t you disable one of the radios you ask? Well the 5 Ghz does extremely well for short distance applications (like streaming Apple TV) while the 2.4 Ghz radio crosses walls better. To make things more interesting, I had the 5 Ghz radios in Wireless-N mode while 2.4 Ghz band operated in Wireless G/B mixed mode to provide compatibility to older devices at home. (As crazy as it may sound, an average home these days can easily have more than 20+ wireless devices considering all of the the cell phones, tablets, SMART TVs, Laptops, Media Players, Smart Home Assistants like Alexa, refrigerators etc).

Setup 1 worked OK for a while but I was getting mysterious signal drops on wifi when I was in the slave network on the third level. The connection would randomly freeze and I would have to reset the wifi radio on my phone to get the connectivity back on. I was not sure what the culprit was. By process of elimination, I could tell the basement Linksys router was working OK and the slave D-Link upstairs was working fine as well. (I swapped them and the problem still persisted). This made me conclude the culprit may be the NetGear Powerline adapter (which uses the home electrical connectivity as an extended wired Ethernet network).

To test this theory out, I bought a TP-Link Nano Ethernet Poweline adapter to see if it solved the problem. After swapping it with the NetGear, the problem seemed to have gone away for a few days and then it was back again.

House 1: Me 0.

Setup 2:

Based on lessons learnt on Setup 1, I realized there may be a hidden electrical goblin in my house wiring eating my IP packets. I started exploring alternate options like wifi extenders which technically extend the same wifi network across a bigger area. I ended up buying the Amped wireless extender and connected that to my basement Linksys router. While this seems to have marginally solved the problem, I was still having intermittent issues with connectivity dropping randomly which was quite frustrating. After a 2 week trial run, I returned the Amped back to Costco.

House 2: Me 0.

Setup 3:

By now I was starting to think the issues may be with my Linksys router which did not have a firmware update from Cisco in 4 years. I started researching new routers. This is when Google got into the router business and launched their OnHub router with the help of TP-Link and Asus. OnHub was google’s first foray into home networking business. The OnHub was supposed to solve all of the coverage issues. I was ready to cry tears of joy and drove to BestBuy to pick it up on Day 1 when it was released.

OnHub ended up being a huge disappointment. Since it was a router on its own respect, I replaced the basement Linksys with the OnHub. The setup was super easy with a smartphone app which configured all the settings which was very cool (compared to the legacy admin consoles hosted at 127.0.0.1 in your older routers). It was definitely very user friendly but ultimately failed the important test of not being able to have the range to penetrate the lead-laden walls of my house to the third level. I mucked around with various settings in vain. However the best speed which I was able to get on the third level was a measly 750 kbps. No YouTube or Netflix streaming while I was in bed.

House 3: Me 0.

Setup 4:

OnHub was promptly returned after 3 days of testing as it didn’t quite cut it for my needs. At this point I was fairly disillusioned with fancy new routers and did more research to find the holy grail of routers. After reading many reviews on The Wirecutter, I finally decided to give the Archer C9 a try. The Archer C7 was rated as one of the best router (for most people) by The Wirecutter in the market. I picked up the Archer C9 from Costco. The added bonus was it came with a range extender which worked out of the box.

The Archer C9 seemed to do OK on most of my testing and has been my primary router for the past year. The extender would take the same wifi network name, so I did not have to keep switching networks as I moved around the house. However I did notice a little bit of lag in streaming speeds on the third level. It worked most of the times, but sometimes it would make me reset the wifi radio in my phone to get it to work again. (By now you may have realized that turning wifi on/off has been something I do at least a few times in an average day and over a period of four years it gets mighty annoying. You ultimately give up and accept it as price to pay to have a wifi connection – I keep reminding myself of pre-wifi days during when I went and bought a 100 meter Ethernet cable 12 years ago when wifi was not a common concept!)

House 3.5: Me 0.5.

Setup 5:

Recently I came to know about a new concept where a new breed of mesh networked home wifi equipment that have been popping up in the home network scene. Most prominent of those were NetGear’s Orbi, Eero Home wifi, Luma Home and Google Wifi.

I stayed away from making a leap into this scene as these equipment were all quite pricey. (Typically more than $400). However when I watched the Google Hardware event on October 4’th, I was blown away by some of the things Google launched/announced. They had a wide range of products from Pixel Phone to VR goggles and then Google Wifi. Watch this video starting at minute 50 to catch the Google wifi announcement. The pricing seemed reasonable for the three pack unit starting at $300. I decided to give one final shot and preordered the Google wifi from Amazon.

I received Google wifi 3-pack today and opened it to perform the setup. The packaging was very apple like. There was just a quick start card inside along with the units and power cords and an Ethernet cable. Very simple and spartan. Following the quick start instructions, I downloaded the Google wifi app on the app store and started the installation process.

I setup the circular hockey puck looking units (a little larger than that) at each level in my home. These devices are beautifully designed and blend into the environment. The bottom of the devices have the SSID of the unit and a password to connect to it (Note: You will only use this SSID and password during setup).

Setup was a little confusing to start with. The App was attempting to connect to an unit without asking me to join to the SSID broadcast by the base unit. I had to manually switch to phone system wifi settings to connect to the SSID of the base unit. At that point, the setup app took over and asked me to name the location where I placed the unit (basement) and asked me to also name the home network.

Once I did this step and the network was created, the app asked me if I had more Google wifi units. I had two more units I needed to setup. The app again went on a wild goose chase trying to locate both the units. I had to now switch to phone wifi settings to identify the unit by name on my family room. Once I connected to this unit using the user id and password at the bottom of the unit, the app took over again. This time the app recognized it as a peer unit and configured it part of the home mesh network. I repeated the same steps for the unit on my third level and it connected to the network like a charm. I breathed a sigh of relief when I realized all of the three units were part of the mesh network and were under the home network SSID I created when I setup the first unit.

Now to the acid test. Speed Test app blazed through on all three levels with speeds consistently exceeding 70 Mbps. I tested the speeds while I was stationary on all three levels. Then to put the system to the test, I started a Speed Test and moved around the house where I knew the connectivity would be weak. Impressively enough I could see the speeds slowing a bit on dead spots but the mesh network came to rescue with another unit picking up the signal seamlessly and I could visually see the speeds normalizing to the 50 Mbps and above threshold.

Finally I think I have a winner with Google wifi!

The best part about this is I hope I do not have to keep resetting the wifi to stream YouTube on my visiting mother in law’s iPad which is worth its weight in gold!

Home KO: Me

2015 is not the year of Mobile Payments.

mobilepmnt

There, I said it. It’s an inside joke amongst the payments industry folks to guess which year might be the year when Mobile Payments finally becomes mainstream. It may seem with the highly promoted launch of Apple Pay, we may have finally put a rest to the claim that 2015 is the year when mobile payments finally hit mainstream.

Maybe Not.

For all intents and purposes I feel Apple Pay, with its marketing momentum, managed to make the general public take notice of mobile payments. However, with Apple finally decided to get into the ring, it managed to make the other failed efforts combine forces together to finally put up a fight. I see the playing field with four major players.

Apple Pay with NFC
Google Wallet with NFC (Android Pay?)
MCX/CurrentC/PayPal/Paydiant Wallet
Samsung Pay (With Loop’s MST and NFC)

Each of these players have their own strengths to polarize the market in their own way. Lets dive in!

ApplePay:

Strengths: Best User Experience for making mobile payments in the current landscape. Pioneered the concept of tokenization and biometrics to provide a new easy way to pay. Brought all the payment networks and banks to execute a near textbook perfect launch.

Weaknesses: Merchant Adoption. As we see more merchants adopting NFC enabled terminals (and the EMV liability shift in 2015), the number of locations where you use Apple Pay will grow. However, don’t expect to use Apple Pay in your neighborhood Walmart anytime soon.

Not having any rewards programs to brag about is another limitation with Apple Pay.

Add to this the other side of Mobile phone pie, the Android user ecosystem who zealously hate anything Apple Makes. These folks will never use Apple Pay, no matter what.

Opportunities: As more of the newer iPhones get sold, Apple Pay will gain traction and people will try it atleast once to see how this works.

Threat: Industry analyst Cherian Abraham has been blogging about the fraud activities generated by ApplePay. Even though none of this has anything to do with the security measures Apple put in place in designing Apple Pay, the soft underbelly of the whole scheme is the Yellow Path for provisioning cards for users. Banks were forced to launch AP without much time to account for this newer security threats and that may slow some of the momentum.

My take: I would equate the launch of Apple Pay to Tesla’s Model S launch. Both were revolutionary products in their own respect. They broke the convention in their areas where common wisdom dictated that it could not be easily done. However, any first generation product there may be some quality issues which may get ironed out as future versions are released. Apple Pay is surprisingly a solid offering for v1 and it can only get better.

2. Google Wallet with NFC (Android Pay?)

I don’t even know where to start with this. Google Wallet has languished forever mostly due to Google’s approach in not building partnerships with the players in the field. Finally the stars aligned for Google Wallet after the Apple Pay launch and lit up the much needed fire in their back to get their act together. Google was able to broker a partnership with Softcard and provide its new wallet offering as an API.

Strengths: Launching Android Pay as a payment API (See Sundar Pichai’s remarks here) is a wise move. This allows Google to open up the API to device manufacturers and developers to build wallets which may result in mainstream adoption. Apple’s walled garden approach would have never worked for Google in the first place. Android has a healthy user base in US who may try this service.

Weaknesses: Design by committee never produces mind blowing user experiences. Apple Pay set a very high bar(See Tim Cook launch Video here). I cannot imagine how the Android Pay UX can be any simpler than this given the fact that it has to work on a multitude of devices made by different manufacturers. The rev. share scheme Google has promised the Telcos to pre-install Google Wallet in newer handsets sounds like something which needs to be vetted after product launch to see how successful it may be in the long run.

Opportunities: Android has an 80% worldwide market share (source). With an open API approach, Google is betting on sheer volume of its users to make this a success. When you thrown in enough magic potion in the cauldron, you never know what may come out 🙂

Threats: Not having the first movers advantage sometimes may come back and bite you. Apple Pay was able to alleviate this shortcoming with an amazing UX. With Android’s open model and fragmented ecosystem, the success of Android Pay may not be imminent. If history is any indicator, the ARPU(Avg. Rev. Per User) for Android is one quarter of iOS users (according to Benedict Evans analysis here).

My Take: Android Pay maybe late to the party but it surely provides an alternative for Apple Pay. How successful this may be is something we will have to wait to see.

3. MCX/CurrentC/PayPal/Paydiant Wallet

Its hard to analyze a wallet only a few have used in Beta. However, the PayPal acquisition of Paydiant came as a surprise and caught most of us off guard. We well knew MCX was working with FIS/Paydiant to use their QR code technology to payments. The QR-Code premise was very promising when all of the industry pundits declared NFC dead (including me). Add some Apple juice and suddenly we see a re-animated NFC becoming the de-facto payments standard.

The QR-code method of payments is still not bad. We use it in Starbucks everyday and most people do not have any issues paying using QR-Codes. However the entire premise of CurrentC wallet which tries to remove payment networks from the picture (atleast in the first iteration) seems like a dicey proposition for a successful launch. From a consumer point of view, I do not understand why a customer would be motivated to link their bank accounts to save interchange fees for a merchant.

4. Samsung Pay (With Loop’s MST and NFC)

Talk about bad timing and possibly some buyer’s remorse. Samsung acquired LoopPay which would provide out of the box support to use existing POS terminals using the Magnetic Secure Transmission technology. While many rumored a marriage between these two companies could have provided a great mobile wallet in Samsung phones, this comes a year too late. With the EMV liability shift fast approaching, many merchants are upgrading their terminals. The concept of swipe as we know may go the way of dodo pretty soon. (This reminds me of Blu-Ray as a technology. I wonder how many people still buy Blu-Ray players now that streaming is becoming the most preferred way to consume content?)

Naming this technology as Samsung Pay is also not a great move in my opinion. For the hardware chops they have, Loop technology could have been made into a hardware chip which Samsung could then sell to any of the device makers thereby securing their investment and guaranteeing a longer shelf life with strength in numbers . With Google announcement of Android Pay API, I am just not sure how Samsung would promote their offering when they will also have to install Google Wallet.

Conclusion:

So, I hope, my dear reader, if you have come this far, you probably know how big of a cluster is the current mobile payments landscape in US. I don’t even want to imagine the free technical support we have to provide our families and relatives once every one of them gets their hands on a pay with a phone thingamajiggy. So good luck.

For my money, I can surely bet 2015 is not the year of mobile payments 😉

Mobile Payments – Are we there yet?

Mobile Payments is the hottest topic in the market now. If you are following the payments industry you would be pleasantly surprised to see the amount of interest in this area from various players which include Financial Institutions like Banks, Card Networks, Processors, Telecom providers, Silicon Valley Giants, small payment startups, retailers and pretty much everyone you can think of.

It’s all Steve Job’s fault:

The iPhone for all we know started a mobile revolution where upgrading the latest OS firmware is something you see customers discussing at coffee shops in the morning. (Did you upgrade to iOS7? I hate the color themes. I am still at iOS6 and love it!). Not to digress too much, but the iPhone opened up a cottage industry of all the things you could do with the device and Google couldn’t sit there and let Apple have all the fun. Thus Android was born (which opened up its own industry of phone makers). The latest browser stats show Chrome and Android browser leading the pack in usage while Firefox, IE and opera losing market share.

Facebook was fun with mobile, so was Instagram, Twitter and all the lifestyle apps which “made” you more productive. It was quite natural that mobile devices evolved to add payments as the next killer app – except the existing payment initiatives in mobile have quite underestimated one fact. The customer didn’t find the idea of paying with a plastic card too hard on the first place. What is the mobile wallet value proposition? Just replacing the leather wallet with a mobile wallet app which can store payment and other credentials does it for customers?

The mobile payments landscape is quite fragmented with a lot of confusion of what really constitutes the ecosystem. Here are the major categorizations:

Mobile at the Point of Sale (Pay using your phone)

–Consumer payment method utilizing NFC, QR Code etc.

–Google Wallet, ISIS, Square Wallet, PayPal Wallet

Mobile as the Point of Sale (Accept payment with your phone)

–Merchant utilizes mobile device to process transaction(POS)

–Paypal, Square, Intuit, ProPay

The Mobile Payment Platform

–Broader mobile payment platform, typically a mobile wallet

–Utilizes NFC, Cloud, QR Code, GeoLocation, GeoFencing and Proximity

–Google Wallet, PayPal, FIS Paydiant, Level Up, Dwolla, Square

Direct Carrier Billing

–Purchases made via mobile phone – charged through wireless carrier

–Zong, Boku, Mopay, Any Telco issued payment app.

Closed Loop Mobile Payments

–In-store only transactions

–Utilize QR codes, Proximity payments

–Starbucks, Level Up, Square Wallet, PayPal (Closed Loop Offers)

What does this mean to the average consumer on the street who wants to pay with their mobile? A lot of confusion. Most of this arises from the fact that there is no standard way to make a payment from the phone. If the GPS technology we use on the phone was similar to what we have in mobile payments today, we probably won’t have most of the location aware apps which make our lives easy(Maps, Yelp, Offers, FB, the list goes on). A good Fintech friend (Matt West) once said he will validate the success of any consumer technology if his mom finds it easy enough to use. Do the Mobile payments solutions today pass the Matt West’s mom test?

What is the primary issue in adoption?

Really the primary issue here is – Do you want one wallet to store all your credit cards and hope that the POS terminal merchant has a way to recognize it? Or do you want to have individual closed loop solutions like Starbucks Mobile app? (Rated as the #1 mobile payments app). An average customer would probably have certain shopping preferences of where they would shop. Existing usage trends have shown that customers download and use Starbucks app and Target RedCard app more due to their richer closed loop experience. A generic mobile wallet can still be a attractive value proposition in locations where they shop infrequently (A gas pump for example).

In a twitter conversation I had with Guillaume Lebleu and Brad Leimer about payments Guillaume mentioned the idea that The mobile wallet is your “transaction browser”, something you’ll use for transactions you don’t have a dedicated app for. I agree with his idea of having dedicated apps for most frequent use and have a generic payment wallet for merchants who do have a native app combined with a wallet. Brad mentioned the fact that there should be a unified backend to make payments simpler.

Integrating Mobile Payments at the Mobile OS Layer:

A truly well thought out mobile wallet would arise only if the major mobile OS players decide to build that as part of a new payments API. Currently these providers (Apple, Google, Amazon, Microsoft) have provided ways to do in-app billing(mostly used for games and digital subscriptions) but to my knowledge they do not have a way for a closed loop wallet application to securely process a payment. All of these successful closed loop systems have their own cloud based payment/auth mechanism which are custom built.

Unified Payments API hooks:

If the mobile OS can provide a payment API hook that an app can utilize, retailers can build their version of a closed loop rich app similar to Target or Starbucks that can be customized with their specific offers and loyalty programs. To make something like this to work, the mobile OS has to provide a payments API infrastructure which is present in the cloud (and not on the device). This may use the Secure Element or shouldn’t have to. It can store most of your wallet information in the cloud and let you manage the cards in the cloud (Similar to Google Wallet or PayPal). This card on file information can be represented as a secure payment token within the mobile device (not the actual card details themselves, but a reference to the card in the cloud store). In case of Apple, this could be iCloud, Wallet for Google, Xbox Live for Microsoft.

When a retailer built closed loop custom app wants to utilize payment information, it requests access to this wallet from the underlying OS. (Similar to how they now request permission to use your GPS, Microphone etc). The OS provides a list of payment methods to the app which can be selected by the app’s payment handler (either set that card as a default mechanism or allow to change payment as required). If the workflow is built with the right hooks for extension, providers like Wallaby can inject value by recommending the the most optimal payment card which maximizing the user’s loyalty options. (Eg. Use the Discover card at electronics store to get 5% cash back type schemes).

An app built in this manner can enrich the in-store shopping experience by providing a view of the full inventory. What if an item you are looking for is not in that store? The mobile version of the retailers app may allow you to order and pay for it from the app and have it shipped to your home directory. The primary difference between what we have now in the likes of Amazon and iTunes app is, the customer gets to store more than one primary card on file, as well as have the liberty to choose where their wallet will reside and the OS will secure the storage and provide a uniform way to access payment apps within its platform.

Generic Wallet:

Many consumers may still find the generic mobile wallets like Google Wallet, ISIS, PayPal and Square quite attractive for their usage patterns. Any merchant who may not have a closed loop scheme can decide to be part of one of these generic wallets to accept mobile payments. Even these generic wallets can start utilizing the underlying OS Payment API hooks in a similar fashion explained above. Google Wallet already has a great way to inject Offers and Loyalty programs for merchants who decide to go through this route using their Wallet Objects API. Other players are offering their own way of launching these value add-ons to the generic wallet. (Level Up has launched its white label, PayPal with its Beacon, Dwolla with its POS payment option).

So who gets to manage this cloud wallet?

This is an interesting question. The payments landscape is big enough to accommodate more than few players. Some people are comfortable with their Banks storing this wallet information. Some are comfortable with Apple, Google, Paypal, Amazon handling this cloud store. Some may trust Visa/MC/Amex/Discover with this function. This will once again be a turf war where once you get locked into an ecosystem of Apple or Amazon or Google, you may decide to stay with them due to the convenience factor.

The next generation Payment API/Wallet?

Add the ability to store Bitcoin and other alternative digital currencies in this infrastructure and we maybe truly looking at a next generation wallet which can be the payment wallet of the future. A lot of innovation is happening at the payments space and its a gold rush. The OS providers wield a considerable amount of power by acting as the gatekeepers of mobile commerce which are facilitated through the mobile devices used by consumers. As long as they can keep the payments functionality simple and pass the Matt West’s Mom Test, we should see mobile wallets playing an integral role in the future of payments.

The latest Android edition (KitKat) has released with new Host Card Emulation (HCE) feature which is a great first step in providing OS level integration for Payment apps. Read more about it here.

Update 2:

Cherian Abraham has done it again with an excellent analysis of Android/Google’s strategy on HCE. You can find it here.

Square Cash – P2P on Steroids?

With much excitement, I welcomed the news that Square had joined the P2P game with other players like PayPal. I am a big fan of the Square Dongle . I admire the simplicity of how it solved the problem for a niche market of small merchants who could not process credit cards.

Once I dove into the announcement and started reading the details of how this worked, I got a little queasy. With some knowledge of email marketing and how it can get abused, I am a little weary of a P2P scheme that tries to use email as an orchestration mechanism for sending money from one party to the other.

In the meantime, many of my FinTech friends were raving about the simplicity and beauty of the service. I therefore decided to give it a test drive. I downloaded the iOS app, launched it and was greeted with a screen to enter the amount I wanted to send. Square cash, by default launched the mail program and created a mail template where the recipient email and message can be customized.

Without diving too much into the mechanics of how this works, I would like to present my observations below. (If you are interested in reading how it works, you can find it various places like this one).

I tried sending $10 from one of my Gmail account to another using my Bank A Debit card to my Bank B Debit card. Once I opened my mobile mail app, I saw quite a few emails from Square. Since this was a test, having an unified inbox app that had access to both the email accounts I used for testing was a mistake.

I ended up getting a total of 8 emails from Square, which added some element of confusion. (I do understand this will not be the case in a real world scenario when you try to pay someone else). After sorting through the emails and completing the required steps from the sender’s perspective, I was able to transfer the money to the other party. From a receiver’s perspective, I got an email from Square instructing me to either use a debit card or to set up a bank account to receive the funds.

Interestingly Square cash runs the whole transaction on a Visa/MC debit backbone API. This scheme seems to work very similar to how you would pay at a POS terminal using your debit card. (More details of this API can be found in this Quora thread).

I got a purchase alert SMS from Visa that my debit card was used at SQC*”DEVA ANNAMALAI in San Francisco US” for the amount I sent as a Card Not Present Transaction.

I logged into my receiving account and saw something interesting – the $10 showed up as a pending transaction. Note the description shows up as a “REFUND”. This further confirmed my suspicion that Square processed this transaction as merchant refund into a debit card.

While the common user on the street would quite not care about the mechanics of how all of this works, this did raise some questions which I wish Square would provide answers to get more transparency/clarity on this service:

1. Square Cash Terms and Conditions dictates that as an end user, you can only create one account. (I am assuming it is a debit card/email combination to create the new account).

2. The T&C frequently mentions the term Square Cash Account. My interpretation of this is Square creates a Card on File Account for the email address which is being used to send the money along with the Debit card. The T&C does not clearly state that, but my best guess is Square is using this as a strategy to compete with PayPal and Google Wallet in increasing its consumer user base. (Check Cherian Abraham’s excellent analysis on his blog post about this topic.)

3. Now the big issue I have with this approach is PayPal and Google Wallet allow you to manage the account by allowing you to store various payment cards in the wallets. With Square Cash, the user seems to be stuck with one debit card to their account. I have no idea what it takes to switch this card on the file to a different card (Or) How someone would go about asking Square to remove their stored card/account. (Some folks are not comfortable for merchants to authorize a direct pull from their bank accounts).

4. The legal age to use Square Cash is 18. I wonder how many under age users who have debit cards will be using this service to send money to their friends. I don’t think most folks in this demographic would even bother to read the terms and conditions.

5. I tried sending money to two of my friends at the same time using the Square Cash app. The app informed me that cash was sent (allowing me to type in two email addresses at the recipient field). However I got an email from Square Cash informing that they could not understand the request and I need to send money to only one recipient at a time. Gmail interface to send money via email is clear about the fact that you can only send money to one recipient at a time. It also lets you pick your funding source, the list of credit cards you have on Google Wallet as well as the Wallet Balance.

6. I believe email as a medium to communicate with friends and family is losing its popularity. When was the last time your friends or family members sent you an email? I am sure we use emails to receive statements, notifications and other random marketing emails. Using emails to keep track of P2P transactions seems weird to me. This is my personal opinion and Gen-Y may prove me wrong 🙂

7. I am also worried about the security aspects of trying to send money via email. Square has informed that they take security very seriously and have extensive fraud monitoring in place. However, mail service providers like Gmail and Yahoo by default have users signed in for extended periods of time in a web browser(Chrome being a good example). What if a malicious user who may have access to your computer sends themselves money and deletes the email thread? Square does mention you can add dual authentication using a mobile phone number but it is not a mandatory step. This probably is the most riskiest aspect of using the service IMHO.

8. Phishing emails – Most users who still open emails click on a phishing scam without thinking twice. Expect to see a lot more Nigerian royals sending money to your account 🙂

9. Gmail also starts categorizing some emails from Square in your Inbox and some in your Promotions tab. Not a deal breaker but something to be aware of.

10. With so many issues plaguing email in general, it leaves room to questions about why Square chose to use email as a protocol to orchestrate money movement. Email has an inherent benefit of being in the address book for all your contacts. Launching the app to build the email template seems redundant. Since they already have an app, they could have taken a secure network route like Dwolla to initiate and complete the funding request. The app could also have access to the address book! (I get it, at that point it becomes Venmo/PayPal/Dowlla 🙂

There are some interesting possibilities like paying a group of friends and adding multiple payments accounts. For the initial launch, Square has decided to attack the basic use case. If Square had partnered with a company like Fiserv to provide real time P2P, it would have been a killer proposition.

Square Cash may be successful in demography of techno-savvy crowd in metro cities and college communities. It would be interesting to see how long it would take for something like this to hit mainstream adoption. I am intrigued by Square Cash and would love to see the usage and its evolution. God forbid we all know that the US Payments system needs a reboot to enable more modern user friendly real time ubiquitous P2P options. Innovations like this would help us get there even if this is a first step.

Update 1: Marcelo Cortes was kind enough to share the link where you can update or unlink your debit card from Square Cash Service. When I tried using it, I had to perform a password reset to register myself. I appreciate minimalism, but this needs a little more clarity.

Update 2: Ron Shevlin raised an interesting question about Account to Account (A2A) money movement using Square Cash. This would be a very useful use case, but if we go by the Terms and Conditions, a customer can only create one account which may prohibit it.

Update 3: Another possible interesting use case is Bill Pay. If Square manages to partner with Billers, a statement email sent from the biller can be replied to pay the bill by CCing cash@square.com. Obviously some details need to be worked out about how to track the payment amount and account number details but I am sure the smart folks at Square will figure it out 🙂 – Now that is something which eliminates friction and opens up a new market!

Update 1:

Update 2: