For the cart, make sure you validate any options, etc from the DB when adding to the cart and checking out. DO NOT use form fields for price. It warrants repeating. Validate everything at Checkout.
As far as storing CC don't longer than you have to. You're better off with setting up a CC server for it. If not, store it as a GPG encrypted chunk. (There's a nice tie module for this.) Make sure the secret key is off of the server.
Depending on how you need to access the data after the order, you could store the non-payment info with a different key that could be read by the server.
update
Also, see this node for ideas.
-Lee
"To be civilized is to deny one's nature." | [reply] |
| [reply] |
I must confess, I once HAD to do this to interface to a third party service, no other way. I did however validate it before they could finish the check out and when orders were imported.
Suprisingly, no one even attempted it.
(This is not downplaying the danger! It only takes a couple HDTV flat panels and your ****ED.)
-Lee
"To be civilized is to deny one's nature."
| [reply] |
First thought: why is the first action to assign a cookie? I'm betraying my own prejudice against these badly exploited critters here, but given the existance of other, less exploitable, and therefore, less rejected mechanisms for session state persistance, why use a cookie.
Second. In order to assign the visitor a unique id, you need to gather identifying information from the user by which to associate them with the ID. As a visitor who has just come by to gather information, if the first thing I am met with is a long form asking for personal identification, you've lost me as a potential customer. I've moved on before your form has finished rendering.
Much better I think to create a session ID and allow me to 'bookmark' any products I see of interest at the server end--usually described as "Add to your shopping trolley/basket/cart", and not actually ask for identification until such times as I opt to 'Go to the checkout'. One benefit, apart from allowing browsers to browse without supplying their life history, is that if the visitor never makes it to the checkout, you haven't created records in your DB that will serve no useful purpose other than to clutter it up. Unless you are thinking of using their details for spamming, and your not one of 'those' I'm sure:^).
If, as and when the visitor makes it to the checkout, I think I would personally do the calculations, present the 'Invoice' with the opportunity for changes, deletions etc, and the final tally, and upon confirmation that the user wishes to purchase, hand over to the SLL session to gather (minimal) user information, delivery address and CC details etc.
From my perspective as a consumer/customer, it would be even better if the actual financial information was gathered and processed by a third party, specialising in such transactions (but not Passport!), that would--once the details have been processed--simply pass back to the originating site, a confirmation of purchase and a delivery address. That way, I only have to provide my details to once, and can use my electronic wallet (for want of a better description) to make purchases at a range of sites without having to re-supply my personal details. Less frustration for me as a consumer. Less risk as my details are only kept at one place specialising in secure transactions. Less risk to you the site owner as you are less liable to be held liable if something goes wrong, as you never had any details for anyone to steal.
That's how I would like things to work. I just hope the guys working on the open alternative to Passport get their act together and make it work.
Well It's better than the Abottoire, but Yorkshire!
| [reply] |
I agree with shotgunfx, validate the charge versus the price. i.e. use Digest::MD5 to create a hash with the price, the product description, and, if you can, a "secret" string known only to you/your server. Then, when you receive the token from your credit card processor, create the hash from their data and compare. If they don't match, then someone may have tampered with the charge amount, trying to get something for nothing.
Also, check out PerlShop, which is a Perl shopping cart, and take a look at their features and code for more ideas to add to your list.
--
hiseldl
"Act better than you feel" | [reply] |
I tend to undercomplicate it. The form only accepts a product id, a quantity and options. The price and other options come from the database and are only displayed for display purposes. Then there is never an opportunity to fiddle with it.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Hi silent11,
I've been doing eCommerce since 1995 and have mainly used a programme called Interchange. It has a very wide user base, therefore well supported, mature, feature rich, secure and has in-built support for many popular payment gateways. Its strengths come in ease of use via a mechanisim called IML (Interchange Markup Language), but embedded Perl and/or ASP like syntax can also be used. It supports SQL Dbs or flatfile and with a little Perl knowledge you can be up-and-running in a short space of time. Almost all the features you asked about are available with the exception of storing the Credit Card numbers, that is severely frowned upon. I don't mean to cause any flame bait but that is the number one NO-NO! in eCommerce, don't store CC numbers, just don't do it...
There is mailing list support which is amongst the most useful I have ever subscribed to and after a steep learning curve you can have a shop that is capable of almost anything at your fingertips.
No point in reinventing the wheel, and certainly no need to roll your own, almost all the pitfalls have been encountered and fixed with this package. Its also written in Perl. | [reply] |