Re:Ask HN: Developing a recurring payments system, what do I...
by ericb on Friday October 22, 2010 @12:13PM
(#1820195)
What made you not use Braintree's automated billing? How long do you think it took you to implement from soup to nuts?
Re:Ask HN: Developing a recurring payments system, what do I...
by pavel_lishin on Friday October 22, 2010 @12:19PM
(#1820223)
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.
Re:Ask HN: Developing a recurring payments system, what do I...
by ericb on Friday October 22, 2010 @12:32PM
(#1820287)
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
edit: I also found this plugin:
http://github.com/maccman/saasy
sample apps: 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.
Re:Ask HN: Developing a recurring payments system, what do I...
by citricsquid on Friday October 22, 2010 @12:46PM
(#1820354)
To clarify your first point, do you have a separate process that runs per customer so that if the process fails and has to be restarted (auth failure with merchant etc) only that one customer will be restarted?
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.