| 7:39 am on Feb 15, 2005 (gmt 0)|
Looks like you have TWO problems, price and verification.
Is there a customer email address you can query? -Larry
| 9:59 am on Feb 15, 2005 (gmt 0)|
Sir or Madam,
Thank you for purchasing our product. Upon receipt of the remaining balance of the purchase price we will immediately ship your product and provide you with tracking information. With receipt of your $33.99, the remaining balance is $400.00.
Thank you for shopping with us.
| 2:54 pm on Feb 15, 2005 (gmt 0)|
If you don't have it already on your order policy page, you should include verbage like:
"We cannot be responsible for errors in typography or photography. We reserve the right to cancel any order at any time."
You're under no obligation to sell your product at the wrong price. So tell the customer he can have it for the correct amount or the order will be cancelled.
The next step is to figure out how they managed to get an item in the cart for an amount other than the "correct" price -- it shouldn't be possible if you're looking up prices from a database; if you're using whatever is hard-coded on the product page, you're open to all sorts of potential problems.
| 3:04 pm on Feb 15, 2005 (gmt 0)|
Unless I have this wrong you dont have to honour this.
Say I run a traditional shop I place a price tag on something that has the decimal place out of whack. The customer picks it up an brings it to the till, they are offering to buy it, at that stage I can refuse to sell it (if I notice a mistake) This is the offer/consideration/acceptance process.
This is suggested with no warranties, OK, just an obseravtion on UK contract law which i did a little of some years ago.
You do need to get your form validation sorted though, to prevent this happenng again.
| 5:15 pm on Feb 15, 2005 (gmt 0)|
Yes, the price is on the HTML page. Its not encoded or hidden in any way.
My shopping cart said in the e-mail:
|Always verify price accuracy. Order from IP# xx.xx.xx.#*$! Warning! A page was submitted from an unfamiliar URL: Probable local file submit or browser location bar manipulation. Double check prices. This may indicate shopper tampering. |
| 5:20 pm on Feb 15, 2005 (gmt 0)|
You have the right not to charge the card.
If their card hasn't been charged, cancel the order.
If their card has been charged, you can fufill it out of goodwill or refund the card and cancel the order.
| 9:34 pm on Feb 15, 2005 (gmt 0)|
Hmmmm, I asked the guy how he placed the order with the reduced price. He explained the process and offered to redesign the site for a fee to prevent this from happening again.
| 9:39 pm on Feb 15, 2005 (gmt 0)|
|He explained the process and offered to redesign the site for a fee to prevent this from happening again. |
Offer to meet him late at night in a dark, secluded place to work out the details - bring a blunt instrument for sealing the deal.
| 10:03 pm on Feb 15, 2005 (gmt 0)|
Is this Mal's shopping cart?
Its a known issue - and I believe there are a set of instructions in the documentation to work around it.
| 1:51 am on Feb 16, 2005 (gmt 0)|
I think I would send him to collections if he doesn't pay the balance.
| 8:39 am on Feb 16, 2005 (gmt 0)|
I wouldn't let him anywhere near your website. This guy is obviously corrupt. He didn't place the order to show you how dodgy order 's can be placed, he was trying to get the item at a knock down price. If he had've wanted to prove a point he might have changed it to a dollar or even a cent, but $33.99 could easily be mistaken for $433.99 if you were just glancing over it.
I expect your cart uses basic Form inputs to send data to a shopping cart (i.e. it is not database driven.), so it would be easy for someone to manipulate the code.
| 8:53 am on Feb 16, 2005 (gmt 0)|
CernyM - this is what I was thinking. It is easy for someone savvy enough to change the price of items from stores using Mal's Ecommerce. I do think there is a workaround though.
| 8:56 am on Feb 16, 2005 (gmt 0)|
a) call the customer and confirm the HIGHER price and if they say no, cancel the order
b) get a real cart, one that uses a database and doesnt pass price via form
| 6:41 pm on Feb 18, 2005 (gmt 0)|
My custom cart passes price in the hidden form, but that was actually an accident because I also send style, color, etc. through the form. The funny part is that I pull the price out of the database on the cart page, so that price in the hidden form doesn't really go anywhere. I would take this out, but I like to know that I'm giving malicious cart breakers a hard time.
| 9:15 pm on Feb 18, 2005 (gmt 0)|
sun818, always verify the pricing before writing the items into the cart. If you're passing the pricing over in a hidden form field then any programmer can write a few lines of code to post into your basket with their own price and then take the cart to checkout.
| 9:31 pm on Feb 18, 2005 (gmt 0)|
Get the authorities involved. Forward your correspondence and move on.
| 2:54 pm on Feb 19, 2005 (gmt 0)|
|Get the authorities involved |
Ya know that's pretty good advice. In most states knowingly intercepting electronic communications is a crime. This person knowingly intercepted an electronic communication to your system and altered it for their own benefit.
| 12:41 pm on Feb 24, 2005 (gmt 0)|
Ya it must be a Mals-e Shopping cart or a crt using the same type of system . What happens is that the Url you have to go to is of the type http://ww8.aitsafe.com/cf/add.cfm?userid=XXXX&product=Bunch+Full+Of+Love&price=26&return=www.abc.com/gifts.htm
What can be done is that in the url just change the "Price =26" to any value you want and thats it . You will get the price reduced . This thing can be easily fixed
[edited by: lorax at 3:37 pm (utc) on Feb. 27, 2005]
[edit reason] delinked [/edit]
| 3:12 pm on Feb 27, 2005 (gmt 0)|
Maybe I'm just repeating what's already been said, but it should be obvious that whether you should ship is not even an issue. That's self-evident, a foregone conclusion: no way Jose. And don't even bother corresponding further with the slimy creep unless it's in cooperation with law enforcement, as a lure into a trap.
The only thing for you to focus on is eliminating the bug that lets it happen.
| 11:31 pm on Feb 28, 2005 (gmt 0)|
wouldnt a simple change of the form method from "Get" to "Post" help to solve this problem?
| 3:49 am on Mar 1, 2005 (gmt 0)|
|wouldnt a simple change of the form method from "Get" to "Post" help to solve this problem? |
No because any coder can write their own code to post their own price into your receiving page.
Depending on what your selling this is either simple as pie of can get very complex. For example if your selling this widget:
Your form should ONLY post the Sku and Color. Price should never be passed. Those attributes should then be tested at the database side. Here's a simple example:
if exists(select widgetid from products where sku = 'widget001' and color = 'Green')
-- Get the price for widget001 from the Products Table not the FORM POST
declare @ItemPrice money
set @ItemPrice = price from products where sku = 'widget001' and color = 'Green'
-- now that we have a Price, Sku & valid color write this into the basket table
insert into basket(....)
| 11:05 am on Mar 2, 2005 (gmt 0)|
Sell him the product for $33.99... but charge him $400 for shipping ;)
| 11:22 am on Mar 2, 2005 (gmt 0)|
i'd write back thanking him for alerting you to a security flaw in your cart and wish him well.
- obviously don't send the item, that is not even open to question!