Price "Fixing" and identity theft in shopping carts for third party CC processors.

One common problem with basic shopping carts or "buy now" buttons is that the data in the form is visable to the shopper. In fact, in many cases (PayPal for example) the price to be changed for the item, as well as the merchants ID (your email address for PayPal) is contained in the form submitted by the shopper.

Problem: Public, clear text, non-obfuscated merchant email addresses: Putting up PayPal "Buy Now" buttons without encryption (which PayPal does provide but seems to be infrequently used) is an invitattion to spammers to grab a known valid email address.

Problem: Undetected Price Modification: Most buttons or shopping carts must send the price of an item to the processor from the form on the users computer. Less than honest shoppers can choose to copy the HTML in the button or cart and modify the price to reflect a "digital finger discount" which will then be sent on to you in place of the price you expected. In many cases this isn't a problem since you will see the price is wrong and reject the transaction. But there are cases where no human looks at the order: Online software sales with automatic email or download delivery are one example. And it is very possible to just miss the amount when you (or an unmotivated employee) are processing a large number of orders for a large number of different products. Even easier to miss is a group of products in a shopping cart; did you really add it up again to verify the total?

Solution: Encryption: One solution is to encrypt the data in the form or at the very least, "sign" it with a cryptographically secure value that ensures the cart is not altered; a sort of crypto-checksum such as the HMAC_SHA1 function. How do the major players manage this?

• PayPal offers an easy to use system of encryption for "Buy Now" buttons which is very much recommended. If you arn't using it, you should. It is not available under certain circumstances such as when custom options or other special fields are required, but for most users it should be the default. One gotcha: PayPal will still accept non-encrypted payments (which could be price modified) until you change a setting in your profile to prevent it. Before you change it, you must ensure that ALL your buttons are encrypted or the ones that you forgot, will stop working.
   
• PayPal also offers an advanced encryption for custom Buy Now and Shopping cart fields. There are two basic problems with it:
  • It is complex as all heck and not well documented. This tends to push users towards the shopping cart vendors who have worked out the kinks (and who charge for that effort).
     
  • It would appear that even when the buttons that go to the PayPal shopping cart ARE encrypted, the posting of the data from the shopping cart to PayPal at checkout time are NOT encrypted. While it is doubtful that spammers would take the time to automate the harvesting of email addresses from shopping cart pages, the problem of price modification is very real in this case. If you set PayPal to only accept encrypted payments, the PayPal shopping cart stops working. If a scammer can send a fake, price modified, non-encrypted payment, what was the point anyway?

• Google buttons are always encrypted. The Google API for Google Checkout encorporates encryption and offers sample code and tools in several common languages to provide for encrypted data in both the buttons and the shopping cart checkout forms. Since Google does not assist with shipping, this is a great opportunity for shopping cart vendors to step in and fill the gap with thier own shipping support while improving security and saving thier clients a few dollars in fees at the same time.

See also:

• 
• http://checkout.google.com

  .