four or five shopping cart design questions

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

High Level Session Handling Design for a Shopping cart
0) What am I missing?
1) How does OSCommerce do it?

I'm thinking about building a shopping cart from scratch,
using a library of dynamic screen generation routines
(already written) that take an XML stream as input from  
various "search for products" forms. That way I can
run queries in one window and display the dynamic
results in another. The searching functions will probably
not index into a relational schema. Instead I'll use
Lucene to parse keywords and values out of XML-based product
descriptions. I know a lot about XML, Lucene, Xpath, XQuery
and dynamic screen rendering. But I have no experience
(at all) working with shopping carts in general.

2) How does repeat customer session handling usually work?
When a customer first logs in we generate a sessionID  
and send it back to the client as a cookie.

Later on in the session, and before we can consumate a purchase,
they have to supply name address and (https) credit card number. We
put that stuff (not including the credit card number), along with the  
sessionID, into a database of some kind. That part (customer contact info)
may well be mysql.

Any current shopping cart items are handled as  
session memory items. Session memory will probably track items
with a hashed array of productObject types, which is a complex
object class that includes lots of generic stuff about each product
in the catalog (name, inventoryID, etc)  
That way we can jump from screen
to screen without losing session, while finishing up at a "review cart" screen.

Review cart has cart-editing features (two of these, none of those)
plus contact information editing, plus a "Make Purchase" button that sends the transaction  
off to a 3rd party transaction handler, sends an email receipt  
to the customer and then prints a Thank You screen. It's probably a good idea NOT to store  
credit card numbers on the server. Instead we hold it just  
long enough to clear the transaction.

3) What security pitfalls surround holding credit card information
in session memory? How long do we keep credit card numbers?

5) If the customer negotiates his/her way all the way out to
the cart editing screen, where they do fill in a card number, name
and address, and then change their mind, and go back to  
the shoppingMode screens, do we NULL out the credit card in
session memory? Or keep it around. And if so for how long?


Re: four or five shopping cart design questions

Forgot to add:

Each consumated purchase would exist as a hashed array of
productObjects, so I suppose that could be serialized,
associated with that users semi-permanent sessionID
and then persisted on the server, so the server
could retreive every known detail about every transaction,
after the fact.

So the shopping cart could recreate a transaction history
for that customer (do you want to see the details of
your 2nd to last order?)

Re: four or five shopping cart design questions

Quoted text here. Click to load it


Quoted text here. Click to load it

Take notes from OSCommerce, but for the love of God don't use it ;)

OSCommerce stores a composite ID of the product and it's attributes (say  
colour=blue, size=large) in the DB alongside the user's ID.  That's  
essentially it.

Quoted text here. Click to load it

Shopping carts are scary to many developers, as it's usually a break from  
the norm.  They are, however, a great demonstration of where a small amount  
of code, properly organised (as I'm sure yours will be), can provide a lot  
of very useful functionality.  It's just storing numbers next to each other.  
The "cart" is simply a relationship between the user and a product, after  

Quoted text here. Click to load it


That's essentially it.  When the user logs in, the session is  
created/resumed.  You can then add to that as and when you need to.  When a  
purchase is going to be made, you ask them for their details, etc (and  
username/password), and set them up a user account.  You can then create a  
login script to populate the session with their stored data when they log  
back in (say, cart contents).

Quoted text here. Click to load it

You just need to hold the composite IDs of the products, and their basic  
display information (price, actual price, make, model, etc.).

Quoted text here. Click to load it

You can hold it on the server - just do it sensibly.  Obviously you should  
get rid of it when you've used it, as you say.

Quoted text here. Click to load it

Don't keep it in session memory, unless you can guarantee that the path  
where the sessions are being stored (assuming you're using the default  
file-based sessions) is secure, and impossible for non-web-server users to  
gain access to.  You could write a custom session handler (really quite  
easy) which incorporates some more advanced security features to assure the  
security of the credit card information.  Once you have their money, get rid  
of the credit card information.  That's law in many countries, so it's  
better to be safe than in court ;)

Quoted text here. Click to load it

Personally, I'd give the user the choice.  You can have the credit card  
information time out in the session, so if they don't go back to the  
checkout in, say, 5 minutes, then your code will nullify the number in the  

Quoted text here. Click to load it

I wish more people wrote their own shopping cart/store systems, as opposed  
to just relying on OSCommerce and its derrivations (zen cart, I'm looking at  
you).  Those products simply suck, and if talented folks make their own,  
their grip of mediocrity will be broken.  Good luck!  

Site Timeline