four or five shopping cart design questions

[G.E.M.P]

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?

[G.E.M.P]

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?)

[d]

"G.E.M.P" <sl*********@spammers.com> wrote in message
news:gZ********************@bresnan.com...

--------------------------------------------------------------------------------

High Level Session Handling Design for a Shopping cart
0) What am I missing?
1) How does OSCommerce do 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.
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.
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
all.
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.
Bingo.
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.
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).
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.
You just need to hold the composite IDs of the products, and their basic
display information (price, actual price, make, model, etc.).
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.
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.
3) What security pitfalls surround holding credit card information
in session memory? How long do we keep credit card numbers?
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 ;)
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?
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
session.

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!