June 18th, 2014 • Features
As you’re reading this, KiSSFLOW‘s payment handling mechanism has been completely moved out of Google Wallet.
From 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:
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/
* - Based on usage requirements