Closed Thread Icon

Topic awaiting preservation: security and e-commerce apps Pages that link to <a href="https://ozoneasylum.com/backlink?for=12866" title="Pages that link to Topic awaiting preservation: security and e-commerce apps" rel="nofollow" >Topic awaiting preservation: security and e-commerce apps\

 
Author Thread
butcher
Paranoid (IV) Inmate

From: New Jersey, USA
Insane since: Oct 2000

posted posted 08-20-2003 18:59

Hi all.

It seems I may get the chance to build a shopping cart (PHP) that includes online ordering and payment (credit cards). I'm a bit nervous about all the security issues that I face and don't want to muck anything up. I was wondering if any of you guys that are old hands at this could relate any of your past experiences or common pitfalls that I need to look out for. I (as well as any other first timers at this) would be grateful.

Thanks

-Butcher-

DmS
Paranoid (IV) Inmate

From: Sthlm, Sweden
Insane since: Oct 2000

posted posted 08-21-2003 22:26

Well Hi there

I've just implemented two different payment providers (swedish) in a big PHP/MySQL project that's nearing completion now.
One is the "internet wallet type" where the user loads his wallet with cash from a creditcard, then calls upon the wallet when he want's to buy something.

The other one is something of a payment switchboard that gives the end user the 4 major creditcards and swedens 4 biggest internet banks.

The implementation is differerent for both of them but they follow the same principle.
They give you specs on exactly how to create the calls to their application and in which format you will recieve their answers.

For all of these except the wallet there is one common denominator., The domain must have a valid certificate, and no it's not enough with a certificate that you (the server) creates by itself, it has to be a certificate that can be validated without any boxes popping up asking if you want to trust this or not. the thing is that it's the code that recieves these without user input so it will most probably stop your application from processing the answer. Also, you will never, ever get a user to submit creditcard info on an unencrypted page.

My first recommendation would be to research the paymentproviders available to you/the customer to see what solutions they can offer. An external paymentprovider is without a doubt the fastest and easiest way to get this up and running.

If you have a choice, pick one that provides an interface on their server for the input of creditcard info, that means less stuff for you to create.

The providers that I had to work with did it differently:
The "wallet" gave me instructions to create an url in a special format, pass that through SSL (we used CURL for that) to initiate the payment, then we should pop a window with their site, also with a special url. Then the customer did his stuff there, some info was swapped that we should react to and when it was done a response came to our script from the wallet and we responded with "OK", then if they got our response it was done and we could act on the completed transaction.

The switchboard was simpler to implement, here they provided us with two different ways, one for the banks and one for the creditcards (still in the form of differently composed urls).

For the bank we simply called our script with info on which bank, then that script popped a window that first landed at the switchboard, they convert the call to the proper format for that specific bank then they redirected to the bank. As the transaction is approved by the user/bank the window redirects to the switchboard which in turn redirected to an url of ours with standard formatted url with transaction-id status and so on, that we could act on and tell the user that all is ok.

For the creditcards we had to build the page to collect the info from the client (certificate required!), then construct the url and pass it on, from there it worked the same way as with the banks. The format of the answer from the switchboard is the same from all the payment options.

For validation of the passed and encrypted data an hash-string is created from selected parts of the url together with a secret key (some 20 chars long) that is encrypted with md5, calculation of the validation has to be done both as you send and recieve to ensure correct validation.

It sounds like a lot, but we got good specs and example code from the providers so it was appr a weeks work to get all of these payment options up and running.

As you see, creating this by oneself is not an option, at least not in my opinion.

Good luck and I hope it comes through for you!
/Dan

{cell 260}
-{ a vibration is a movement that doesn't know which way to go }-

butcher
Paranoid (IV) Inmate

From: New Jersey, USA
Insane since: Oct 2000

posted posted 08-22-2003 17:36

Thanks DmS!!

That sounds like quite a project there. The wallet sounds like a really cool feature.

Thanks for the insights on the cert and on the processing places. I haven't looked around a lot, but I didn't know that some of them allowed you to switch to their server for the info input... that's got to relieve a bit of work.

Thanks again.

-Butcher-

Emperor
Maniac (V) Mad Scientist with Finglongers

From: Cell 53, East Wing
Insane since: Jul 2001

posted posted 08-23-2003 19:28

I notice Cal has produced some articles on user authenticationa dn cookies and stuff which might be relevant:
http://www.iamcal.com/publish/article.php?id=28
http://www.iamcal.com/publish/article.php?id=27

___________________
Emps

FAQs: Emperor

brucew
Paranoid (IV) Inmate

From: North Coast of America
Insane since: Dec 2001

posted posted 08-23-2003 23:46

Piggybacking on the thread...

Interestingly I'm in the middle of writing an RFP for a similar project and was going to ask here about security in a couple of weeks.

DmS: I came to similar conclusions about using a third-party for payment for expediency. It's good to hear about the basic process and time for implementation. Thanks.

This project goes it a bit of a different direction than the typical shopping cart and presents security issues of its own.

Client is a not-for-profit literary center. Each quarter they offer 50-70 reading and writing workshops (sorry, no 'rithmetic). It's time to take the next step from just showing the course listings online with a PDF registration and payment form to accepting course registration and payment online. So far, pretty basic stuff which could be done with almost any shopping cart package.

The twist is that there are two prices for each course, depending on whether or not the registrant is a member. This requires that the membership database be available to the application. Keeping this database secure is the issue.

Their current "database" is an Excel worksheet on an iMac in the front office. A few more iMacs and a DSL line are the extent of their infrastructure. So keeping the thing in-house isn't a viable option. That leaves the web server as the only alternative. I host the site on a shared virtual server. I have MySQL now and a choice to use PostgreSQL after an upgrade scheduled this autumn.

This is way beyond my ability to code, however the fundemental system analysis and design is within my skill set, even if I'm a bit rusty. What are the issues I should be thinking about as far as server environment, MySQL issues and such, and what should I make sure goes into the RFP?

« BackwardsOnwards »

Show Forum Drop Down Menu