Faux shopping experience—Cookies, or....?

[macwise]

I'm working on a site that is database driven, allows users to view product, and is meant to allow them to order product online—with one caveat: they can choose one or many products/quantities, but they cannot actually pay online.  The client wants to disallow paying online for various reasons, but basically the flow will go like this:

 

1) Go to product page

2) Enter quantity in input field, click "order now" button

3) Redirect to the order page where a list of the user's current order is shown,

4a) Continue shopping, or

4b) Submit the order and personal (*non-financial*) info via email

 

I know a bit about cookies, so was thinking I would track the users' orders via cookies, set to expire after 24 hours or so.  The main problem with that idea is that setting the cookie on the order page (after receiving the $_POST data) is that the page then needs to be reloaded in order to see the item they've added to their shopping bag.

 

So, do I work around this problem (for example, create an interim page that creates the cookie then forwards them immediately to the order page to summarize) or do I use another vehicle for tracking order data, for instance session data/database combo?  Or is there a better way entirely?  (I'm a total noob, so this is likely)

 

Your suggestions are greatly appreciated.

 

Thanks!

[fortnox007]

Well if you were to track orders from a customer i would use a database to store orders in. Cookies I think are best to serve the customer with the some comfort where the shopping cart knows what the client has selected even if he closes his browser. But to use that as an admin to see the confirmation of an order, I think that can potentially f*ck things up pretty bad. I would use cookies for customer comfort, and a database to store data, with maybe even an email confirmation to send out stuff. That way you also keep out some bots.

 

[macwise]

@fortnox007

 

Thanks for the reply.  Would you mind elaborating as to why tracking orders via cookies could create issues?  I really don't know that much about this process, and am eager to understand the pitfalls and advantages of the different approaches. 

 

Also, I tend to understand flows and steps a little easier—it seems to help me understand concepts in context.  Would you mind listing out the basic steps of how this would work?  My main questions is how exactly the cookies would be used in conjunction with the DB.  Thanks!

[macwise]

Wondering if anyone would mind elaborating on the pieces I would need/steps I might take to accomplish my objective laid out in the OP.  I'm looking for the simplest implementation of a shopping cart experience I can come up with that resolves our requirements.  Any insight is appreciated. Thanks!

[macwise]

I'm new to complex ideas in php, and am kind of stuck until I know the basic ingredients I should be learning about in order to implement this type of shopping experience. 

 

So far my understanding is that I should use cookies in conjunction with DB in order to track customer orders.  The customer strongly prefers to have the final order emailed to them.  Even though I'd love to give them an admin page to manage orders, that is way out of scope for the project, so email it is.  So, do I still use DB/cookie combo?  My guess is that this is still the best approach, but I'm a little sketchy on the details I might need in order to implement this properly/efficiently. 

 

The ingredients I can foresee needing are:

- Cookies

- DB

- Session data

- ???

 

I'm fairly familiar with DB, and cookies to a limited degree, but session data is still a mystery.  So, question is, is this a sound blueprint, or should I be considering an alternative approach? 

[stuartriches]

I would agree with fortnox007 that it would be better to use the db to record the orders.

 

Unless I am missing something, won't the customer lose all their order history if they are on either a different PC to normal, or decide to clear their cookies out?

 

If a customer uses different machines (I alternate between my laptop and PC at home, and can also use a different machine in the office), then their order details are going to be spread across a number of machines.

 

Are you keeping the orders in a database for the client to use and analyse? Without doing this, they will miss out on the possibility of analysing this data to find many useful insights, e.g. customers who haven't ordered recently, abandoned carts etc.

 

Have you tried using a standard shopping cart package? This should allow you to create and handle most of what you need to do, quicker than you can code it yourself. Personally I use cartweaver for php, and it does all you require:

1) Go to product page

2) Enter quantity in input field, click "order now" button

3) Redirect to the order page where a list of the user's current order is shown,

4a) Continue shopping, or

4b) Submit the order and personal (*non-financial*) info via email

as well as providing the admin pages, catalgue maintenance etc .

 

Coping with offline payments is also straightforward as you simply turn the payment processor off, and allow all orders to be finalised in "pending" status, allowing the client to update them to paid once the offline payment has been processed.

 

I like cartweaver as the licencing model allows it to be used on a "buy once, use many" model and its easily incorporated into existing sites and designs as it isn't built around difficult-to-changeemplates.

[macwise]

@Stuartriches

 

Thanks for your response. To answer your questions:

 

Unless I am missing something, won't the customer lose all their order history if they are on either a different PC to normal, or decide to clear their cookies out?

 

If a customer uses different machines (I alternate between my laptop and PC at home, and can also use a different machine in the office), then their order details are going to be spread across a number of machines.

 

The business model for my client doesn't really require this much complexity.  Orders will be placed immediately and from a single computer or just called in for almost all cases.  Order history will not be tracked for customers, and no login is required to order.  Basically, due to the nature of the business, orders are placed and either A) the customer (who is on a credit account) is billed, or B) the NEW customer is contacted and run through a credit check process, so they can be billed for the current order and all orders placed thereafter.

 

FYI, the previous website simply had an order page with a table listing all of the products requiring the customer to sift through the 40 or so products and select the quantity they wanted for each product ordered (default 0 for any products not ordered).  Instead of keeping this abysmal list, I thought I would improve on this system by making the order page "smart", remembering any product they've ordered from any given product page.  This keeps the final order list short and relevant.

 

Are you keeping the orders in a database for the client to use and analyse? Without doing this, they will miss out on the possibility of analysing this data to find many useful insights, e.g. customers who haven't ordered recently, abandoned carts etc.

 

While I can appreciate this logic, these are capabilities which the client neither requires nor desires.  This really is a simple site that is updated VERY infrequently, used by a very focused group of customers, and billed offline.  If it were a full fledged shopping site, I would have hired my backend guy.  Since the budget is so low, I, the front end guy decided to tackle it myself.  I really am only seeking to make iterative changes to the flow from their current system, and am mostly improving their front end experience.