Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

shopping cart implementation

by silent11 (Vicar)
on Sep 16, 2002 at 18:44 UTC ( [id://198331]=perlquestion: print w/replies, xml ) Need Help??

silent11 has asked for the wisdom of the Perl Monks concerning the following question:

this post may be OT. read at your own risk.
We've all read posts here about people wanting 'out of the box' shopping cart solutions written in perl. I have no intention of being one of those posters today. But lets face it, a lot can be learned from building an application such as a shopping cart. I have often entertained the idea of writing my own solution to the shopping cat dilemma. I am still undecided as to weather or not I will, but I do have a few questions regarding shopping cart systems; not on the code level, but a higher level.
What I was hoping to do was to explain how I think a shopping cart should work and possibly you more experienced monks could correct me where my logic is off. So here goes nothing.
  • User visits app and gets assigned a unique ID via a cookie.
  • Each time the user adds/edits/deletes an item to the cart a record gets added/edited/deleted in a database table (Containing the user ID, prodID where prodID is the primary key in the product table, quantity, etc..)
  • once the user is ready to check-out we somehow pass the ID over to an app sitting on a server with aSSL.
  • Once on the SSL we take the users information (including credit card info) and process the order
  • I would assume that the credit card number would be stored encrypted on the database so that intruders could do nothing with the number without a key.
So in my head that's how a shopping cart should work. I have left out alot of functionality that usually is included with a cart, but to my knowledge this is the bulk of what is happening. If I'm wrong, and I probably am, tell me I'm wrong, but most importantly please tell me why.
I'd also like to hear about pitfalls others have made out there while building similar types of apps. What should I be looking for? What shouldn't I be looking for? Do I roll my own? Do I use an 'out of the box' solution? I'm sure each of you have gone through the same thing I am going through right now. What was your experience?
Thanks in advance.

-silent11

Replies are listed 'Best First'.
Re: shopping cart implementation
by shotgunefx (Parson) on Sep 16, 2002 at 18:58 UTC
    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."
      DO NOT use form fields for price.

      Incidentally, this is my favorite web security bug. I am amazed by how many people have done this. I'll take two new PCs for $3.00 please.

        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."
Re: shopping cart implementation
by BrowserUk (Patriarch) on Sep 16, 2002 at 19:42 UTC

    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!
Re: shopping cart implementation
by hiseldl (Priest) on Sep 16, 2002 at 19:33 UTC
    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"

      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."
Re: shopping cart implementation
by barrd (Canon) on Sep 17, 2002 at 10:37 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://198331]
Approved by hiseldl
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2024-03-29 12:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found