<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Merchant Account Blog &#187; Ecommerce</title>
	<atom:link href="http://www.merchantequip.com/merchant-account-blog/category/ecommerce/feed" rel="self" type="application/rss+xml" />
	<link>http://www.merchantequip.com/merchant-account-blog</link>
	<description>Merchant Accounts, Ecommerce, Processing Equipment</description>
	<lastBuildDate>Wed, 18 Jan 2012 15:32:56 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Zappos Breach &#8211; All is well, no credit card data was stolen&#8230;</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen#comments</comments>
		<pubDate>Wed, 18 Jan 2012 15:32:56 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantequip.com/merchant-account-blog/?p=1603</guid>
		<description><![CDATA[The online retailer Zappos just had a data security breach where they lost 24 Million customer&#8217;s personal information records. This loss included names, addresses, email and phone numbers, encrypted passwords, but did not include credit card information. No doubt that thoughtful security planning prevented the loss of credit card or financially sensitive information. However, it [...]]]></description>
			<content:encoded><![CDATA[<p>The online retailer Zappos just had a data security breach where they <a href="http://www.informationweek.com/news/security/attacks/232400441">lost 24 Million customer&#8217;s personal information records</a>. This loss included names, addresses, email and phone numbers, encrypted passwords, but did not include credit card information.</p>
<p>No doubt that thoughtful security planning prevented the loss of credit card or financially sensitive information. However, it doesn&#8217;t really lessen the reality that the repercussions from the Zappos breach could be huge. Does data security go far enough if we accept that personal information is completely acceptable to be lost as long as financial information is not?</p>
<p><img class="alignright size-full wp-image-1604" title="iStock_000017590354XSmall" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2012/01/iStock_000017590354XSmall.jpg" alt="" width="359" height="334" />With the amount of personal information that was obtained in the Zappos breach, the thieves have a very lucrative marketing or hacking information package.</p>
<p><strong>On the marketing side</strong></p>
<p>Companies pay a lot of money for targeted marketing lists like the one that Zappos inadvertently provided. Let&#8217;s see, here&#8217;s a list of 24 million people that definitely buy things online, most likely shoes or clothing items, FIRE AWAY&#8230;</p>
<p>This information is a telemarketer or direct marketer&#8217;s dream, and they can target these known shoppers via phone, mail, and email.</p>
<p><strong>On the hacking side</strong></p>
<p>I can almost guarantee that Zappos customers are going to receive an onslaught of highly engineered spam, viruses, offers, and everything else to their emails. At the same time they are going to start getting physical spam, and scam offers, and probably are going to see telemarketing scams as well. There&#8217;s really no limit to how the information can be used for malicious purposes. Scam companies and hacking groups trying to install mallware and spyware are extremely efficient and proficient at developing well planned attacks on unsuspecting users. There are millions of computers called zombie computers because they are being used to send spam and other malicious activities without the knowledge of their owners. Expect some more.</p>
<p>As to the encrypted passwords. Websites typically use 1-way hashing mechanisms for password storage. This means that the password is encrypted, but cannot be decrypted by any reasonable means. The caveat to this is that if the hacker knows how the password was hashed, they can create a huge list of hashes and compare them to find the original. This is a very targeted attack, but with 24 million passwords it&#8217;s worth a lot of effort. They will begin finding real password very quickly if they discover the hashing mechanism. Since many users do not use unique passwords between websites, the direct loss from being able to log into user&#8217;s bank accounts, or other websites will be significant. I always recommend using a unique password with every site you log into, and <a href="http://www.roboform.com/php/land.php?affid=jeste&amp;frm=frame1">use a password manager like roboform</a>.</p>
<p><strong>The reality</strong></p>
<p>The reality of this situation is that Zappos is owned by Amazon.com. I can guarantee that Zappos has some stout security in place, and yet one of the largest, most tech oriented companies on earth, just had a data loss of 24 million records. This tells me that that standards we have in place for protecting data, especially non-sensitive data, are not enough. We should not just be protecting financially sensitive data, but all customer data. Sure there may be no direct cost in replacing bank cards, or obtaining new bank account numbers, stopping checks, or posting chargebacks, but the effect to the customer when you lose their data can be remarkable. We&#8217;ve yet to see the actual damages that this breach causes, but with the sheer amount of information out there, there could be substantial damages.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Credit card logo generator and API &#8211; Updated</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1498/credit-card-logo-generator-and-api</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1498/credit-card-logo-generator-and-api#comments</comments>
		<pubDate>Fri, 26 Aug 2011 19:30:37 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>
		<category><![CDATA[Tools]]></category>

		<guid isPermaLink="false">http://www.merchantequip.com/merchant-account-blog/?p=1498</guid>
		<description><![CDATA[We&#8217;ve just completed a simple credit card logo generator and have included an API for web designers to use as well. The API supports different logos for card issuers, paypal, google checkout and a few other. A developer can use the API to specify the size, background color and the order of the logos that [...]]]></description>
			<content:encoded><![CDATA[<p>We&#8217;ve just completed a simple <a href="http://www.merchantequip.com/information-center/credit-card-logos/">credit card logo generator</a> and have included an API for web designers to use as well.</p>
<p>The API supports different logos for card issuers, paypal, google checkout and a few other. A developer can use the API to specify the size, background color and the order of the logos that they need on their website.</p>
<p><strong>Update 08-2011</strong> &#8211; Added ebillme and 2checkout.com logos.</p>
<p>Here&#8217;s a quick tutorial and a few examples of how to use the API.</p>
<ol>
<li>Create an image tag with the root url: https://www.merchantequip.com/image/</li>
<li>Next add the <strong>bgcolor</strong> parameter to specify a 3 or 6 character HEX background color for your logo. If you do not know the background color: FFF is white, 000 is black. Here is a <a href="http://html-color-codes.com/">full HEX color chart</a>. There are also a variety of <a href="http://www.colorzilla.com/firefox/">browser addons</a> if you need to match the exact colors of your website.</li>
<li>Next specify the actual <strong>logos</strong> that you would like to add to your site, in the order you would like to display them. Separate the logos with a pipe | character. Example: v|m|a|d for Visa then MasterCard followed by Amex and Discover.<strong>All of the available logo codes are:</strong>
<ul>
<li>v = Visa</li>
<li>m = MasterCard</li>
<li>d = Discover</li>
<li>a = Amex</li>
<li>g = Google Checkout</li>
<li>p = Paypal</li>
<li>bml = Bill Me Later</li>
<li>ec = eCheck</li>
<li>jcb = JCB</li>
<li>dc = Diners Club</li>
<li>s = Solo</li>
<li>me = Maestro</li>
<li>mb = Moneybookers</li>
<li>az = Amazon Payments</li>
<li>in = Interac</li>
<li>ebm = eBillme</li>
<li>2co = 2checkout.com</li>
</ul>
</li>
<li>Finally specify the <strong>height</strong> of the logos. The images currently come in 32px and 64px, so size accordingly allowing for a small margin around the images. <em>We will be allowing for dynamic resizing in the future, but for now the only 2 sizes supported are 32px and 64px. Any additional height will be added as a margin.</em></li>
</ol>
<p>The actual image url should look like <em>(these are all generated through this exact API)</em>:</p>
<p><strong>https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=v|m|a|d&amp;height=32</strong></p>
<p>The image HTML will look like:</p>
<p>&lt;img src=&#8221;https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=v|m|a|d&amp;height=32&#8243; /&gt;</p>
<p>The logo above will display as:</p>
<p><img src="https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=v|m|a|d&amp;height=32" alt="Card Logos" /></p>
<p>Here&#8217;s the same logo using the larger image sizes:</p>
<p><img src="https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=v|m|a|d&amp;height=64" alt="Card Logos" /></p>
<p>Here&#8217;s all of the currently available logos:</p>
<p><img src="https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=v|m|a|d|p|g|ec&amp;height=64" alt="Card Logos" /><br />
<img src="https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=jcb|dc|bml|s|sw|mb|az&amp;height=64" alt="Card Logos 2" /><br />
<img src="https://www.merchantequip.com/image/?bgcolor=FFFFFF&amp;logos=in|me|wu|ebm|2co&amp;height=64" alt="Card Logos 3" /></p>
<p>While this tool is free to use we greatly appreciate a backlink or credit if you are using images that are hosted through the API. These images are all served securely over SSL, so they may be used on secure/SSL websites and ecommerce sites without errors.</p>
<p>If you have no idea of what an API is or just need logos for your website, please use the <a href="http://www.merchantequip.com/information-center/credit-card-logos/">credit card logo generator</a> and ignore this post.</p>
<p>Thanks again.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1498/credit-card-logo-generator-and-api/feed</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>30 Second Fraud Checklist for Ecommerce Merchants</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1004/30-second-fraud-checklist-for-ecommerce-merchants</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1004/30-second-fraud-checklist-for-ecommerce-merchants#comments</comments>
		<pubDate>Wed, 17 Mar 2010 20:36:13 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Fraud]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1004</guid>
		<description><![CDATA[Credit card fraud and online ordering fraud has hampered ecommerce merchants since the first credit card payment was taken over the internet. Because fraud is still successful, and because there is virtually no way to go after someone you suspect of fraud, it is still a plague to website owners trying to run a business [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/03/online-fraud.jpg"><img class="alignright size-full wp-image-1016" title="online-fraud" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/03/online-fraud.jpg" alt="" width="250" height="250" /></a>Credit card fraud and online ordering fraud has hampered ecommerce merchants since the first credit card payment was taken over the internet. Because fraud is still successful, and because there is virtually no way to go after someone you suspect of fraud, it is still a plague to website owners trying to run a business on the internet. Online fraud is especially troublesome to online retailers, because they end up losing twice, first when the merchandise they shipped is not recoverable, and second when the real cardholder makes a chargeback. Now they lose the merchandise and the money they would have collected for it. There are numerous fraud screening applications designed to help ecommerce merchants prevent accepting and shipping fraudulent orders. However, many ecommerce sites aren&#8217;t even covering the most basic of fraud screening principals.</p>
<p>Here is 10 items that should be checked on every order before shipping. If you do nothing else for fraud screening at least cover these basic principals to help prevent some of the more obvious fraud.</p>
<p>If any of these are true, it&#8217;s a good idea to further review the order, or contact the person making the purchase before shipping.</p>
<ol>
<li>Billing and Shipping Addresses Don&#8217;t Match</li>
<li>Requesting Overnight Shipping</li>
<li>Order is for Multiple Quantities of the Same Item</li>
<li>Items Being Ordered are Mainly of High Value</li>
<li>Order is for Uncommonly Purchased Items</li>
<li>Different but Related Products Being Ordered</li>
<li>AVS and/or CVV Verification Failed</li>
<li>Customer Made Several Unsuccessfully Attempts Before the Transaction was Approved</li>
<li>Customer&#8217;s phone number and/or email look unconventional</li>
<li>Order is Being Shipped to Africa, Asia, or Eastern Europe</li>
</ol>
<p><strong><span id="more-1004"></span>1. Billing and Shipping Addresses Don&#8217;t Match</strong></p>
<p>This should be the first sign of potential trouble. While not impossible, it is rare for fraudulent orders to be shipped and billed to the same address. Someone making a purchase fraudulently will often have the item shipped to a forwarding address or other location that they are not personally associated with.</p>
<p>It is common for shoppers to ship to their home or business address which may be different from their billing address. Nevertheless, it&#8217;s a good idea to at least take a look at orders that do not have matching shipping or billing addresses. If an order is being billed to Omar Patel in Houston, and being shipped to John Smith in Seattle, you may want to ask why&#8230;</p>
<p><strong>2. Requesting Overnight Shipping</strong></p>
<p>While it&#8217;s completely reasonable for a customer to want their order ASAP, expedited shipping is a very common trait of fraudulent orders. The thief needs to get the merchandise as quickly as possible before a chargeback is made. With slower shipping methods, the merchant has the opportunity to halt the shipment if they receive a chargeback, or identify the order as fraud, which would make nullify the efforts of the thief.</p>
<p><strong>3. Order is for Multiple Quantities of the Same Item</strong></p>
<p>Many times, fraudulent orders are made with the intention of reselling the merchandise on eBay, Craigslist or locally. Multiple items make an easier sale and easier money especially if the items are in high demand.</p>
<p>Depending on your industry you may often get orders for multiple items, so this rule applies much less to some industries. For us, we often get orders for 10 or more credit card terminals as many businesses have multiple locations. Over time, you should be able to better identify common ordering trends.</p>
<p><strong>4. Items Being Ordered are Mainly of High Value</strong></p>
<p>As with above, since many fraudulent orders are placed with the intention of reselling the merchandise, the most expensive merchandise often yields the greatest rewards. The merchandise can be quickly sold and the thief can makes a decent profit even when discounting 50% or more. The higher the value of the merchandise to you, the higher the value to someone trying to steal it.</p>
<p>If your average order is $200, you should definitely take a closer look when someone places an order for $10,000. Also, keep in mind that the larger the order, the more damage to your business if a fraudulent order is successfully placed.</p>
<p><strong>5. Order is for Uncommonly Purchased Items</strong></p>
<p>I&#8217;m not entirely clear on the reasoning behind this, but it&#8217;s not uncommon for fraudulent orders to be for items that are rarely purchased. Most likely it is due to careless research on the thieves part. If you sell thousands of orders per year and have never sold some particular item, I would be suspicious when someone comes along wanting it. There&#8217;s usually a reason why some products sell a lot and why others never sell. It&#8217;s not common for only 1 customer ever to be interested in an item that you offer.</p>
<p>New ecommerce sites will have a hard time with this rule, but once you establish some sales history and if you really know your products, it&#8217;s easy to spot and flag orders with uncommon items in them.</p>
<p><strong>6. Different but Related Products Being Ordered</strong></p>
<p>Let&#8217;s assume you sell LCD TV&#8217;s online. It&#8217;s very common for someone to come along and purchase a single TV. Maybe you have a sale and someone purchases several TV&#8217;s on sale, still a completely reasonable scenario.</p>
<p>Now, let&#8217;s say someone orders 5 TV&#8217;s, and every one is a different brand and size. This should immediately raise a red flag. Yes, it&#8217;s possible that someone wants 5 completely different TV&#8217;s, but purchasing products like this is not a common shopping or even human behavior and warrants further investigation.</p>
<p><strong>7. AVS and/or CVV Verification Failed</strong></p>
<p>While the majority of the <a href="http://www.merchantequip.com/merchant-account-blog/284/only-half-of-top-ecommerce-sites-require-card-verification">largest ecommerce sites still do not require CVV</a>, it&#8217;s a really <a href="http://www.merchantequip.com/merchant-account-blog/415/why-cvv-is-worthless-and-why-its-not">good idea for you to</a>. If your customers are US based, requiring a positive AVS zip code match is also a good idea. AVS verifies the address of the cardholder, and CVV verifies that the person placing the order has at least had the physical credit card in their possession. Even if  the card number was stolen, odds are the thief does not have the CVV number unless the entire card was stolen.  If the entire card was stolen, there&#8217;s a good chance that the owner would have canceled it already. CVV costs nothing, and I strongly recommend all merchants to at least require it to be submitted. Because the number can be worn off the card, I do not always recommend a positive match, but this is something you need to assess specifically for your business and your customers. When in doubt, require it!</p>
<p><strong>8. Customer Made Several Unsuccessfully Attempts Before the Transaction was  Approved</strong></p>
<p>This works in conjunction with AVS and CVV verification. If someone is attempting to place orders using a stolen card, it&#8217;s common for several declines due to an incorrect address, expiration date, or CVV.  Keep a close eye on customers that submit multiple declined or AVS/CVV mismatch transactions. 1 or 2 errors may be common, but if you start seeing a group of attempts it may be a sure sign of fraud.</p>
<p>If you start seeing hundreds or even thousands of attempts it is almost certainly an entirely <a href="http://www.merchantequip.com/merchant-account-blog/36/what-does-a-fraudulent-transaction-look-like">different type of fraud called carding</a>. This type of fraud can be very costly to your business even if you never lose any merchandise, so it&#8217;s important that you promptly address and correct the situation that is allowing it.</p>
<p><strong>9. Customer&#8217;s phone number, email and/or shipping information look unconventional</strong></p>
<p>You wouldn&#8217;t believe how many times fraudulent orders use incorrect, fake, or just plain goofy email addresses, phone numbers, and ship-to information. If you get bounced receipt emails, see an email like fbi.gov, see phone numbers like 555-555-5555, or are shipping to Mickey Mouse, you should probably be concerned about the order being fraudulent. Additionally, if the phone number contains a country code, or incorrect area code, there&#8217;s a good chance that someone just typed the first digits they could into the phone number box.</p>
<p>Most business and personal land-line phone numbers can be researched just by entering them into a google search. At the very least you can figure out if the area code matches the billing or shipping address, and if the number is actually valid.</p>
<p><strong>10. Order is Being Shipped to Africa, Asia, or Eastern Europe</strong></p>
<p>I don&#8217;t want to discriminate against people in any particular country, but it&#8217;s a fact that a lot of fraud originates in a few select regions and countries of the world. Unless you have experience in international-commerce, it&#8217;s a good idea to only cater to your own country, or ones you know and trust very well. I wouldn&#8217;t even consider shipping a product to most African countries, East Asia, Eastern Europe and Russia. Also, some areas like Amsterdam are notorious for credit card fraud. Be very careful when accepting international orders.</p>
<p>Even if an order isn&#8217;t fraudulent, international orders can introduce a multitude of additional customs, credit card processing, and legal requirements, and can make processing returns very difficult. Something as simple as shipping from the US to Canada, can present a  number of problems and costs that many website owners are not prepared to deal  with. I strongly suggest doing a lot of research and finding someone who has real experience before venturing into international shipping.</p>
<p><strong>Final words&#8230;</strong></p>
<p>I can guarantee that every online merchant will face some form of credit card fraud. Credit card fraud is a minor inconvenience to some, and will end others&#8217;  online ventures. Not all merchants need to use some of the more advanced fraud screening methods out there, but everyone should cover the basics.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1004/30-second-fraud-checklist-for-ecommerce-merchants/feed</wfw:commentRss>
		<slash:comments>10</slash:comments>
		</item>
		<item>
		<title>How to re-bill your customer&#8217;s credit card, without storing it!</title>
		<link>http://www.merchantequip.com/merchant-account-blog/827/how-to-re-bill-your-customers-credit-card-without-storing-it</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/827/how-to-re-bill-your-customers-credit-card-without-storing-it#comments</comments>
		<pubDate>Thu, 29 Oct 2009 21:10:44 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=827</guid>
		<description><![CDATA[Many times business and website owners want to store credit card numbers for later. This allows re-billing customers for recurring orders, and allows easier checkout for repeat customers on a website. If a business decides they want to actually store credit card numbers, they are subjected to stricter PCI-DSS standards, and run a real risk [...]]]></description>
			<content:encoded><![CDATA[<p>Many times business and website owners want to store credit card numbers for later. This allows re-billing customers for recurring orders, and allows easier checkout for repeat customers on a website.</p>
<p>If a business decides they want to actually store credit card numbers, they are subjected to stricter <a href="https://www.pcisecuritystandards.org/">PCI-DSS</a> standards, and run a real risk of losing customer data just by the fact that they have it. Apart from PCI, it&#8217;s difficult to securely store credit card data as there is a multitude of technical aspects to doing it safely. If you lay it all out on paper, there is a huge amount of work, ongoing management, and liability in storing credit card numbers. </p>
<p><strong>But, sometimes we still need to store credit card numbers, so how do we do it?</strong></p>
<p>We simply let somebody else store it for us. If we outsource our credit card number storage to another party, we are no longer liable for that data. This is still your customer&#8217;s data, so your reputation is on the line, but not necessarily your wallet. What&#8217;s even better is that with some of today&#8217;s available services, outsourcing this can give us an easier method of re-billing our customer than if we could easily store credit cards.</p>
<p><strong>Who can we store these with?</strong></p>
<p>This is the easy part. Your payment gateway may have a customer storage mechanism, or customer vault. <em>If it doesn&#8217;t, find one that does.</em></p>
<p>What this does is store your customer&#8217;s information and credit card number in the payment gateway&#8217;s secure database. If you need to charge your customer again, you simply reference their customer number and the amount you wish to charge. You can do this manually through the administrative virtual terminal of your payment gateway, or you can often do it directly through your website using an API. You can also setup recurring payments, refund, void, or credit via a customer&#8217;s stored card.</p>
<p>With a system like this, a developer can create a custom recurring billing system, or a user friendly &#8220;remember card&#8221; feature with your ecommerce site&#8217;s checkout system.</p>
<p><strong>Which gateways support this?</strong></p>
<p>The <a href="https://www.nmi.com/">Network Merchants Gateway</a> which we <a href="http://www.saynotoflash.com/scripts/network-merchants-api-php-class-script/">developed an integration module</a> a few weeks ago, supports customer storage at a very low cost per month. Network Merchant&#8217;s customer storage is called the Customer Vault.</p>
<p><a href="http://www.authorize.net/">Authorize.net</a> has a similar system called the <a href="http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/">Customer Information Manager</a>. </p>
<p>There&#8217;s definitely a number of other gateways that have custom vault type systems as well. These can be integrated with a website, charged manually, or even integrated with a desktop application. A customer vault is a responsible way to outsource credit card number storage while still being able to use them.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/827/how-to-re-bill-your-customers-credit-card-without-storing-it/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Free Network Merchants PHP Class</title>
		<link>http://www.merchantequip.com/merchant-account-blog/819/free-network-merchants-php-class</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/819/free-network-merchants-php-class#comments</comments>
		<pubDate>Wed, 07 Oct 2009 19:21:19 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=819</guid>
		<description><![CDATA[We&#8217;ve just finished a PHP Integration class for the Network Merchants Payment Gateway. This script integrates with the Network Merchants Direct Post API, and the Network Merchant customer vault API. The Direct Post API allows processing credit cards and electronic checks. The Customer Vault allows merchants to store their customers credit card and check information [...]]]></description>
			<content:encoded><![CDATA[<p><img src="https://www.nmi.com/images/NMI.gif" alt="" style="float:right;" />We&#8217;ve just finished a PHP Integration class for the Network Merchants Payment Gateway.</p>
<p>This script integrates with the Network Merchants Direct Post API, and the Network Merchant customer vault API.</p>
<p>The Direct Post API allows processing credit cards and electronic checks. The <a href="https://www.nmi.com/newsmedia/index.php?ann_id=14">Customer Vault</a> allows merchants to store their customers credit card and check information in Network Merchant&#8217;s secure customer vault. The API allows charging customers stored in the vault without a merchant ever storing a credit card number.</p>
<p><a href="http://www.saynotoflash.com/scripts/network-merchants-api-php-class-script/">View and download the class here &raquo;</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/819/free-network-merchants-php-class/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>How to accept credit cards on your website</title>
		<link>http://www.merchantequip.com/merchant-account-blog/227/how-to-accept-credit-cards-on-your-website</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/227/how-to-accept-credit-cards-on-your-website#comments</comments>
		<pubDate>Wed, 07 Feb 2007 17:47:06 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Guides]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/archives/227</guid>
		<description><![CDATA[I absolutely hate writing this post, because it is so generic, broad and over-done. But, I was searching on Google today to see what was out there, and as usual there are very few objective sources that are worth reading on the topic. Apart from that, I don&#8217;t have a guide on this site, and [...]]]></description>
			<content:encoded><![CDATA[<p>I absolutely hate writing this post, because it is so generic, broad and over-done. But, I was searching on Google today to see what was out there, and as usual there are very few objective sources that are worth reading on the topic. Apart from that, I don&#8217;t have a guide on this site, and seeing as how this is a merchant account blog, it sort of fits the genre. Without any further rambling&#8230;</p>
<p>Accepting credit cards on a website is absolutely necessary for the success of any online sales efforts. While there are several other available payment methods for websites, credit cards surpass every other one because of their wide use and convenience.</p>
<p>There are two types of companies that can enable a website to accept credit cards. The first is a 3rd party processor, and the second is a merchant service provider (called an MSP, or ISO). The primary differences between 3rd party processors and MSPs are the way a website integrates with their service, the liability that the website owner has over the transactions that they process, and the price that a they will pay for the ability to accept credit cards. 3rd party processors include companies like Paypal, Google Checkout, 2checkout.com, CCnow, Clickbank, and many more.</p>
<p><strong>The difference between MSP&#8217;s and 3rd party processors:</strong></p>
<p><strong>MSP&#8217;s</strong></p>
<ul>
<li>The business apply&#8217;s for a merchant account directly with a MSP.</li>
<li>Business is personally liable for everything that they process.</li>
<li>Customer&#8217;s credit card statements have the business name on them.</li>
<li>Use with a Payment Gateway (Seamless integration available).</li>
<li>Some fixed monthly fees in addition to processing costs.</li>
<li>Possible setup fee.</li>
<li>Possible long term contract requirement.</li>
</ul>
<p><strong>3rd Party Processors</strong></p>
<ul>
<li>Business processes under the name of the 3rd party processor.</li>
<li>Customer&#8217;s credit card statement has 3rd party processors name on it.</li>
<li>Any dispute is made through the 3rd party processor and not the processing bank.</li>
<li>Business and customer have limited protection from being ripped off.</li>
<li>Must use 3rd party processors checkout system (Paypal has one exception).</li>
<li>No fixed monthly fees.</li>
<li>Some have setup fees.</li>
<li>Most have high processing costs (Paypal and Google Checkout don&#8217;t).</li>
<li>No contracts.</li>
<li>Business is partially liable for the transactions that they process.</li>
</ul>
<p><strong>Which should a business use?</strong></p>
<p>Assuming that you are based in the US, this depends mainly on how much business you do, the type of products you sell, how you want to integrate payments into your website, and whether you sell on eBay or not.</p>
<p>For businesses in the US, Paypal is pretty much going to be the lowest cost method of accepting payments that you will find. As much as I personally hate to admit it, it will be very hard to find a company that can beat the cost of paypal. However, paypal has many negative attributes which often make it a poor solution for serious ecommerce websites.</p>
<p>Personally, I think paypal makes an excellent supplementary payment method, as there is a fair number of online shoppers that prefer to use it.</p>
<ul>
<li><strong>How much you business you do:</strong>Merchant accounts have fixed monthly fees associated with them. If you are only processing a few dollars a day, it is simply a waste of money to use a merchant account. 3rd party processors don&#8217;t have fixed monthly fees, and will be a more cost-effective solution for low volume businesses or an individual. If you do a lot of business, then a merchant account will give you better control over the funds that you process, and how your payment method integrates into your website. Many people consider the threshold of switching from a 3rd party processor to a MSP at about $1000 per month in processing. Personally, I would switch to a merchant account at about $500 per month, so that I could provider a cleaner experience for my customers. But either way, these aren&#8217;t huge volumes of processing before a merchant account may be warranted.</li>
<li><strong>The type of products you sell:</strong>Many product types are considered high risk. High risk refers to products or services that carry an increased risk of being charged back, or being obtained by or sold to fraudulent buyers. A few examples of high risk businesses include anything adult related, travel related, online pharmacy, and download-able products. Online in general is much higher risk than retail. On a personal note, I think that most online businesses will experience some sort of fraud in their online ventures. Neither 3rd party processors or MSP&#8217;s like providing services to high risk businesses. In these cases a business will have to contact everyone to find a company that can provide service to them. In some cases they may have to process through an offshore merchant account provider.</li>
<li><strong>How you want to integrate payments into your website: </strong>If you want a completely seamless system where your customer never leaves your website, then you are going to need a merchant account and a payment gateway. Payment gateways generally have <a href="http://www.merchantequip.com/merchant-account-blog/archives/177">two integration methods</a>, but I only recommend using an API method of integration. 3rd party processors require your customers to fill out their information on a website owned by the 3rd party processor. A seamless integration method is considered by many to be fundamental in providing a smooth and efficient shopping experience. Paypal does provide a system called payments pro, which is a step in the seamless direction, but it is difficult to integrate into a website, and still creates some usability barriers. If you look on any major ecommerce website, you will find that they are all using a seamless integration with their payment processing method. 3rd party processors may be an alternative payment method, but they are rarely the primary method for a serious company.</li>
<li><strong>Do you sell on eBay? </strong>If you sell on eBay, you should accept Paypal. Paypal integrates seamlessly with the eBay checkout system, and the majority of eBay users <strong>expect</strong> to be able to use Paypal to complete their purchase. Merchant accounts are difficult to integrate with eBay and must always rely on multiple independent systems for them to work smoothly and automatically. Businesses that sell a lot on eBay will probably look into one of these checkout management systems at some point, but Paypal is the perfect solution for the majority of smaller eBay businesses.</li>
</ul>
<p><span style="font-weight: bold">Now that you have your processing method:</span></p>
<p>I am making the assumption that you already have a shopping cart in place on your website. This can either be a custom designed system, or can be a pre-made cart system like oscommerce, zen cart, and many of the other popular carts.</p>
<p>If you went the merchant account direction, you will also need a payment gateway. It is easiest to get a payment gateway from the same company you are getting a merchant account through. If you already know what payment gateway you want, make sure that the merchant account provider can set this up for you. If you don&#8217;t know what payment gateway you want, Authorize.net is always a safe bet. There are <a href="http://www.merchantequip.com/merchant-account-blog/processing-information/payment-gateway-list/">many payment gateways available</a>, with the most common being Authorize.net, and Verisign. You will want to use a payment gateway that has an API (Application Programming Interface) method of integration. The API is what allows your website to transparently integrate with the payment gateway.</p>
<p align="center"><img src="http://www.merchantequip.com/merchant-account-blog/images/checkout-comp.gif" /></p>
<p style="font-weight: bold">Requirements to process on your website:</p>
<ol>
<li>A SSL (Secure Socket Layer) Certificate <span style="font-style: italic">(needed if you use a payment gateway API)</span>.</li>
<li>A shopping cart system <span style="font-style: italic">(This can be custom made or you can use </span><a href="http://www.merchantequip.com/merchant-account-blog/processing-information/shopping-cart-software/" style="font-style: italic">ready made shopping cart software</a><span style="font-style: italic">)</span>.</li>
<li>Integration of your payment gateway or 3rd party checkout system.</li>
<li>Merchant account providers also have a list of <a href="http://www.merchantequip.com/merchant-account-blog/archives/44">requirements to setup an ecommerce merchant account.</a> I recommend making sure that as many as possible are met before applying for a merchant account.</li>
</ol>
<p>Depending on whether you have a custom designed or a generic shopping cart system, it can be as easy as pressing a button, or as hard as writing a complex integration script, to integrate your website with the payment gateway. Most shopping carts that are widely used will have a module or plug-in to integrate with most of the popular payment gateways. Custom carts will need a custom payment module, which should be coded by the person who designed the cart or another competent programmer. Here is a guide on <a href="http://www.merchant-account-services.org/article/authorize-net-php-integration">how to integrate Authorize.net with a website</a> using php5. Also, if you are interested in purchasing a Authorize.net integration script, <a href="http://www.authnetscripts.com/">authnetscripts.com</a> has scripts for PHP, ASP, PERL, and Cold Fusion. I have used their scripts myself and highly recommend them. The price of one of these scripts is far less than hiring a programmer to write one for you. Integration tutorials for most payment gateways are available in just about every programming language, but again these should be programmed by a professional. If you need to hire someone to do the integration for you, I recommend services like <a href="http://www.getafreelancer.com/">getafreelancer.com</a> and <a href="http://www.rentacoder.com/">rentacoder.com</a>. Make sure to pick a service provider with positive feedback, and make price a secondary factor. Here is a brief guide on <a href="http://www.merchantequip.com/merchant-account-blog/archives/150">how to use freelance marketplaces</a>.</p>
<p>If you do use a payment gateway, make sure you are not storing credit card numbers or other sensitive information unless you know exactly what you are doing, how to properly encrypt the data that is being stored, your server is PCI compliant, and your website does not have <a href="http://www.ecommerce-blog.org/archives/website-security-auditing/">security vulnerabilities</a>.</p>
<p><strong>Once you&#8217;re integrated:</strong></p>
<p>Once your website is integrated with your payment gateway or 3rd party processor, you are ready to start accepting payments. This whole process is not really as complicated as it seems, and should be takes in steps to prevent problems.</p>
<p><strong>Quick Overview:</strong></p>
<p><strong>Merchant Account / Payment Gateway Flow</strong> -is the order of setting things up that I recommend for the least amount of potential problems.</p>
<ol>
<li>Setup Website</li>
<li>Setup Merchant Account and Payment Gateway</li>
<li>Purchase and Install SSL Certificate</li>
<li>Integrate Website with Payment Gateway</li>
<li>Test Integration, and Run A Real Transaction</li>
<li>Go Live!</li>
</ol>
<p><strong>3rd Party Processor Integration</strong> &#8211; requires less structured planning, but some ordering will make a difference.</p>
<ol>
<li>Setup 3rd Party Processor Account</li>
<li>Setup Website</li>
<li>Integrate Website with 3rd Party Processor</li>
<li>Test and Run A Real Transaction</li>
<li>Go Live!</li>
</ol>
<p>For a better comparison of merchant account and 3rd party processors checkout the <a href="http://www.merchant-account-services.org/article/merchant-accounts-compared">Merchant Account Comparison</a>.</p>
<p>Hopefully this whole process goes smoothly for you. Once everything is complete, you can focus on the marketing and promotion of your ecommerce business. As always, feel free to <a href="http://www.merchantequip.com/merchant-account-blog/contact-us/">contact me</a> if you have a question, or you need some direction on what to do.</p>
<p>Best of luck to you&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/227/how-to-accept-credit-cards-on-your-website/feed</wfw:commentRss>
		<slash:comments>10</slash:comments>
		</item>
		<item>
		<title>Where do data losses actually occur?</title>
		<link>http://www.merchantequip.com/merchant-account-blog/208/where-do-data-losses-actually-occur</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/208/where-do-data-losses-actually-occur#comments</comments>
		<pubDate>Tue, 28 Nov 2006 22:32:21 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Fraud]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/archives/208</guid>
		<description><![CDATA[Most businesses that accept credit cards online have become more aware of Payment Card Industry (PCI) security regulations like CISP, and SDP. What I find to be an interesting figure is that very little data loss actually occurs with online businesses. Roughly 65% of all data security breaches occur at restaurants, the next largest group [...]]]></description>
			<content:encoded><![CDATA[<p>Most businesses that accept credit cards online have become more aware of Payment Card Industry (PCI) security regulations like CISP, and SDP. What I find to be an interesting figure is that very little data loss actually occurs with online businesses.</p>
<p>Roughly 65% of all data security breaches occur at restaurants, the next largest group retail stores claim about 12%, and the remaining percentage is split between every other type of business out there including online. The simple truth is that with all the scrutiny over online businesses, card companies have failed to see the actual problem. It is retail businesses where employees and even customers often have direct access to sensitive data. Online businesses, even with poor security would require someone very knowledgeable in networking and computers to compromise their data. Any average Joe could <a href="http://www.merchantequip.com/merchant-account-blog/archives/149">obtain a credit card skimmer</a> and use it at the restaurant where they work.</p>
<p>What this concludes is that somewhere along the line, card companies ignored where data breaches actually occur, and just decided to target all online businesses. Now everyone has to jump through hoops when for many there is absolutely no risk of a security breach because the information just isn&#8217;t there to steal.</p>
<p>Security is extremely important for all businesses, and protecting cardholders information is every business&#8217;s responsibility. Don&#8217;t store sensitive data if you don&#8217;t have to, and if you do, make absolutely sure you know how to encrypt and store it properly. </p>
<p>Also, if you use any custom made POS software system, you may want to check with the programmer that the system is not storing track data. If it is and you get caught, you can get up to a $100,000 per month fine until it is fixed. That is just a fine for storing the track data, not for an actual data breach which could be <a href="http://weblog.infoworld.com/techwatch/archives/008478.html">significantly higher</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/208/where-do-data-losses-actually-occur/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Accepting payments on eBay</title>
		<link>http://www.merchantequip.com/merchant-account-blog/206/accepting-payments-on-ebay</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/206/accepting-payments-on-ebay#comments</comments>
		<pubDate>Mon, 27 Nov 2006 15:50:27 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/archives/206</guid>
		<description><![CDATA[Ebay has become one of the largest marketplaces for selling in the world. Actually getting money from an eBay auction can be as hard as selling something. Here&#8217;s a quick overview of the different methods of payment you can consider for your eBay auctions. Paypal: Paypal is by far the easiest and most tightly integrated [...]]]></description>
			<content:encoded><![CDATA[<p>Ebay has become one of the largest marketplaces for selling in the world. Actually getting money from an eBay auction can be as hard as selling something.</p>
<p>Here&#8217;s a quick overview of the different methods of payment you can consider for your eBay auctions.</p>
<p><strong>Paypal:</strong><br />
Paypal is by far the easiest and most tightly integrated method of accepting payments on eBay. Paypal is automatically tied into the eBay checkout system, and Paypal is widely used by buyers. There is however a percentage of buyers and sellers that have bad experiences with Paypal, and wont use it. For this reason it is always best to provide at least one supplemental payment method for selling on eBay. But, buyers normally want to use Paypal to pay for auctions and from a sellers perspective it is wise to accept Paypal, even if you have had a negative experience with them. As crazy as this may sound, Paypal auctions almost always sell for much higher than an auctions where Paypal is not accepted. Even an automated credit card acceptance system does not offer a suitable replacement for the wide use of Paypal.</p>
<p><strong>Credit cards:</strong><br />
Credit cards can be tricky to accept on eBay auctions, but are the second most desired method of payment next to Paypal. Depending on how many products you sell, manually accepting orders over the phone from eBay sales can be the perfect solution or simple impossible. There are a variety of pre-made systems that can integrate eBay with your payment gateway and merchant account, but these systems often add unnecessary extra fees to the already high cut that eBay takes. If you run a successful online business, I recommend hiring a programmer to develop an eBay checkout system for your auctions through your existing payment gateway. This creates a much more usable system, and eBay orders can be better integrated with website orders for inventory, customer service, and tracking. </p>
<p><strong>Personal checks:</strong><br />
In my opinion, personal checks are the worst method of payment for eBay auctions that work well enough to consider. Checks are slow, they must clear a bank account, they are prone to bouncing and being lost in the mail, and they create a very poor user experience. With the exception of a few rare occasions, checks are not a convenient, timely, or cost effective method of payments for eBay. The money you save by not using Paypal or accepting credit cards, is most definitely more than offset by the lack of bids you get on your auctions. Nearly every bad experience I have had on eBay was a result of having to send or received a check.</p>
<p><strong>Money orders &amp; cashiers checks:</strong><br />
Money orders and cashiers checks are safe and effective methods of getting paid on eBay. But, they are slow as they have to be mailed by the buyer and deposited into a bank account before the auction item can be shipped. They are best used with high dollar auctions where it is essential that the seller is protected from any buyer fraud or frivolous chargebacks and disputes, and time is not of the utmost importance. For high dollar items, I recommend getting an initial deposit via Paypal or credit card, and accepting the balance by cashiers check. I would consider a high dollar item anything of about $2000 and up.</p>
<p><strong>Cash:</strong><br />
I would not even consider sending or requesting cash through the mail. If you sell locally and are comfortable with meeting your customers, than cash can be a great method of getting paid for your auctions. For most of us, cash is rarely if ever a viable option. For those that do meet their customers, I would highly recommend taking appropriate precautions to protect yourself. If you do not have a business address, I recommend meeting your customers in a public place, not at your residence. Most likely you will never have a problem with a buyer, but it&#8217;s simply not worth the risk to you or your family.</p>
<p><strong>Western Union:</strong><br />
Western union is not an acceptable method of payment for eBay. It is commonly associated with fraud, and a very high chance of someone getting burned exists with western union. I do not recommend using western union for auction payments at all. eBay also warns against it. Just don&#8217;t do it.</p>
<p><strong>Other 3rd party checkout systems:</strong><br />
There are several other common checkout systems that can be used for accepting payments on eBay. Personally, I find most of these systems to offer a poor experience for a customer, but they are still used often enough to mention. <a href="http://www.andale.com/">Andale</a>, <a href="http://www.bidpay.com/">Bidpay</a>, <a href="http://www.vendio.com/">Vendio</a>, and <a href="http://www.usaepay.com/">USAepay</a> are some of the commonly used checkout systems for eBay auctions. These systems have a hosted checkout process for your auction winners. They also help manage your existing auctions, shipping, and have a variety or reporting tools that help you keep track of all of your eBay affairs. All of these services have fees associated with different levels of their services, but they can help sellers that have a large quantity of items to manage.</p>
<p>Using a payment method that your &#8216;<strong>buyers</strong>&#8216; want to use is vital to getting the most out of your eBay auctions. It is important to provide at least two options for payment from your customers, and make it as easy as possible for your customers to pay. One of the largest contributors to a low quantity of bids on auctions is not accepting the payment method that buyers want to use.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/206/accepting-payments-on-ebay/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Integrate a website with Authorize.net</title>
		<link>http://www.merchantequip.com/merchant-account-blog/205/integrate-a-website-with-authorizenet</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/205/integrate-a-website-with-authorizenet#comments</comments>
		<pubDate>Tue, 21 Nov 2006 21:36:10 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/archives/205</guid>
		<description><![CDATA[The merchant account services blog, just came out with a guide on integrating a website with Authorize.net. The guide is written for websites using PHP 5, Curl, and SSL to connect a website to authorize.net using the API method (Known as AIM with Authorize.net). PHP 5 is required for this particular script. There are several [...]]]></description>
			<content:encoded><![CDATA[<p>The <a href="http://www.merchant-account-services.org/blog">merchant account services blog</a>, just came out with a guide on integrating a website with Authorize.net.</p>
<p>The guide is written for websites using PHP 5, Curl, and SSL to connect a website to authorize.net using the API method (Known as AIM with Authorize.net).</p>
<p>PHP 5 is required for this particular script. There are several PHP 5+ functions that will make the script completely incompatible with PHP 4. Unfortunately a good percentage of servers are still using PHP 4. Apart from that, it looks like this guide should be all that a developer needs to successfully integrate authorize.net into a shopping cart system.</p>
<p>I really like the feature where the script automatically retries a transaction 3 times if there is an error. This can be common with payment gateways, and it&#8217;s definitely not good to return an error or declined message if you absolutely don&#8217;t have to. The script also validates the card number using a simple version of the LUHN algorithm to verify the card number against a check-sum, in addition to performing basic card number and expiration date checks. </p>
<p>When it&#8217;s all said and done the script will return an approved, error or declined message for your customer&#8217;s transaction, and you can send them to whatever page or message on your website that you want.</p>
<p>This script is complete, but I don&#8217;t think that a new programmer should change anything they don&#8217;t understand, because they have the potential to open security holes if their programming gets broken. This is especially important since this script will transfer sensitive information across web servers.</p>
<p>There are a variety of free and paid scripts out there, but this one is written by a competent group of individuals that have extensive knowledge of payment processing, web development, and web security, so I highly recommend it.</p>
<p>Check it out:<br />
<a href="http://www.merchant-account-services.org/article/authorize-net-php-integration/">Integrate the Authorize.net Payment Gateway with PHP</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/205/integrate-a-website-with-authorizenet/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Required Actions for PCI Compliance</title>
		<link>http://www.merchantequip.com/merchant-account-blog/194/required-actions-for-pci-compliance</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/194/required-actions-for-pci-compliance#comments</comments>
		<pubDate>Wed, 25 Oct 2006 19:04:55 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Fraud]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/archives/194</guid>
		<description><![CDATA[If you accept credit card online, this chart is for you. This chart is a simple breakdown of the PCI data compliance levels and requirements. If you accept transactions online, you fall into one of these levels. This chart explains what the requirements are to be in a specific category, and what a merchant must [...]]]></description>
			<content:encoded><![CDATA[<p>If you accept credit card online, this chart is for you. This chart is a simple breakdown of the PCI data compliance levels and requirements. If you accept transactions online, you fall into one of these levels. This chart explains what the requirements are to be in a specific category, and what a merchant must do to remain compliant. </p>
<p>The yearly cost for a level 2, 3 or 4 merchant is around $150, while the yearly cost for a level 1 merchant is more than $30,000. Because of this, it is extremely important not to ever have a data compromise. I personally recommend not storing any sensitive data online, at all, and if it is stored offline, access should be highly restricted and the data should be encrypted. Track data should never be stored anywhere, under any circumstance.</p>
<p>If you have a data compromise and card holder data is stolen, you should expect upwards of $100,000 in fines, arbitration fees, and regulations in addition to the additional cost of level 1 PCI certification.</p>
<table width="100%" border="0" cellspacing="0" cellpadding="2">
<tr style="background:#f99;">
<td width="75px" rowspan="3"><b>Level 1</b></td>
<td width="100px"><b>Definition:</b></td>
<td>
<ul>
<li>Over 6 million annual Visa or MasterCard Transactions</li>
<li>Any merchant suffered a hack or attack that resulted in a data compromise</li>
<li>Any merchant that card associations, at their discretion, determine should meet requirements</li>
</ul>
</td>
</tr>
<tr style="background:#f99;">
<td><b>Requirement:</b></td>
<td>
<ul>
<li>On-site assessment by approved <a href="http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_Qualified_Data_Security_Company_List.pdf">QDSA on Visa&#8217;s website</a></li>
<li>Quarterly vulnerability scan by approved scanning vendor</li>
</ul>
</td>
</tr>
<tr style="background:#f99;">
<td><b>Deadline:</b></td>
<td>
<ul>
<li>September 30, 2004 (1 year for new Level 1 merchants)</li>
</ul>
</td>
</tr>
<tr>
<td colspan="3">&nbsp;</td>
</tr>
<tr style="background:#fc9;">
<td rowspan="3"><b>Level 2</b></td>
<td><b>Definition:</b></td>
<td>
<ul>
<li>Visa: 1M &#8211; 6M annual transactions</li>
<li>MC: 150K &#8211;  6M annual transactions</li>
</ul>
</td>
</tr>
<tr style="background:#fc9;">
<td><b>Requirement:</b></td>
<td>
<ul>
<li>Self assessment questionnaire and Quarterly vulnerability scan by approved scanning vendor</li>
</ul>
</td>
</tr>
<tr style="background:#fc9;">
<td><b>Deadline:</b></td>
<td>
<ul>
<li>June 30, 2005 (Sep 30, 2007 for new Level 2 Visa merchants)</li>
</ul>
</td>
</tr>
<tr>
<td colspan="3">&nbsp;</td>
</tr>
<tr style="background:#ffc;">
<td rowspan="3"><b>Level 3</b></td>
<td><b>Definition:</b></td>
<td>
<ul>
<li>Visa: 20K &#8211; 1M annual transactions</li>
<li>MC: 20K &#8211;  150K annual transactions</li>
</ul>
</td>
</tr>
<tr style="background:#ffc;">
<td><b>Requirement:</b></td>
<td>
<ul>
<li>Self assessment questionnaire and Quarterly vulnerability scan by approved scanning vendor</li>
</ul>
</td>
</tr>
<tr style="background:#ffc;">
<td><b>Deadline:</b></td>
<td>
<ul>
<li>June 30, 2005</li>
</ul>
</td>
</tr>
<tr>
<td colspan="3">&nbsp;</td>
</tr>
<tr style="background:#cfc;">
<td rowspan="3"><b>Level 4</b></td>
<td><b>Definition:</b></td>
<td>
<ul>
<li>Less than 20K ecommerce or 1M total Visa and MC transactions</li>
</ul>
</td>
</tr>
<tr style="background:#cfc;">
<td><b>Requirement:</b></td>
<td>
<ul>
<li>Self assessment questionaire and Quarterly vulnerability scan by approved scanning vendor</li>
</ul>
</td>
</tr>
<tr style="background:#cfc;">
<td><b>Deadline:</b></td>
<td>
<ul>
<li>Dates determined by merchant&#8217;s acquirer</li>
</ul>
</td>
</tr>
<tr>
<td colspan="3">&nbsp;</td>
</tr>
</table>
<p><strong>Related Posts:</strong><br />
<a href="http://www.merchantequip.com/merchant-account-blog/archives/114">Scan Alert PCI / CISP</a><br />
<a href="http://www.merchantequip.com/merchant-account-blog/archives/96">A Guide to Small Business Security, Free PDF Downloadâ€¦</a><br />
<a href="http://www.merchantequip.com/merchant-account-blog/archives/95">CISP, SDP, PCI Compliance required for every businessâ€¦</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/194/required-actions-for-pci-compliance/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

