[Resolved] Credit cards on the site...?

vaska

Hi everybody,

I've been trolling around everywhere trying to understand how best to accept credit cards on a website.

It's not a shopping cart or anything too complicated, I just need to setup a system for people to make contributions to a site. Paypal, however, is not an option (because people have to sign-up).

Some basic questions:

If I used md5 to encrypt a credit card number on a site there is no way that a hack could extract that information correct?
Is it an unnaceptable and unsecure practice to simply have the credit card information sent to a processors email account (who then calls it in via the phone)?
I would like to use Verisign or something like that, but the client doesn't want to go there and I can't steer things that direction. Does anybody know of any other good, inexpensive, reliable services other than Paypal that don't require a user to sign-up (meaning, people just enter their card and it's processed without them having to go through some registration process)?

Thanks for any tips...Jv

mtimdog

If you encrypted with md5, you couldn't get the credit card number either!! One way or another you'd end up doing it with a keycode/keypass.
Yes and Yes. What happens when someone reads your e-mail? If you're sending it through mail, you mise well just have an e-mail link like

<a href="mailto:me@me.com?subject=Donation from site">Click here to send me your credit card # and amount of donation</a>

(I don't recommend this).

I would highly recommend using SSL. As far as cc processors, you still need to shop around to find one that fits you weighing in how much they take off your profits for monthly fees, per transaction fees and so-forth

authorize.net **
2checkout.com
paypal.com (-) (negative if that's possible)
ipayment.de

secpay.com
psigate.com
trustcommerce.com

there are plenty of others, but I took those off an osc page.

mtimdog

p.s. all of these require your client to have an account (I think 😉 ), but donators do not.

Erkilite

i wrote a donation script for a charity a while back using Card Services International and Linkpint (linkpoint kind of sucks). It was a simple php setup.

https://host27.ipowerweb.com/~fortheki/onlinedonation.php

there is this page, an error page, and a success page.

there are special html tags you enter then post all the info to the payment gateway link. (this part is hidden so you can't see it in the source).

it's like $50 a month for the merchant account and gateway i think. plus whatever percentage you loose for the processing.

DO NOT USE md5 to encrypt the credit card, it is NOT safe.
see-> http://www.phpbuilder.com/board/showthread.php?s=&threadid=10242570&highlight=md5

Your better off encrypting the card and sending it into a database to be retrieved later, than going over email. (i don't recommend either of these methods). email is too easy to intercept, you shouldn't store the entire credit card in a db, maybe just the last four digits at most. The card should be processed immediately so you don't have to store the card number anywhere.

AstroTeg

I was doing the math on this 6 months ago - it may have changed a little by now...

Basically, if you're doing more then 30-35 transactions a month, then PayPal is not a good fit (their transaction costs will eat you alive). But if you are doing less then 30 transations a month, then getting the merchant account, SSL, and hassle of creating your own cart will eat you alive (or just be really expensive). Just something to ponder...

A rule I go by when it comes to credit cards:

Never ever never store the credit card numbers. I personally wouldn't even consider trying to encrypt them. I'd just rather not store them at all. Also spend as little time handling the card number as possible (don't be storing it in a hidden form field and passing that all around, for example). Collect the card number, then the next action should be to submit it to the payment gateway and listen for a success/fail response.

If you have to store the card number, I'd recommend only the last 4 digits (the first 4 are somewhat useless depending on the card type). If you have to do re-occurring payments, then setup a "subscription" payment with the gateway and the gateway will handle charging the card each month or time period.

MD5 is one way - so you encrypt the card number, how are you going to unencrypt it? I don't think MD5 is what you want for this.

Email is not secure. Email gets transmitted in raw text. The email will hop along many email servers to get to its destination. At every stop along the way, its possible someone could be packet sniffing or just a nasty server administrator browsing the emails coming and going. Its unlikely it will happen, but its very possible. If you absolutely have to do email, then encrypt it. PGP and there's another one which I forgot - something like GPG should do. A good email client will be able to handle the messages (Moz/Thunderbird appear to but I haven't tried).

As for other services, the only thing I can think of is you build your own. But then you get into coding the interaction with a payment gateway and some server side credit card validation. Its not difficult, but not something I'd recommend for the novice developer (unless they have a really good book or someone to mentor them). The payment gateway may even have you do test payment validation tests and you send the results back to them. Or they may actually access your payment page and do their own validation. Usually they won't let you go "live" until they're happy you're code handles interaction with their server (notice they're NOT going to test your shopping cart to make sure its behaving - just the interaction with their server).

vaska

Isn't there an out-of-the-box solution that is perfectly customized, tailored, designed, skinned, etc to meet my every need and also gives me personal counseling? :p

It sounds like they have no choice but you go through a third-party service - makes things more complicated (no biggie) but gives me some piece of mind as well.

Thanks for the tips...Jv

andymoo

if there's no sign up how can you be sure you won't get a high rate of chargebacks?

the more personal data you can collect from a customer before you take the card details the better validated they are, the better your data is the less chance of being stung with chargebacks

just something else to consider when doing card clearing