I would highly recommend adding an additional table to keep track of your product IDs. I know... I know... Its a little more work, but you'll be following good database design practices and you'll have an easier time digging the data out later.
Keep your orders table the way it is. If you have a column you were going to use to store the product IDs, you can remove it (or remove it after you get everything all settled in - doesn't matter).
You'll want to add an additional table. The bare minimum needed for this table is only 2 columns: order ID and the product ID in the cart.
Notice there is one row per product ID. It may seem odd, but this is a good thing since you'll be able to do tricks with this later on. What makes this all work is the fact there's an order ID tied to that product ID.
So lets take an example. I purchase 3 items. The product IDs for giggles are 101, 102, and 105.
From a coding standpoint, you'll still do your insert into your order table - and you'll need to do this first AND grab the ID that was used for your new record. This ID should/will be the order ID. You'll need this.
Once you have the order ID, you can update your orderproduct table (lets call it that for the moment - you can name it whatever you like). To update this orderproduct table, you'll need to loop through all the product IDs in my shopping cart (which I assume you're able to do). In your loop, you'll just insert a record into the orderproduct table with the order ID you grabbed in your last query and the current product ID of this loop you're in. Presto! You're done.
Now something you'll want to think about is the auxillary data regarding the order - how do you want to store it all? One thing to think about is prices. In theory, with this orderproduct table, you may wish to include with the order ID and product ID the product's individual price. Maybe you were running a special on product ID 105. Maybe 2 weeks later you raise the price on ID 102. Either way, it may be pretty valuable to keep track of what the user paid for that product at the time of purchase.
But at the same time, you might find it valuable to put the order total in the orders table. Some might say thats not normalized because technically you could query your orderproducts table and calculate the order total - but you may have shipping, handling, and tax to include so an order total in your order table will still be pretty helpful (or you might have additional columns in your order table to handle tax and shipping).
You have some creative here. Just keep in mind what is called the "one to many" relationship you have between an order a user places and the products they have in their order (notice that a user would have 1 order or 1 cart and many products associated to that order or cart).
