Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

Parent Full thread

Would you mind saying a bit more about why you felt building your own billing system was a bad idea?

We're looking into that at the moment, and have been considering the usual options of DIY, using Recurly/Chargify/similar, going quick and dirty with Paypal/Google, etc. Right now, after a great deal of investigation and contacting many organisations for more details, we are overwhelmingly thinking that a simple, direct system with a payment gateway and merchant account is the way to go. None of the usual recurring billing suspects has even come close to justifying the costs and usually lock-in of integrating their service instead.

However, in the HN goldfish bowl, almost everyone seems to have a different view (though I have noticed a few dissenting voices creeping in recently). Right now, all we've done is a bit of prototyping with the test system for the service we're looking at using and a thorough read of the docs. If we're about to enter a world of pain when we actually want this stuff to work, it would be good to hear any advice about how to minimise the damage and make it through!

Great slides, BTW. Thanks for sharing.

The main reason that I don't personally believe it's a good idea is that it's not a core part of Sifter. We use Braintree and process everything via ActiveMerchant, but we've been using Braintree so long that we're actually on their old API.

Obviously, since we built it in house, I don't have any hands on experience with the other options that are out there now, but from what I've seen with other applications, I can't see any reason not to use the other providers.

The downside to not building your own system is that you may lose some control over things like invoice formatting or other parts of the user experience.

The other aspect that's a big consideration is PCI compliance. We don't store any payment information on our servers, but it does pass through our servers which means we have to have the minimum amount of PCI compliance. By offloading it to another provider, you're almost entirely free of any significant PCI compliance.

Now that it's done, it's kind of nice having full control over every detail of how we handle credit cards. However, I wouldn't do it again now that there are so many other options out there.

Thanks for the reply. I can understand your reasoning, but I think perhaps our situation is different.

For future reference, you might like to know that there are now regular payment gateway/merchant account combinations where you can use their systems to handle the final part of the transaction so you never even have card numbers on your network, so the PCI DSS issues are moot, at least here in the UK. The lock-in isn't ideal, but as far as I know only Recurly out of the major billing services doesn't effectively lock you in just as badly anyway.

However, we've found that the recurring billing platforms tend to lack precisely the kind of flexibility you mentioned above. We have all kinds of plans to use promotional codes, multiple offerings that users can subscribe to individually or in combination, etc. As far as we can tell, none of the "big name" billing services even gets close to supporting this kind of stuff properly yet.

For the benefit of anyone else following this discussion, I'll also mention that because we're in the UK but most (all?) of those billing services are across the Atlantic, there are serious concerns about legal differences, particularly data protection/privacy rules, and about tax, particularly how VAT is handled. Again, the billing services whose terms and conditions we've checked out had deal-breakers here.

Given that the billing services take a relatively large cut out of the payments, sometimes with terms that don't even guarantee any particular level of service, and that we'd have to implement a whole bunch of things on top of their platform anyway, we concluded that they simply don't offer enough to justify the risks and overheads.

Those are definitely all very good points. Everyone's situation is so different, I'm always hesitate to give any advice as a "prescription" and more of "here's what we did and why we did it so you can decide for yourself".

I'm definitely aware of how easily the new services enable you to entirely avoid the PCI issues. Personally, I'd say that their cut is probably well worth it relative to the time and effort that it takes to build it from scratch. However, that's driven in large part because I'd much rather invest time in the product than worry about the billing details. It's not that it's all that difficult, it's just that it's not the core of what makes Sifter unique.

With regards to promotions and stuff, I'm not a big fan of that. I'm a strong believer in keeping things simple and people either like it enough to pay for it or they don't. I feel that promotions might attract people for the wrong reasons. The more complex the pricing is, the more painful it is to deal with, and it can quickly become a distraction from simply crafting a better product.

Of course, plenty of companies have had great success with promotions, but it's not for us. To each their own, right? Either way, I hope the info helps. Best of luck which ever way ends up working out for you.

I completely understand your point on wanting to concentrate on the main product and not the billing. That's why we spent such a long time looking into the alternatives, and we would happily outsource that side of things if we could do so with acceptable losses in flexibility.

It's interesting that you don't rate promotions, and I noticed elsewhere in your slides you were fairly negative about ongoing publicity spend. On that we would somewhat agree as well, I think.

The difference is more that we're in something of a niche market, nothing like the stereotype HN fodder that is aiming for the general public as a target audience and low prices. We've done a lot of research into both the global demographics of our market and various potential marketing channels, and it turns out that something as simple (to the customer) as a promotion code can support all kinds of other activities beyond just a generic coupon code promotion, as long as you can implement the right systems for generating and recording those codes behind the scenes.

This is where we felt the simple options offered by the various billing services today just weren't up to the job, and to some extent I'm not sure they ever could be since beyond a certain point I think these policies are always going to be customised to a particular business model.

Anyway, thanks again for sharing the slides. It's useful to know where you were coming from on that particular one because it's the only one where our current approach is clearly different to what you felt had worked for you. Otherwise, your experience is actually quite reassuring, as we had come to many of the same conclusions on your other points and it's nice to know that we aren't completely crazy! :-)

I went through picking a payment provider recently as well. I ended up going with Stripe[1]. It is currently in a closed beta, but if you request an account they are activating after around a week of waiting (you could also try emailing them).

Strip is brilliant - I wish I had it 10 years ago instead of dealing with Paypal or banks and merchant accounts

[1] https://stripe.com/

Reply on news.ycombinator.com