Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

Parent Full thread

My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers.

This strongly suggests that I should not be writing billing code, ever.

You need a bunch of pieces to do billing. I use Paypal Website Payments Pro to physically charge people's credit cards, and Spreedly to tell them when to do it. I interact with Spreedly through a REST API that is wrapped with a Ruby gem. My entire interaction with them is one form, three model actions (which handle account creation, status change, and expiry), and a callback for when customer status changes. This took me a few hours to implement, once. Aside from a bug on my side (not charging Mastercards because I am illiterate and failed to read their documentation correctly), it has been pretty flawless.

This seems to come up way, way too often. Would anybody be interested in a blog post about how to do it in a practical, pain-minimizing manner?

It doesn't take much to improve the billing experience over sending someone to an external website, to pay with payment pages that are minimally customizable to match your site.

You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.

I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.

I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.

Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.

dan, because you are holding the CC information on your site and POST'ing it out to external services at authorize.net, did you have to do any work for the "PCI" compliant/privacy stuff I see?

I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.

That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.

You're right, doing it yourself requires PCI compliance. I've done all that work and my servers get a compliance scan every quarter. That's just tangential to patio's argument (that it's technically difficult to offer a better billing experience than an outsourced service).

Thing is, everything PCIDSS says you have to do when payment data passes through your servers is security 101. If you're not already doing 90% of these things, you're just waiting to be hacked anyway. Instead of thinking of it as a burden for payment processing, think of it as something every professional online business should have been doing anyway.

"PCI Compliance" is like keeping a drivers education book in your glove compartment. It's good because every once in a while you find it and it makes you think about safety. Unfortunately it does absolutely nothing to actually make you safer.

Lots of bark, absolutely no bite. There is not a single case where a bank will shut you off and stop getting your processing fees.

I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.

This is one of those instances where I wish everyone (specifically patio11) could see how much karma bryanh's comment has.

I didn't mean to upvote you, I misclicked.

I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.

As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.

Do the credit card numbers ever travel via your server? Even temporarily in memory? If so you are liable for PCI-DSS section C, which is a LOT of hoops to jump through.

Spreedly saves you from that.

It took us a couple hours to be in compliance with section C. If memory serves, we dealt with a vendor who did a scan, made us install AV software on our Linux boxes, and one or two other minor process adjustments. It wasn't a big deal.

Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)

Cost: approximately 3 man-days.

Benefit: currently sitting at approximately 1 man-year/year and growing.

It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.

As I understood it you have to have written procedures and policies, with fully secure change control and logging for section C ?!?

You need a written security policy, but that was pretty close to pro forma. The compliance firm wrote us one which we disseminated appropriately.

You basically just need to follow some reasonable security standards. Firewalls, ssh/ssl admin terminals, no shared credentials, and then follow a basic security policy.

Thanks, that sounds a lots less complicated than the advice I was given.

The only situation where I can imagine it being a pain is if you aren't already following good security procedures.

If your ops/DevOps guys are experienced pros, they're probably going to be pretty close to compliant, just out of habit. That said I guess it's not terribly hard to envision a scenario where there's no firewall, bad user access controls, and a host of other crap that could be painful to fix if you only have junior-level ops talent.

I don't understand how Spreedly is somehow providing you a "return". They sit on top of your payment gateway so you pay everything you would've paid withluan in-house integration, plus Spreedly's fees. Coding your own subscription billing is a one-time thing as well. Where are you saving money?

It may be a one-off cost but writing a billing system is still a few weeks work. Pro-rataing on upgrades/downgrades, support for one-off overage fees, refunds, credits. Plus dealing with the fallout when you get a decimal place wrong in a tax calculation and accidentally charge a customer a hundred times what you were supposed to (guilty).

One of my clients paid $700 for Spreedly kickstart plus their percentage transaction fees, plus a couple of hours for me to integrate it. Significantly less money then three or four weeks of my time to write a billing app from scratch.

Maybe the math works out like that when you bill four weeks for a two day job. Startups can and do find programmers that write robust billing code with those features in a day or two. I've done it more than once. I run both ecommerce sites and subscription web apps -- the billing code handles upgrades, downgrades, pro-rating, one-off overage fees, refunds and credits. Once you've done it once, doing it again and testing for another site is a few hours work.

I was specifically noting that I was getting a return by not using Spreedly, as compared to having used it. My apologies if that was unclear.

Perhaps point values should be shown for your post and all of your children, so you can see what people think of the responses to your post (and the submission author can see points for everything since he's the essentially the root node).

This may have been recommended in the other thread, but I don't recall it.

I don't know about the GP's project, but I implemented my own for historious by using PayPal's recurring payments feature. I store the user's subscription expiration date in their profile, and when the PayPal rebilling notification comes, the date is just reset by X days, which is stored in the PayPal "extra data" field (signed, of course).

Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.

Just in case anyone is wondering, the parent comment earned 26 points (which is one of my highest point counts to date).

Reply on news.ycombinator.com