Putting actual information into cookies, as opposed to just storing a session ID and keeping the rest of the information server side can (but does not have to) be problematic. There are two pitfalls you want to avoid:
- Trusting information in the cookie without server side validation, e.g. accepting a total price of $0.01 just because the cookie says so.
- Storing sensitive information in the cookies, e.g. passwords or credit card numbers.
However, there are legitimate reasons to store things in cookies. I could imagine it could be useful when implementing a shoping cart and you want to persist the content over page loads without troubeling the server.
So to know if there is a vulnerability here you need to carefully pen test the application (just like you have already done). Try changing the price. Try to order an item that you should not be able to order. Try providing random rubbage. Try to fake discounts you should not get. Try to order non existant items to get the free shipping you only get when ordering more than five items. Try starting two orders in different browsers and see if you can hijack one of them by changing the order ID of the other. Etc, etc, etc.
Some apps that rely on cookies to keep a state will populate a form client side with the data from the cookie, and then that form is sent to the server when the order is submitted so the server will never bother with the cookie. If that is the case here, you should probably focus your pen testing on the form instead of the cookie.
To write safe code, you will need to treat cookie values with the same scepticism you treat any user input even though it was you who set the values. So you will need to validate, do authorization, calculate the correct price and so on server side.
So to summarize, the answer is a firm "it depends".