[H-SASIG] Payment database

[Russell Stuart]

On Tue, 2010-05-04 at 22:39 +1000, Raymond Smith wrote: 
> On 1 May 2010 23:14, Russell Stuart <russell-humbug at stuart.id.au> wrote:
> > Greg and I sat down one night and looked at what be needed for Humbug to
> > accept membership payments via they web.  We specifically limited the
> > scope of the project to just that.  This is what we came up with:
> 
> Seems like an impressive amount of scope remaining :-) It seems
> reasonable though. I have a few thoughts/comments.

This post is actually me checking off a todo item from the SysAdmin
meeting.  In order to understand where I am coming from, you need a bit
of context, which you won't have if you were not at the meeting.  Matt
took minutes, but I don't think he has posted them as yet.

The first bit of context is we had a general discussion about membership
databases.  It turns our two groups[1] were working on different aspects
of this.  One was Stephen/James and the other was myself and Greg.  But
Greg is involved only because he refuses to become a financial member
until I do this, and so by way of retribution I forced him to review
what I had written before I posted it.

In an effort to get some cooperation between the two groups we decided
at the meeting that both groups should post a database schema of what
they have done so far.  Hence my post. 

> First, I wonder if it is worth looking again at LA's MemberDB. I know
> this has been looked at before and people were none-too-happy with it
> -- I got the impression this was mostly because it was hard to
> install/configure? It looks like it would do almost everything in
> scope except for the Payment Engine integration. That would be a
> useful enhancement for the community!

The second bit of context is what I am trying to achieve.  In simple
terms it could be stated thus: to get Greg to pay his membership dues.
Greg will probably argue with that and say the real goal is to allow
memberships dues to be paid online.  Regardless my goal is _not_ a
membership database.  My WAG[2] is the Exec spend roughly 2 hours a year
doing membership stuff.  If the justification is saving the Exec time, a
membership database isn't worth effort.

However, Humbug does have a number of non-local members.  We make them
go through hoops to maintain their financial membership.  That is
something worth doing. 

> Second, on the Payment Gateway side I would take a look at Google
> Checkout, PayMate, and PayPal.  This is going to be a lot easy, I
> think, than trying to establish yourselves with an Australian Bank. It
> may even be not much dearer when you look into the total costs of
> processing credit cards directly.
> 
> You might also like to consider NOT supporting credit-cards at all but
> supporting EFT with a magic number provided by the membership
> registration process. EFT is likely to be cheaper for you than credit
> cards and saves the integration nonsense. On the downside, you have
> the possibility of people screwing up their payment numbers and you
> cannot automate receipting.

I looked at a few payment gateways, including all those you list above.
PayPal has funny requirements we probably don't meet, Google Checkout
doesn't support Australian vendors.  PayMate isn't bad - its only
downside is it accepts payments from a restricted set of countries and
can be a little expensive.

There are others you didn't mention.  There of a whole gaggle of them
based in Russia.  On paper they are ideal.  Their fees are low, that are
happy to deal with anyone and accept payments for anything, and they are
simple to use.  Unfortunately Greg has religious objections to dealing
with Russians.  There is ProPay, but they have monthly fees, and
MoneyBrokers who is looking the best so far.

> Third, on the email alias front it would be nice to continue
> supporting multiple aliases per member (as we do now for a few
> members). This would also be a convenient way to manager president@,
> etc.

Really, email aliases should not be there at all.  They are out and out
feature creep.  As for multiple email addresses - mw view is if people
want them they can be handled as they are now: manually, by the exec.

The third bit of context is how much effort I was planning to put into
this.  The answer is "not much".  I don't believe I have a graphic
design neuron in my head, so expect to see the ugliest web forms you
have every laid eyes on.

The fourth bit of context is what all this would be written in.  My
original plan was for "raw python", but it turns out we have a django
hacker in our midst.  That would be Stephen, our sasig leader.  Everyone
at the meeting was happy with Django, so Stephen is setting up an
instance of it on Excalibur.


[1] This is using  a very loose definition of the term "group".

[2] Wild arsed guess.