Hello All

[antona]

After getting the 99th phone call asking why there wasn't a 'shopping cart' function on the antona.com website, I decided the time had come. uh, also I note that most all of my competitors have such a function on their sites. The osCMax program looks like it will fill-the-bill and has been recommended on several cart software review webpages.

As I know next to nothing about PHP or MySQL, there's a big learning curve to climb. So far I've installed a local server on my desktop computer (xampp) that runs PHP (also runs the database mysql) and gotten the osCMax cart running good enough to work on. I can place orders, and see them show up in Admin. Emailing does not work, but I think that has to do with a server issue rather then a PHP problem.

Other issues still to be solved involve handling offline credit card processing (or hooking in the alavon virtual terminal) and linking current website HTML datasheet pages with the usual 'buy now' button to jump to the correct PHP product page on osCMax. I found info on the offline CC processing, but still need to locate a posting on the correct way of going from HTML to PHP. Maybe a matter of linking the 'buy now' button into the 'search' function for each page I suppose.

Anyhow, I have found a lot of useful information on this forum - Thanks.

[jpf]

Welcome,

Yes osCMax is ready to run and use out of the box. (Customizing it may takes a bit of time however).

Great that your using a LAMP/WAMP like xampp for your testing. Just remember that all WAMP state they are not to be used in a Production or Live server.

Off line CC is a BIG liability issue! Many CC are cracking down requiring PCI compliant servers - and having the full CC on most servers is an automatic FAIL.

I do suggest you look at one of the payment modules included with osCMax or you can work with one of the 700+ payment modules/processors that already have a module for osCMax/osCommerce/CRELoaded/ZenCart/CubeCart etc...

Ask your processor if they already have one or see if some one already created one: 760+ Payment Modules

Good Luck!

[antona]

Thank you for the reply - I will check with my merchant CC outfit and see if they've got a payment module for osCMax. There must be one with +700 modules floating around out there! The CC issue is the only thing left to get squared away before uploading a working version to the website.

[jpf]

Thank you for the reply - I will check with my merchant CC outfit and see if they've got a payment module for osCMax. There must be one with +700 modules floating around out there! The CC issue is the only thing left to get squared away before uploading a working version to the website.

Humm...did you look at the above "760+ Payment Modules" web link yet?

[antona]

I have looked through 1/3 of them. The more I learn about CC processing, the more there seems to be looked at. I must be missing something to not understand why the process of off-line CC processing would present some problem.

1. Customer fills in CC number on 'https' secured connection and not receiving a 'SSL certificate not valid' warning.
2. CC info is encrypted and stored in SQL database via a key-word.
3. Website owner checks into admin directory via 'https' and types in username + password before being able to download the customer order and protected CC info.
4 CC info is decrypted by key-word used for encrypting.
5. Website owner processes CC card the same as if a phone or FAX order had arrived.

What am I missing? As 10s of 1000s of websites have this shopping cart function working with CCs, it must be doable without rewriting (or writing from scratch) a osCMax module that protects both customer and seller.

[jpf]

The connection is secure....but what if you have a hacked server and they are looking at your DB or files......

More and more a few years ago - CC number are being stolen from major vendors all over the place due to poor server security. Now with PIC compliance and auditing they certify servers from know attacks and if they do hack that it is nearly imposable to get personal info like CC & SIN info.

If stored in DB then they copy everything. If encrypted in then sit back and watch and figure it out ....

HTTPS does not protect you if site been hacked - you have a key-logger/screen capture Trojan. You have poor passwords.... Just a few of a number of things.
HTTPS is just the connection - if some one has a network sniffer and looks at the packet (was and still is very common). But if encrypted and the hash is store on the server - then it is just a mater of time to unlock it.


Paypal is easy to setup and use. Authorize.net is a good one - plus so many others too. They are the most secure and speedy to use. All protect your the merchant (as no CC is stored on your Server) and the Client (under HTTPS and CC is stored in a very secure data storage). Your liability of the CC leakage had just gone right down to nearly zero.

Please note some one could brute force an attack on any server - if your not actively looking at your logs - at some point they would get in. A key-logger/screen shot would make any https or password unless.

Check your merchant agreement for "Card not present" clauses (ie: ONLINE or phone/fax orders). You might not be able to use (or limited use of ) off line CC....

They often will change you more if you manual or process alot of "Card not present" or online transactions (typically 4.5-6.5%). If you use a CC processor - this often goes down (2.5%-5%)


There are 1,000,000's of sites taking CC - Much of it is over HTTPS and other encryption in the background taking to a secure CC processors.

[antona]

I'm sold - I'll probably use the CDG as they seem to be offering the cheapest way to process CCs.

Life would be much simpler if every action was not governed by the criminals - at least when it comes to CC processing.