views:

128

answers:

4

I was given the task of creating a registration page for an upcoming church retreat. Design-wise, it will consist of fields for name, sex, phone number, email, and grade. We need a way for the end user to put their credit/debit card info and have it charge them for the retreat.

After some searching I found that Braintree offers a good service (37 signals likes them). The down side is that I have no clue on how to implement this sort of system into my site. So we are going to apply for a merchant account using their service. I also found documentation on how to implement it with PHP.

My question is, do I have to do anything else? I've always heard of https but I don't know if that's something I should implement. What security measures should I put in place? Should credit card numbers be stored in a database as plain text or encrypted? Has anyone used Braintree and can let me know what to expect after getting a merchant account?

Edit: I was looking through the PHP documentation code and was lost at this:

Braintree_Configuration::environment('sandbox');
Braintree_Configuration::merchantId('your_merchant_id');
Braintree_Configuration::publicKey('your_public_key');
Braintree_Configuration::privateKey('your_private_key');

I'm guessing the environment is set to sandbox for testing but is a merchantId provided to you after you make an account? Also, I have no idea what a public or private key is.

+3  A: 

You should not and cannot store any credit card information in your database. Mostly any payments service like Braintree will handle entering sensitive data, HTTPS and all other things. All you need to do is to give correct request to payment gateway and process answer.

Māris Kiseļovs
You can store credit card information in your database as long as it is encrypted and follows PCI standards. It's still a bad idea, though, and should be avoided.
John Conde
+8  A: 

Hire someone with ecommerce experience to do this. If you don't know what https is then you shouldn't be handling sensitive information like credit card numbers or processing payments. The implications of a poor implementation are huge and lives can literally be ruined from it.

Do not store the credit card information in a database. This is a bad idea for numerous reasons listed many places on the Interwebs. PCI Compliance being the most commonly cited one. It is a really, really, really bad idea.

Https, by the way, is the secure version of the http protocol and allows for http traffic to be encrypted between clients (usually a browser and server but not always). It is implemented by the installation of an SSL certificate.

Your best bet is to use a merchant account and a payment gateway service like Authorize.Net's SIM API which handles the order form for you. That way you hand the handling of sensitive data to them.

You may want to read Merchant Accounts 101 and Ecommerce 101 before proceeding. Disclaimer, I wrote those articles.

John Conde
DaveE
Thanks for the honest answer. I'm reading as much as possible at this point for fear that something bad could happen. Thanks for the articles very much as well. I won't make anything unless I know exactly what I'm doing.
NessDan
+1 to John. The questions you've asked, NessDan, make it clear that you're not capable of properly doing the task. Just stating the facts, here. I wouldn't be able to do it either. Best to leave it to a professional rather than find out Aunt Maud "bought" an island in the Caribbean!
Andrew Heath
We (Braintree) have a list of companies that have integrated with us before and might be able to help: http://www.braintreepaymentsolutions.com/gateway/integrators
dan-manges
+3  A: 

A second reason to consider a site such as Google Checkout, Amazon, or Paypal is because the big merchants charge a set fee by the month plus transaction fee. If this is a one-time deal, the registration fees aren't that significant, or you don't plan to use it year-round, it's likely not worth going this route, even with a professional doing the work. I do a lot of work with quite a few smaller non-profits and the only way they can afford to do merchant accounts is via grouping of resources...but that brings up several tricky accounting questions.

Even easier than doing all the work yourself, consider a simple online registration site such as Active.com (or many multiples of others out there--I'd bet there's even one specifically for church groups) Their business is online event registration, and they do this for hundreds of smaller parks and rec type registrations, so they certainly would have the capability to do something like this. Trust me, having built several registration systems, there's nothing worse than the first bug popping up that makes 50 registrants show up unregistered or charging someone 4 times.

bpeterson76
That sounds like a terrible experience (the bugs and charging someone 4 times). Thanks, I think I'll go with what you're recommending. Just so I'm clear, is it possible to to use Amazon, Paypal, Google, etc. while still having a custom made form on my page?
NessDan
Regarding "even one specifically for church groups": I believe that SimpleGive (http://www.simplegive.com/) does church registrations in particular. (Disclaimer: I help out with a bit of their web development.)
Josh Kelley
Ness, indeed, the payment systems all basically work the same. Send them the required info via a webform, get a response back. Each has its own plusses and minuses such as how long they "sit" on your money, what information is contained in the response (a simple yes vs details such as transaction response) and backend interface.One more thing I forgot. For anyone really bent on doing their own online reg, this has worked well for Scout groups I work with: http://extensions.joomla.org/extensions/calendars-a-events/events-registration/2037 Note that it requires Joomla.
bpeterson76
+1  A: 

Unless there's some good reason for you to roll your own, use a third-party service to handle registrations for you. Among the others mentioned, some of my friends who put on shows and improptu classes use eventbrite.com and brownpapertickets.com

Both will tack on a small service fee

pborenstein