Ask HN: How do you organize the monthly payments from your users? | Hacker News Reader

Ask HN: How do you organize the monthly payments from your users?

16 pointswilhelm6 comments

Ladies and gentlemen,

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.

I'll avoid the database section, as that's a bit involved.

I 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.

Thanks for your input!

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:

I use Authorize.net with Automated Recurring Billing (ARB). I only intervene to handle exceptions like an expiring card or failed transactions. I bill each customer each month on the day they signed up to avoid explaining pro-rated transactions.

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.

Has anyone ever had the need to utilize more than one payment processor? I.e. Authorize.net and PayPal + others? If so, what were the challenges with integrating with multiple providers?

In one of my companies we use a subscription model similar to the one you have described above.

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.

Indeed it does. Thanks a lot. I'll check out the names you mentioned. I don't have any volume yet, but I might find useful inspiration there. (c:

Reply on news.ycombinator.com