

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

Ladies and gentlemen,<p>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.<p>* In essence: how do you organize billing in your system?<p>* How do you keep track of who has paid for what?<p>* What do your database tables for this look like?<p>* Do you bill all customers on the same day each month, or a few each day, depending on when they signed up?<p>* 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? :)<p>* In what way do you notify your customers about the montly payment taking place?<p>Thanks a lot for your input.
======
Travis
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.

~~~
wilhelm
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:

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

------
canterburry
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?

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

~~~
wilhelm
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:

