We've been using Stripe for about two years now. We love it, but the one thing we're running into now is that we want to start adding support for additional payment options besides just Credit Card (e.g. PayPal).
The problem then becomes that all your subscription logic is handled via Stripe, so at that point you have to move your data to something like ChargeBee, or you have to set up your own in-house solution that handles working with PayPal's own recurring payments authorizations for some accounts, or Stripe's subscription features on the other.
We honestly haven't gotten far enough to decide what we're going to do about this yet. Moving to something like ChargeBee would make things simpler, but it adds an additional cost on top of what we're already paying Stripe/PayPal, plus we have to migrate all of the thousands of customer's data out of Stripe and into something else...
The Chargebee guys in particular are lovely, but for a recent project I went with plain old Stripe for a few reasons.
Firstly, I wanted to bill in multiple currencies according to where customers come from, and Chargebee required multiple API accounts, so that there could be no unified reporting of activity. Stripe, on the other hand, is perfectly happy with USD plans/subscriptions living alongside those in EUR or GBP.
Secondly, if you start with just Stripe, you can add other added-value providers like Chargebee on top later, but once you're committed to managing everything through those providers, it's hard to go back.
And finally, it would be easy to assume that you will need all that fancy Dunning process and workflow magic, but setting it up is an additional up-front time & complexity cost which might never pay for itself. Better IMO to start off simple, write a little code to track failed payments and expiring cards, and email the customers directly the old-fashioned way. This way, you're also connecting personally with your customers.
Credit Cards are rather uncommon outside of Europe so you will be limiting yourself there, though Google Wallet also restricts themselves to CCs in my country. In fact, the only reason I now have a CC is because I wanted to sell on the play store and needed to pay a registration fee. I would not have acquired a CC (which has a recurring cost) just to pay for a service if that service wouldn't have paid me back.
I believe it, that Google Wallet is geared towards mobile app developers. It's almost implied that Google Wallet is for mobile by the way they describe what Google Wallet is on their website: "Google Wallet is a free digital wallet that securely stores your credit cards, debit cards, loyalty cards offers and more. With Google Wallet, you can shop in stores, buy online, and send money."[1] The only part of this I see as not necessarily mobile is "buy online", but even that can be mobile and/or on the desktop/laptop.
I also found the Google Wallet to regularly stump users who wanted to buy my software, either because of an error or because they were forced to create a Google account. So switched from Google Wallet to PayPal (years ago).
Why not offer both payment systems? I've been getting annoyed with PayPal's stubborn resistance to letting me pay by credit card instead of my bank account (also an event where they completely bungled recurring payment to a service I was using), so I've been using Google wherever vendors take both.
Actually I did offer both for a while, but in the end I just found PayPal to be more reliable and to have fewer complaints from my customers. Seemed that giving the user the option of Google Checkout (as it was then called) was inviting trouble, so I made PayPal the 'default' option.
Both offer different price tiers based on volume. If you split between the two you could end up paying more percentage than just one. Besides it being annoying to deal with two systems.
The TLDR seems to be using the wrong tool for the job is possible but painful, and using the right tool for the job makes life easy. With a side dish of billing and payments is a really giant and diverse ecosystem, so whats perfect for them is probably not adequate for us, and likely vice versa.
I think part of the tl;dr is that at first it was the right tool for the job, but then both the tool AND the job changed, and then it wasn't that good.
What I'm wondering though, is they say Wallet is being focused on mobile devs, but what if I'm a mobile dev that also wants to offer a subscription service or something else that they identified as a problem for them?
Has anyone else experienced issues where a business simply refused to make the purchase through a system like this? HHMI would not pay me through PayPal because they consider it 3rd party credit card billing, and I don't think any of the easy options fix that.
