Say i have a Laptop for 600.00. Say i change it to $650.00. How do shopping carts handle that? Like do they store the price in the cart or the item? How do they make sure they get the price they wanted but not bill the customer the new change without asking them? Or do most store them in both?
I was thinking maybe i could store it in both.
So if the current price is over the cart price for a item, don't remove it/bill them from their cart. Then after, tell them what was billed/email a receipt for the items that didn't change that was billed(say they had more then one item) and remove it from the cart. For the items that did change, say something like "Items left in cart due to price change, please check if you still want to buy the items at the new price." So leave the items that changed in the cart but update the price in the cart.
Thats my idea on how to do it. I don't think the language should matter. Guess this is more of a logical type question. Do most shopping carts do it this way or is there a better way?
Simple shopping carts are just arrays of products that are maintained through sessions and cookies. You can do anything you want. Just make sure users can't do anything they want such as change prices through the url. But most of all make it very, very, very easy for the user to checkout.
Most developers will create an array with product objects so if any changes are made to a product shopping carts will reflect this change. However, if you change your prices then obvious you will have a problem if a user clicks on on price but then you change it and the uses doesn't see this change until after they paid or become confused why the price went up mid shopping experience.
In terms of maintaining the line item if you have users sign in before they can add things to a cart then you don't need to worry about creating a cookie/session to store the array of the line items until they do checkout and the line items are saved with their information for later reference.
In this case what you will want to do is create a line item which is associated to the object so you can get all the products information but at the same time store the price in that actual LineItem model so if you do update your price it will not affect shoppers mid buying experience.
And if you want users to pay higher prices because you change your mind and want to use the line item model you can just do what is sated in the last paragraph and check the price right before a user decides to checkout. If it is different then let them no that this product is now x amount to purchase and don't forget to apologize.
The short answer, it all depends on how it was coded.
I assume the transaction that you are talking about is in process. If the price changes after the user completes the transaction, then it would be considered a "Bad Thing" in the terms of customer service, and may potentially be illegal in the eyes of your payments processor.
I like your idea of comparing the price in the cart vs the newest price. However if the user can change the value of the price of an item in the request to view the cart, it could cause many problems with what they actually get charged. For example, if the user changed the price of the laptop to $1200, and in your code you reduced the value in their cart by the difference, they could get that laptop for $0, which would be a "Bad Thing".
$1200 - User Input
$600 - Actual Price
-$600 - Adjustment against price
$0 - price customer is charged?
Another example would be if you make the price of the item a value that the user can edit, and they are a malicious user, they could potentially change the price to -$600.00, which again would be a "Bad Thing".
The more secure way to do it would be to store the item ID of the item in the cart in the link to view the cart, then retrieve/update the price of the item in the cart every time the properties (total, etc) of the cart are requested. That way if a malicious user tried the plus or minus trick, they would just get a message that the price has been updated to the "current price".
The OWASP site has some open source security tools that can help test your code against situations where the user tries to high jack a shopping cart. Their address is http://www.owasp.org
If the cart simply contains a reference to the item (such as the id/primary key), you don't need to store the price in two places at all. You simply load the objects from the cart when you need them, and prices will automatically reflect the change. In most cases, the changes will be infrequent enough that it is not a big deal from a user perspective.
Related
I want to make implement Cart funcionality in Laravel. I chose this plugin. But here and in many others cart packages I see that cart row stores not a product id but full information (product name, options, price). But what if the product title or product price was changed? Then the user still sees the old title (price) and it will cause some inconvienences to him. What I do not understand, why most cart packages store full information in cart row.
So what is the right way to store cart data: full info or by keys (product_id, option_id, ...)?
There is a preferred way to store cart information, and its the latter that you mentioned.
The reason for this is to not only increase the security of your shopping cart, but to also ensure that, as you rightly pointed out, customers are getting the right price, even after a change.
Typically what you want to do is store the product ID, any customisation options as well as a cart ID. Depending on the amount of products and the traffic you're receiving it may be unnecessary to work out the basket price each time a new page is loaded, and so typically you only work out a new price when a new product is added, taken away or modified; in addition to when the customer gets to the checkout area.
This serves several purposes,
the first is that is ensure that when the cart is directly changed by
a customer action, you can show an updated price.
The second is that you cut down the amount of calculations you have to do by a large amount by only changing the prices in the basket when something acts upon it.
You can ensure that customers cannot cheat the system by modifying the price, then going on to pay a different amount because you stored the price in the session.
I can't give you a more concrete answer because you've been fairly light on the specifics, but I hope this indicates the direction you should be heading in.
Simply put a flexible check out paypal button using your own shopping cart.
one that sends each product plus quantity to the paypal payment page.
I've seen codes for multiple products, but those are not flexible. for example Payment for 2 unique items. but what about if the user buys X amount of different products? when only allows a fixed amount.
Referring to This page
Is this possible to do in PHP? If so I was thinking of something easy like an array listing each product with in the button form.
This would be possible. However, you would want to have some logic on your side that would check to see that amount that they are wanting to order and check it against your database to see the quantity that you have on hand. If they try to order more than you have on hand, you would give them a pop up telling that you only have x number on hand and that they can not order more than x amount. Then you would just populate the details and quantity that they ordered, and pass it over using the cart upload method similar to the example you provided.
I have a website that list multiple items for sale. I would like to use paypal to sell stuff on it. The only problem is, when I have 1 item left, how can I avoid the clash if two people plan to buy it at the same time. Let's say Person A adds the item X to his cart. And after 30 second Person B adds the item to his Cart. Now person A is going to check out and is filling out his paypal information while Person B also presses checkout. How can I avoid that ? I know that I can remove the item from the listing the moment one of them is in the checkout stage, but again what If someone goes all the way to checkout page and just close his browser and never buy the item ? I appreciate it if anyone can suggest a solution that solves this issue and also give flexibility to people during shopping online.
If you create a hosted button on PayPal.com, under step 2 of button creation you can track inventory. Set the quantity to 1 or 2 or whatever you have in stock. Later you can change the quantity in stock by going to My Saved Buttons -> Action -> Edit Button.
If it's a unique item, start with quantity 1 and simply remove the button from your website once sold. People can't complete check out when there's 0 left in stock, so it's first come first served.
I am currently working on an eCommerce website, but i need some advice regarding the stock management.
I want the shopping cart to work as follow:
CostumerA add a productO to cart with a quantity of '1'.
CostumerB tries to add the same product to their cart but with no success.
CostumerA logs out or their session expires.
CostumerB tries to add productO again and is allowed to do so since the product hasn't been added to CustomerA's cart ...
i came up with 2 solutions but neither is reliable from my point of view:
add a field 'champ' to Table product that initially have value of product.quantity but change with cart movements.
add table Cart and update it with cart movements.
as u can see both solution require lot of work.Is there a better way to implement my shopping cart.
I think a better way might be to only update if the user checks out and check stock on the product listing pages.
The downside being the following scenario:
user A adds an item to their cart
user B adds the same item to their cart
user A checks out and the item is now out of stock
user B checks out, but item is out of stock
You'll need to check stock at every point in this process and inform your users what's going on.
Tying up inventory by having a user placing it in their cart is a bad idea. If user A adds all of the available stock of one item to their cart, no one else can buy it until they either log out, or you log them out with some sort of timeout.
OK my client wants to show a buy both feature in the cart, if they have 1 particular item type in the cart they want it to show up for another particular item type so if they buy both they can save $50 off the total. I am trying to wrap my head around what would be the best way to set this up so it couldn't be easily hacked (ie: adding both to the cart then removing one and keeping the discount)
does anyone have some general ideas in theory?
Thanks.
Why not perform the check right before they submit the order? that way, everytime they get to the submit order page, it will check if both items are present.
easy enough - always calculate the final price on the fly based on the current cart contents. The issue you mention seems like it would only be a problem if you were calculating the final price and caching it somehow.
usualy it'd done by creating a new bundle item. It's a bit dirty but works :)
Are they using a system already, or is this a custom job on your part?
Add the discount to the cart and use another table to keep track of the discount's dependencies. Whenever an item is removed from the cart, check to make sure the discount is still valid. If it is, great. If not, remove it and recalculate the cart price.