6 ms·

Ask HN: Developing a recurring payments system, what do I need to consider?

• bediger 16y ago
  Things to think about: 1. Keeping the credentials (account number, name, telephone number, credit card number, routing number and account number, etc etc). You may have legal duties to perform certain things, or to delete them every so often. 2. Retries of failed payment authorizations. The ACH and credit card systems ARE NOT THAT RELIABLE. Your code will need to take account of network failure (failed to contact Paymentech or AmEx) vs a declined payment. Not the same things at all. You need to have the ability to retry an authorization. 3. Your own software failures can leave a "batch" of payments in an inconsistent state. The dangers here are double-billing a human, and on the other hand, not billing a human. In one case, your clients cry out, in the other, you miss some money. 4. Give your clients the ability to cancel a scheduled payment right up to the deadline, but don't let them schedule a payment too close to the deadline. Horrible race conditions that are hard to imagine ensue.
  • pavel_lishin 16y ago
    Unless you know exactly what you're doing - and if you're asking this question, you don't - don't store credit card numbers at all. There is no justifiable advantage to doing this when Braintree/Authorize.net/etc provide much more secure ways to make arbitrary charges against a card.
  • henrikschroder 16y ago
    May have legal duties? If you wish to handle credit card details in your systems, you must pass PCI compliance, and this is something you really, really do not want to do if you're a small company.
    • HNer 16y ago
      This is correct, I offer PCI complaince tools and advice, for recurring billing, you will need to have pci scanning on your servers, if your hosted and not doing sys admin yourselves or if you dont have sys admin skills it's going to cost you dearly. Basic advice, use a linode, get a sys admin who knows about pci compliance, set up pci compliant approved server, check with scanning software, we offer it for 200 GBP which includes the SAQ wizard which will save you days. pcicompliance.org.uk, nightmare process. Best advice, just starting, use Paypal...
      • epochwolf 16y ago
        I thought VMs didn't qualify for PCI compliance unless you had the physical hardware the VM runs on.
• there 16y ago
  i implemented the recurring billing for http://corduroysite.com http://corduroysite.com with braintree and ruby activemerchant. i did the recurring billing manually rather than using braintree's automated billing. i'm storing credit card numbers and addresses in their secure "vault" and just store the associated token with each customer record for pci compliance and added peace of mind. some things to consider: - store the last billed timestamp with each customer record, don't just sweep through each customer and try to bill for anyone with a billing date of today. if something goes wrong in your billing script halfway through, you don't want to double-bill those first customers and don't want to forget to bill the second half. when billing auth failures happen, you want to retry those failed customers the next day. - don't be quick to blame the customer for their card not going through. even if it is on their end, it might not be their specific fault, and may be their credit card company, someone else using their company card, etc. for corduroy, it emails the customer with a notice saying the charge failed but it'll retry for a week or so before anything bad happens. it sends the error message from the credit card processor, though many times they're hard to decipher exactly what's wrong (usually a billing address change though). if the card continues to fail for a week, the customer's site is put into a disabled state where the customer's staff users can't login without fixing the problem, but none of their data is affected.
  • ericb 16y ago
    What made you not use Braintree's automated billing? How long do you think it took you to implement from soup to nuts?
    • pavel_lishin 16y ago
      We have several projects (non-Braintree, we use Authorize.net) where the amount billed per month varies. Authorize.net's automatic recurring billing system doesn't allow you to change the amount in between pay periods, so we had to do something similar to what the original commenter said. Basically cron running a script that bills whoever needs to be billed for the proper amount.
  • ericb 16y ago
    For anyone else interested, I found this while googling for ActiveMerchant sample apps and will probably pick it up. Looks apropos. Thanks for the feedback! http://peepcode.com/products/activemerchant-pdf http://peepcode.com/products/activemerchant-pdf edit: I also found this plugin: http://github.com/maccman/saasy http://github.com/maccman/saasy sample apps: http://github.com/linoj/saasramp http://github.com/linoj/saasramp If anyone has looked at these or others, I'd love to hear thoughts on them before I dig in.
• grok2 16y ago
  You need to worry about everything mentioned as a feature at https://cheddargetter.com/features https://cheddargetter.com/features. No, I am not associated with them, but I have been researching subscription billing and found CheddarGetter's list of features a good template to compare other providers. Why are you considering Braintree? They seem a little more expensive for starting out (though probably they are more robust and have better support than the rest -- Spreedly/Chargify/Recurly/CheddarGetter/Vindica/Zuora/Aria are some I researched).
  • ericb 16y ago
    I haven't looked exhaustively. After the chargify free account fiasco, I'm staying away from them. I would have started with the free account there and moved up, but now I'd be too nervous to look at them. Not familiar with the others, but I'd be nervous to go with anyone who doesn't have serious momentum, or size in their favor, as I don't want to rewrite my code if a startup fails or deal with stranded account information.
    • vietor 16y ago
      That happened to my co-founders and I on our previous product (the one visible at the website in my profile). The only thing our payment provider ended up being serious about was getting acquired. We had to change providers about a year after we launched, and it ended up costing us nearly half of our early customers.
      • ericb 16y ago
        Interesting that the data didn't transfer over to the acquiree. Is that a rule in terms of PCI I wonder?
        • vietor 16y ago
          My understanding was that it was a low-dollar tech acquisition. The acquiree had no interest in existing customers beyond the fact that they validated functionality.
• Terretta 16y ago
  The intellectual property for minimizing charge backs, preventing fraud, and handling exceptions and edge cases--knowledge built up over handling millions of transactions--is generally not worth relearning. Then there's the outrageous business crushing liability if something with CC data goes wrong. You're usually better off keeping your brainpower focused on your app's differentiators, and leaving the recurring billing part to someone whose brain has already been sucked down the black hole of gateways, processors, and PCI compliance. Chargify, Spreedly, and CheddarGetter come to mind as SaaS billers discussed frequently here. (If your pain tolerance is higher, PayFlow Pro has tremendous institutional knowledge under the hood from handling over $100 million USD daily, despite changing corporate owners several times. Also compare Authorize.NET.)
  • flacon 16y ago
    "gateways, processors, and PCI compliance" These are not that complex and should be well-understood by any would-be entrepreneur. We are writing our own recurring billing system right now for our startup www.wellhubstudios.com, using Auth.net CIM. Auth.net even offers recurring billing themselves. Another obvious issue with the services you mention such as Chargify et al is that they charge a higher rate for each transaction than most other Merchant Account providers, sometimes 1-2% more per transaction which, if your trying to run a viable business based on margins it is something to greatly consider. The Transaction fee we got was ridiculously low compared to what these "recurring billing" apps (which surely will reduce your headache) are offering. Off to make some money.....
    • Terretta 16y ago
      To say the ins and outs of card processing should be "well-understood" by any would-be entrepreneur seems like saying biochemistry should be well understood by anyone who wants to wear a Got Milk? t-shirt. How many stores write the software in their cash register? Who would argue that was useful instead of working on their product line? The would-be entrepreneur really should be doing other things with his time, and if the card processing percentage difference matters to the business model, hopefully the model is micropayments or billing itself, because for anything larger, there should be room and the entrepreneur better watch out for the much larger expense of supporting billing. Billing is rarely a differentiator, except when it goes wrong. On the other hand, if you're selling billing itself as a service, as I see your site says you are, then sure. You're competing with Chargify, Spreedly, etc., for a more targeted vertical. So sure, billing is your product. In that case, agreed, it needs to be well-understood.
• drm237 16y ago
  You might want to check out http://railskits.com/saas/ http://railskits.com/saas/. Yes it actually costs money, but consider what your time is worth.
  • poink 16y ago
    Just bear in mind that the SaaS Rails Kit has been around for quite a while. I don't know if the features page lags behind the actual code, but: "Compatible with Rails 2.3.8"
    • inm 16y ago
      I enquired the other day about Rails 3 support - he's working on it and expects to release it in the next few weeks.
      • stympy 16y ago
        In fact the rails3 release is mostly ready. There's a rails3 branch in the customer git repo that will be merged into master in the next week or two.
• damoncali 16y ago
  Just use Braintree's API with their vault. It's as easy as it gets without going with Chargify/Spreedly/etc, especially if you're just doing plain vanilla recurring billing.
• rmoriz 16y ago
  1. It's about PCI compliancy 2. It's about running a cronjob/sending invoice mails 3. It's about fancy features (up/downgrade/trials/coupons/variable fees) 1. You will not be able to collect raw credit card data without having a PCI certification. This is easy to get by filling out a questionaire if you have only a few thousand transactions per year (below 200k iirc) and it's about a ~1500$ fee (iirc). PCI compliancy limits your choices of payment gateways and inhouse software solutions: a) you can use a payment gateway that supports recurring payments: they save your customer's raw data and provide you a token where you can bill future charges. This is the simplest way, does not require a PCI certification of you but has a huge vendor lock-in. If ActiveMerchant (e.g.) supports your gateway of choice AND recurring functionality WITHOUT dealing with raw credit card data: Go for it, it's the easiest way. b) you can chose between more payment gateways by using the various 3rd party services that are PCI compliant (recurly.com, spreedly.com, chargify.com). Of course this is another vendor lock in and costs money. 2+3) This is about dealing with subscriptions and is primarily not credit card dependent. Of course you want to deal with chargebacks (you don't want to but this will happen) but usually the hardest parts are: up/downgrading within a paid period. Everything else is easily done, imho no special "kits" are needed UNLESS you're busy or lazy which is sometimes ok. TL;DR If you think that your MVP and core functionality needs more love than a fancy payment system, go with one of the services (recurly, chargify … or even paypal). If you business works, you've the time and money to upgrade to a better/your own solution/pci compliancy. It usually does not pay off to write your own billing system unless you already have paying customers :)