Hi, I'm new here, but I was wondering if anyone could give me some advice, here's my situation:
I help run a small record company's website. We currently have about 15 products for sale. As I've had it set up, it's just a really messy javascript that totals everything, adds shipping and passes to PayPal, or prints out an order form. We no longer want to use PayPal, because we now can accept credit cards. We have a merchant account, but we didn't get a payment gateway, so we will need to access the cc#s online and enter them manually.
I've been looking around for a simple PHP/MySQL e-commerce solution, and frankly, I can't find anything that is "simple". I downloaded and installed PhpShop, and while it generally suits our needs, it is so buggy it worries me.
So here's my question: am I better off just coding my own solution? I know a bit of PHP and MySQL, I've made 1 or 2 small web apps. I am just concerened with security, we need to store the CC#s in MySQL, and I've heard this is somewhat risky (we do have SSL installed).
Can someone perhaps point me to some sample PHP code transmitting & encrypting CC numbers to a MySQL database?
Thanks for any help, I am sort of at my wits end with this.
ps: the current store is at http://www.pernicebrothers.com/store.shtml
The most popular PHP/MySQL commerce solution is OSCommerce (http://www.oscommerce.com).
Originally posted by drgroove
The most popular PHP/MySQL commerce solution is OSCommerce (http://www.oscommerce.com).
Yeah, I've seen oscommerce, but I think that's a little too "big" for what I'm looking to do. Small is the word here. Thanks, I guess I'm going to crack out my PHP & MySQL books!
I would use OsCommerce. Is it operation overkill? Maybe, but it will do the job and has risen as the cream of the crop. Also as your business grows, your site can as well. Not only look at what you need now, but may need in the future. If Oscommerce will do the work and has the possiblity for future expanded operations, might be the right job.
Okay I'll end my speech and give some "simple to use shopping cart" systems. Some of these are PERL/CGI and not PHP, but worth a look.
Do a more complete search @ www.hotscripts.com
Here is my list
Agoracart - nice easy to use with installer, PERL based and FREE! I have used it before in earlier version and have been impressed.
http://www.agoracart.com/
If you are actually going to use a merchant account / payment gateway - there would be no need to store the CC numbers. The gateway would handle that for you.
Originally posted by Corey Bryant
If you are actually going to use a merchant account / payment gateway - there would be no need to store the CC numbers. The gateway would handle that for you.
We have an offline merchant account, thus the need to store and retrieve CC#s.
I have actually written the shopping cart code, but I am getting suck on getting my dbs aligned. I wish i went to school for this stuff.
Ah Ok. The only "problem" with that - other than being against your merchant agreement / illegal according to Visa/MasterCard rules & regulations is that your CC processor could up your discount rate because you have more keyed transactions - increasing your chances of chargebacks. I have seen some companies raise a brick & mortar account to 3% because of this. Plus if they find out that you are doing an internet business account on a brick & mortar account - they could pull your merchant account & you would have a difficult time getting another one.
Originally posted by Corey Bryant
Ah Ok. The only "problem" with that - other than being against your merchant agreement / illegal according to Visa/MasterCard rules & regulations is that your CC processor could up your discount rate because you have more keyed transactions - increasing your chances of chargebacks. I have seen some companies raise a brick & mortar account to 3% because of this. Plus if they find out that you are doing an internet business account on a brick & mortar account - they could pull your merchant account & you would have a difficult time getting another one.
Um, wanna explain this to me? I didn't decide on the merchant account (nor am I the one administering). I am simply trying to build a solution to the problem. Why would accessing invoices over an SSL connection be against rules and regulations? I'm not saying you're wrong, but it doesn't make sense to me. Does it cost much to add a gateway to an existing merchant account? It'd be so much easier on my end since I don't know much about security and passing POST vars via SSL and MySQL.
Thanks!
Well there are two types of merchant accounts: brick & mortar & internet/telephone.
Brick & Mortar is card present, swiped, or qualified rate. This means the merchant has physically held the card, seen the card & hopefully even verified that John Doe was the owner. if there was a chargeback - the merchant would have the signature on the slip. And once the bank verified the sig, there would not be much the owner of the card could do (unless it was not his sig).
Internet/telephone is card not present, not swiped, or not qualified. I could call you up - give you a credit card number & you accept it. There is not way of verifying really that it was actually John Doe on the phone & him giving you his CC number.
Let's say the merchant that you have now has a rate of 1.55% (since that is what we offer). And he starts keying in CC numbers. This (depending on his merchant agreement) could be an extra 1.65%. So now that $100.00 transaction is costing him $3.20 (plus .25 for the transaction rate) instead of $1.55 (plus .25). If he did use the AVS (Address Verification Service) he might be charged a mid-qual rate of .85%, so that $100.00 would be $2.40 (plus .25).
You can get an internet account for about $175 start-up costs total. And the discount rate would be about 2.30%.
It is not accessing invoices via SSL - but if you are having your customers pay for anything via the net, you should have a internet/telephone (MOTO) account.
I hope all of that made some sense. Visa/Mastercard can be a big pain at times.
Originally posted by Corey Bryant
Internet/telephone is card not present, not swiped, or not qualified. I could call you up - give you a credit card number & you accept it. There is not way of verifying really that it was actually John Doe on the phone & him giving you his CC number.
I hope all of that made some sense. Visa/Mastercard can be a big pain at times. [/B]
Thanks for the explaination, but we are qualified to accept phone orders with our account, and I just read the usage agreement and it doesn't say anything about not using the internet to generate business. Unless you can point me somewhere official, I assume that I can go ahead with my project.
Well your merchant agreement states that - that is official. Keep reading though to see if they charge you extra for the non-qual rate.