Sadly, we are leaving Google Wallet

kausikram

June 18th, 2014 Features  

As you’re reading this, KiSSFLOW‘s payment handling mechanism has been completely moved out of Google Wallet.

empty walletFrom day one, KiSSFLOW has been a product that was built keeping Google Apps users in mind, and we consciously decided to go all out for Google technologies. We use Google App Engine, Google Cloud Storage, Google Big Query, Google Cloud SQL and just about every Google Cloud technology that is out there. We are and have been extremely happy with Google’s Cloud Services and Support. However, one product has been a pain for us for a while now – Google Wallet.

When Google started moving away from Google Checkout and towards the new Wallet a couple of years ago, it seemed the most obvious choice for us. Firstly, it was a Google product and, since all our customers were Google Apps users, we thought that it would reduce any friction that might arise during the paying step. Secondly, Wallet seemed to be brimming with promise back then, Google had gone all out to build something that was better than Checkout, and we thought that it would be generic and that there would be a lot of new features coming into it. We knew we were taking a gamble but the odds, we thought, were in our favour. Also, Wallet was the cheapest payment gateway around – super important if you’re a startup.

Ouch!!! Over the last two years, our engineers, our sales team, our accounting team and our support team have come back to us over and over again with a number of issues and limitations that made us realize that Wallet was not the right choice. Wallet, over the last two years, seemed to be shifting from the generic payment service that we thought it was to being a payment gateway inclined primarily towards mobile app developers. Now, we are not mobile developers, and we don’t know how green the grass is on the other side of the fence; but we sure know that, as SaaS ISVs, we were left in the lurch.

Sales Complained: Sales’ biggest requirement was a self-service system to initiate and terminate trial accounts, generate Discount Coupons, change subscriptions, and to manually update card details. When customers wanted to buy some more licences, they would be expected to key in their credit card details afresh as, to Wallet, this was a new purchase. The entire PG offering was so limited that the onus of implementing a better system to actually handle subscriptions fell on Engineering.

Engineering Complained: Engineering knew that Wallet was just a payment gateway service and not a recurring billing solution, and hence it had to build a layer on top of Google Wallet for the kind of features required for a SaaS product. However, whatever subscription-based billing capabilities Google Wallet offered just weren’t good enough. At the technical level, there were just two callbacks – success and cancel. No callback APIs for things such as inadequate funds on card, card expiry, transaction failure etc. We had to write most of the recurring billing code, notifications and error handling ourselves. The APIs were so shallow that we could not even perform a subscription cancellation.

Accounting complained: Firstly, there was no integrated dashboard that Google Wallet offered to track the subscription status of various customers. There was no notification to either the customer or the accounting team about expiry of cards, inadequacy of funds, or failure of the payment process. And, of course, Google Wallet accumulated all our earnings and transferred it at a go – the frequency of repatriation was once a month even if accumulated value exceed $10,000.

You might now rationalize that all our complaints so far do not strictly fall under the inadequacies of a payment gateway service provider. Agreed. But, more than anything else, our single biggest problem was that of reliability. Our users kept getting ‘Technical error. Could not process payment at this time. Please try again later’ messages, the last thing you would want.

As a SaaS company, you would know that the actual point of sales had to be the most easiest and most reliable system to work with. Once Sales, Support, and Engineering do the hard job of getting a trial user onboard, you really wouldn’t want to realize that, right at the moment of purchase, your customer was stumped and could not pay because of the payment gateway service despite everything else having gone well!

We were in a bad situation – we needed better functionality but, more than that, we needed reliability. And so, we decided to move. We looked at various PG services and also looked at various subscription payment systems such as Chargify, ChargeBee, Recurly, etc.

We took the plunge and moved to ChargeBee for recurring billing and Stripe to process payments. And it has been wonderful ever since. In addition to solving the problems of reliability, we got a whole goodie bag of extra features from ChargeBee that are very SaaS-focused. Engineering was happy – they could dump most of the extra payment handling code, and get back to improving our core product. The APIs provided by ChargeBee was clean, precise, reliable and helped in the complete automation of payment-related code in the product. Sales was happy – Discount Coupons could easily be generated, card details could be requested, and trial accounts could be automatically upgraded without engineering help. Accounts was happy – subscriptions could be manually marked as paid, and offline payments could be transparently and uniformly tracked. Of course, repatriation was happening once every 2 days. Above all, our customers were happy, and thus Support was happy. The number of PG-related problems dropped drastically, notifications were instant, automatic and kept all stakeholders informed of events, and it was a breeze.

The biggest learning for us is that:

  • a payment processing solution like Stripe/Braintree provides the components for recurring billing, but you still need to keep building on top of it
  • a recurring billing service that provides sophisticated layers on top of a payment gateway can save you precious hours for features required by sales, accounting & support
  • building it internally is also an option, but you need to have enough bandwidth of developer & management to improve your billing system to keep up with your startup’s growing needs

We weighed the options of build vs buy – ultimately, we ditched build and we went with ChargeBee + Stripe as our SaaS recurring billing solution.

 

Full Disclosure: Suresh Sambandam, our CEO, is an advisor to ChargeBee.

Image source: http://iluminisme.wordpress.com/ 
  • Mr Jack

    Did you try Amazon’s “Login and Pay” offering? If yes, any thoughts on that?

  • Oli

    This completely echos my experience with Google’s payment solutions. The APIs look great to begin with but once you dig in you’re locked into handling a completely brittle loop of payment logic. Google Checkout had subscriptions but —omfg— the time we spent implementing that was never recouped.

    It’s a sad state of affairs when Paypal looks like a decent alternative to anything.

  • Glad you found a good solution that works. I keep hearing good things about Stripe!

  • Suresh, Good to read this article. Please let me know if you need help in using PayPal APIs and I will find the sources for the integration.

  • James

    It was my understanding that Google explicitly forbids using a 3rd party billing service? Which means you can no longer use Google play and this would require users to download the app via your APK file (in order to do so they need to manually enable downloads of 3rd party apps on their device). This causes a massive drop in download rates. Any comments?