2CO meets PCI requirements so you don’t have to!

When considering the best way to sell your products over the internet, one of the most important aspects to look at is the security of customer data. Credit card companies require all merchants to follow extensive security guidelines, called the PCI DSS, which describe every aspect of how the customer’s information is handled. Meeting the requirements set forth in the PCI DSS can be an expensive and time consuming endeavor. 2Checkout takes on the responsibilities of PCI DSS compliance for our suppliers, saving you time and money.

Continue reading…

The ability to include ‘demo=Y’ to return to the vendor defined approved URL without placing a valid order is not a security flaw or error, it is the intended usage of this parameter. It is included in the parameter set in order to allow for vendor testing, from the start of the order process (passing the parameters to 2checkout’s purchase routine), to the end of the order process (returning to the Approved URL defined by the vendor).

It is true that if a vendor defines an approved URL that allows access to the downloadable product/service they are selling, and the vendor takes no further security precautions, someone could download the product/service by including the ‘demo=Y’ parameter.

The ability to control the demo parameter is available from inside the 2Checkout system. You can choose from the following 3 options inside of your 2Checkout account to control the use of the Demo parameter. Those choices are:

• On: Using this setting all sales will be treated as demo, regardless of any parameter value.
• Off: Using this setting all sales will be treated as live, regardless of any parameter value.
• Parameter: Using this setting a demo parameter sent to the purchase routine will control the demo setting.

In the new Vendor Admin, this option is under “Account > Site Management”:

In the Classic Sellers Area (V2), this option is under “Look and Feel”:

It is not recommended to provide a downloadable product/service to a customer immediately after a sale completes by means of a return to the Approved URL. It is recommended to allow the fraud review process to complete before providing your customer with the product/service.

We realize that some vendors may not wish to wait for the fraud review process to complete before providing their customer with a downloadable product/service. For such vendors, the MD5 hash is provided to help verify the authenticity of a sale. We intentionally break the hash code that is passed back if the ‘demo=Y’ parameter is used. You can compare the value of the hash we pass back with the value of what the hash should be (this needs to be calculated on your end). This will allow you to determine whether or not to provide the customer with the downloadable product/service. It should be noted that when using this method to provide a downloadable product/service immediately, you do run the risk of having your product/service stolen by someone placing a fraudulent order with a stolen credit card.

For full details on using the MD5 hash please refer to the article How do I use the MD5 Hash?

If you choose to provide a downloadable product/service immediately after a sale using the Approved URL, and do not check the MD5 key which is passed to the Approved URL to verify the validity of the sale before providing a customer with a product, then you are accepting the risk that your product may be taken without being paid for by someone who includes the ‘demo=Y’ parameter.

Because MD5 is designed to fail in demo mode for security reasons, the only way to test the MD5 hash is to perform a live test order using a real credit card. Note that if you cancel the test order from the admin panel immediately afterward, no transaction fees will apply to the sale.

The MD5 hash is provided to help you verify the authenticity of a sale. This is especially useful for vendors that sell downloadable products, or e-goods, as it can be used to verify whether sale actually came from 2Checkout and was a legitimate live sale. We intentionally break the hash code for demo orders so that you can compare the hash we provide with what it should be to determine whether or not to provide the customer with your goods or not.

To calculate the MD5 hash, you need to make a string that contains the information described below and pass it in as the value to your scripting languages MD5 function. Below is an example:

md5 ( secret word + vendor number + order number + total )

The secret word is set by yourself on the Site Managment page. The vendor number is your numerical vendor/seller ID number. The order number is the order number for the sale. The total is the numerical value for the total amount of the sale.

Demonstration:

Secret Word => tango
Vendor Number => 123456
Order Number => 9999999
Total => 5.99

md5hash = md5( tango12345699999995.99 )

It is important to note that the MD5 hash must also be converted to upper case letters for a clean comparison. How this is done depends on the scripting language that you use. Below are some examples of how to compute the MD5 hash using PHP. This should illustrate how this process works.

The following code would be applicable to orders placed using our Plug and Play cart and our proprietary third party set of parameters.

$string_to_hash = “tango123456″ . $_POST[”order_number”]
.
$_POST[”total”];
$check_key = strtoupper(md5($string_to_hash));

echo (”Returned MD5 Hash : ” . $_POST[”key”]
. “<BR>”);
echo (”Should be : ” . $check_key . “<BR>”);

if($check_key == $_POST[”key”]){
// At this point the expected key and the returned key match, so the customer should be given access to the download
// This is where you would want to put the code or page for the download
echo (”<center>They match!</center>”); }
else {
// At this point the keys do not match, so either the attempt was fraudulentor a demo order
// This is where you would put the code or page for an unsuccessful attempt
echo (”<center>They do NOT match! Was this a demo order?</center>”);}

The following code would then be applicable to orders placed using the Authorize.net
parameter set.

$string_to_hash = “tango123456″ . $_POST[”x_trans_id”]
.
$_POST[”x_amount”];
$check_key = strtoupper(md5($string_to_hash));

echo (”Returned MD5 Hash : ” . $_POST[”x_MD5_Hash”]
. “<BR>”);
echo (”Should be : ” . $check_key . “<BR>”);

if($check_key == $_POST[”x_MD5_Hash”]){
// At this point the expected key and the returned key match, so the customer
should be given access to the download
// This is where you would want to put the code or page for the download
echo (”<center>They match!</center>”); }
else {
// At this point the keys do not match, so either the attempt was fraudulent
or a demo order
// This is where you would put the code or page for an unsuccessful attempt echo (”<center>They do NOT match! Was this a demo order?</center>”);}

The MD5 hash is also provided to help you verify the authenticity of INS posts. The MD5 hash that is sent with INS posts is a hash of sale_id + vendor_id + invoice_id + secret word in the md5_hash parameter.

Demonstration:

sale_id => 9999999999
vendor_id => 123456
invoice_id => 1111111111
Secret Word => tango
md5hash = md5( 99999999991234561111111111tango )

The following code would be applicable to orders placed using our Plug and Play cart and our proprietary third party set of parameters.

$string_to_hash = $_POST[“sale_id”] . “123456” . $_POST[“invoice_id”] . “tango”;
$check_key = strtoupper(md5($string_to_hash));
echo (“Returned MD5 Hash : ” . $_POST[“md5_hash”]
. “
”);
echo (“Should be : ” . $check_key . “
”);
if($check_key == strtoupper($_POST[“md5_hash”])){
// If the expected key and the returned key match the authenticity of the message has been validated.
echo (”They match!”); }
else {
// At this point the keys do not match.
// This is where you would put the code for an unsuccessful attempt.
echo (“They do NOT match!”);}

Please note that help with implementing the MD5 hash into your return script is beyond the realm of 2Checkout.coms support. This document is provided merely as a reference document to help point you in the right direction. How the MD5 hash is computed is Dependant upon the scripting language that you use. Implementation of any MD5 hash checking is solely on your end or your server. 2Checkout.com can not provide you with support in implementing this or troubleshooting your implementation. We provide you with the hashes as a convenience to help you protect your digital goods.

The following links may be of interest to you if you are looking for more information on the MD5 algorithm and its use.

http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html
http://en.wikipedia.org/wiki/MD5
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemSecurityPolicyHashClassMD5Topic.asp

We have also intentionally designed the MD5 hash not to work for demo sales as was explained earlier. If the sale is in demo mode, the order number used to create the hash will be forced to a one, which will cause the hashes to be different when you compare them. If you wish to test the hashes, you’ll have to place a live test order using a real credit card number.

No, you do not need an SSL server in order to integrate your site with 2CO.

All payment transactions take place on the 2CO SSL server.