Online Registration

[Kim Crosser]

To answer the "profile" question, I guess I made some assumptions (any of which may be incorrect).

Usually, information captured for forms like this is stored locally on the user's machine in the form of a "cookie" (of course, it could also be stored on a server, as well). Cookies (or server accounts) are often indexed/referenced by the user's login account on the machine.

Some (not many, but some) drivers have multiple cars and/or run in different classes in different events (AX vs. DE vs. TT, or even X cars).

If the profile information were indexed (or authenticated) by the user's login, then there is no easy way for the user to have multiple car profiles. If the profile is stored on the server, then the user must authenticate to the server by some means (other than local login) to select the profile.

Thus, IMHO the simplest way to provide multiple profiles is to explicitly allow each account to have more than one profile and to be able to select from a stored profile.


Re: PayPal - after hearing the comments on the MC/Visa payments, it may well be worth investigating PayPal linkage. Many very small companies doing far less than a few thousand a month (70 drivers * $40 = $2800) have found PayPal worth it for the elimination of credit card billing issues.

[kary]

Kim, we have all the information about a driver and the cars they have driven in the results database. Likely this will turn into the registration database so looking up what car combinations they have had is a no brainer. Cookies are really not the way to go with this since people do move around on different computers. I work with three different computers everyday so having cookies would be not updated at all locations. Using the server to store this information is the way to go here.

Regarding paypal, they are one of the worst in terms of cost per transaction out there for a merchant. I researched this when I started group 9 Motorsports and found a credit card gateway that was far less expensive then paypal. I would not recommend them at all. I do not think we need on-line transaction procesing anyway, we just need to accept a form of payment that can be charged later as was pointed out earlier.

[Kim Crosser]

I will certainly defer to experience with PayPal. I have only used them as a consumer.

Re the profile - storing the profiles on the server is certainly fine, but if (here goes another assumption) a user logs into the on-line registration system similar to the forum or other sites, the registration system would still have to explicitly handle multiple profiles for each user, or each user would have to have multiple logins (and remember which one to use for each event).

This was the question Alan originally asked about multiple profiles. While you could certainly implement this via multiple login accounts, it seems like it would be nice to be able to track common user information across events, regardless of the specific vehicle/class entered in any one event. Not critical, just nice.

[MikeD]

I'm not sure how Alan is going to design this system. But I'm on the same side of the fence as Kary in this. The more bells and whistles we add to this system to try and make it the King Bru Ha Ha of online registration system the longer it will take to implement. The longer it takes to implement the more we risk losing volunteers to get it done.

I would suggest that credit card information be stored in the database until after the event. And then manually processed as they are now. This is no harder on the registration staff than the current system. Correct?

[Robert]

Agreed. It's cheaper to wait anyhow and only put through the charges you actually want to bill so that you never have to process refunds. Full card processing can always be implemented later if it's deemed valuable. At that time, a complete survey of what's out there in terms of online processing can then be done.

[Jeff Grow]

I think you should start circulating a document which flushes out what the desired attributes of an online registration system looks like.

The bigger question is what the business process looks like - how to manage the event 'inventory', back-end membership database, customer service features, transaction capture, automate customer receipt email, transaction processing security, etc. And then event masters and registrars need to be able to efficiently integrate their processes with the data.

Payment processing is the least of the concerns (though I agree w/ Kary about PayPal). Even if the registration payment is not automatically processed online via transaction processor, you can't send credit card information over an unsecure link. So the server has to have SSL certificates....

[Pete Millikin]

This reminds me of my workplace, a good idea gets floated and, with good intentions, expands into a bigger, all encompassing project which reduces its chance of success. Here are a couple of suggestions:

1. Do some high level planning and design about what we really want as Jeff suggested.
2. Break the project into logical pieces and a plan so we can have early success while having a plan for the eventual end product. On line registration is the obvious first piece, but downloading into the timing system /results database / payment process are features which may yield big benefits to the club behind the scenes. It doesn't have to be done all at once.
3. Maybe we can benefit from the wheel that has already been invented. If NASA or others already have a functioning system, they might give it to us to adapt if we share improvements with them. I doubt NASA sees PCA as competition and it would be worth a phone call to see if an arrangement can be worked out.

I'll volunteer to help but keep in mind I'm a CPA and financial guy not a techie.

[Kim Crosser]

I'll talk to whoever has needs/suggestions, but I need to know who they are (names, emails, phone numbers etc). Anyone with suggestions, please post them here.

Be careful what you ask for, you might get it!

Alan asked for suggestions, I gave suggestions - note key word "suggestions". Alan should feel completely free to disregard or consider any or all suggestions made by anyone.

If I were the implementer, I would be very interested in getting a large selection of suggestions, and then would decide which (if any) I wanted to implement.

As someone involved in managing large-scale software systems development and deployment, it is a LOT easier if you understand the global/long-term requirements (or even wish lists) when you start developing - even if you decide to only implement a small portion - than to later discover additional "suggestions" that require core redesign.

There will always be some amount of "gee, wouldn't it be nice if..." items that arise after deployment, but having the wish list at the beginning at least gives you a chance to make design decisions with the possible future in mind.

I applaud Alan for volunteering to look into this. I "suggest" that Alan can choose for himself which suggestions to consider and/or incorporate.

The registration payment issues are another matter - I think this has clearly been stated in these posts that on-line payment is NOT desired at this time. If on-line payment isn't done, then don't we still need to fax the credit card information with signatures? Can we go with some form of "credit card and signature on file"? If not, and a faxed credit card form is still required, then is on-line registration a duplicate effort. (Yes/no?)

--------------------------------------------------------------
"One should respect public opinion insofar as is necessary to avoid starvation and keep out of prison, but anything that goes beyond this is voluntary submission to an unnecessary tyranny."
Bertrand Russell

The views expressed in this post are those of an unreasonable, egotistical, curmudgeon, and generally reflect the lack of respect due those who disagree with me.

[ajackson]

Kim is correct, I want as many suggestions as possible so I have a good idea of the big picture. I don't want to finish something that won't work for us because I didn't think of something major that it needs to do. Also, there is a certain amount of design decisions that I can make now that don't implement features, but makes them easy to implement in the future.

Right now I have a certain subset of the features that I think is necessary for the system to work at all which I will implement first. Once we have something going, it will be pretty easy to add features as we go to make it more useful.

Payment, for now, will be just storing credit card numbers (in a secure way of course) and payment processing can be done manually. I *know* that you don't have to have a signature to process a credit card, every online/phone store depends on it.

Keep the suggestions/comments coming.