Ask HN: How do you organize the monthly payments from your users?
I've been working for the past few months on a web application I intend to release soon. The basic functionality I need is working well, I've tested it on real users, and the final thing I need to do before opening the doors is to get a proper billing system in place. I intend to go for recurring payments from each customer once every month, automatically drawn from the credit card they used the first time. I've got a test account from the payment provider I'll probably be going with and made some pretty forms, but a few issues are still unclear, so I'd like to hear what others are doing.
* In essence: how do you organize billing in your system?
* How do you keep track of who has paid for what?
* What do your database tables for this look like?
* Do you bill all customers on the same day each month, or a few each day, depending on when they signed up?
* How do you invoke the billing? Is it a completely automatic process, or does a human push a button? (Have you ever had bugs in the automatic process? :)
* In what way do you notify your customers about the montly payment taking place?
Thanks a lot for your input.
6 comments
[ 2.8 ms ] story [ 14.7 ms ] threadI bill customers on the day that they signed up. It's easier to bill Joe Smith on the 12th every month than to explain to him why his first months bill was smaller than the others (pro-rated approach).
You should definitely automate this. Try to bill, if it works, send an invoice via email. If it fails, send them an email asking them to update their payment information. Now, an automatic process could have bugs in it, but so could having a person push a button. It's the code to execute the charges that matters, not how it's invoked. That said, the first few times it happened I'd be danged sure I was watching in realtime (and maybe require human intervention to prevent a bug from affecting ALL my customers).
You aren't saving credit card numbers, right? I use authorize's CIM to obtain a reference to that cc file. You don't want to go through PCI compliance for storing cards, or even risk massive fraud due to a security breach. It's worth the extra money.
No, I won't be storing card numbers. I'll just store a hash I can use to bill again. The PCI certification is cumbersome and costs money I don't have yet, and I'd really prefer if those numbers are on someone elses's server - just in case. (c:
What we do is as soon as the user shows interest in the subscription (i.e. clicks the relevant link), there is a redirection towards PayPal where a recurring subscription is initiated after the whole transaction is processed.
Paypal then takes care of the rest. Its API reports back to the software and if someone's card is declined or anything like that, their subscription status changes. This way we do not worry about the subscriptions themselves.
Several things to note:
1. The software handling this comes within the software we use. Integration then is something that others have done and we do not worry about this. 2. Refunds are processed manually 3. Increase in the subscription price is a pain since the old users (the ones that paid with the old price) will continue to get charged the old price using this model. The recurring transaction from PayPal does not account for increases in prices. Therefore you will need to cancel those subscriptions manually and let the users resubscribe.
Customers are never emailed but everyone is well aware that these charges are taking place. We also use eSupport from Kayako which solves a lot of problems in customer support (you will need something like that if your volume is going to be high).
From another company that I had, we were using the ModernBill software. It handled a lot of payment processors and it was emailing customers. The processing was automatic on that one so in your case I would be inclined to use this piece of software.
I hope the above helps.
I don't typically email invoices or receipts, but when customers request it I setup a Blinksale recurring invoice to coincide with their billing cycle.
Authorize.net CIM is great if you need to bill irregular amounts or at irregular intervals, but it requires an outside trigger to initiate a transaction. The Authorize.net ARB service is more self-contained and works for my needs.
Every couple of months I reconcile my accounts spreadsheet with my recent charges to be sure that no accounts fall through the cracks.