<?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>Zen Dzign &#187; credit card payment</title>
	<atom:link href="http://www.zendzign.com/tag/credit-card-payment/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.zendzign.com</link>
	<description>The official ZZ Servers Blog - Visit http://www.zzservers.com for your business hosting needs.</description>
	<lastBuildDate>Thu, 26 Jan 2012 05:59:54 +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>Understanding PCI Levels and Types</title>
		<link>http://www.zendzign.com/2009/06/understanding-pci-levels-and-types/</link>
		<comments>http://www.zendzign.com/2009/06/understanding-pci-levels-and-types/#comments</comments>
		<pubDate>Tue, 02 Jun 2009 13:19:57 +0000</pubDate>
		<dc:creator>Peter Zendzian</dc:creator>
				<category><![CDATA[PCI]]></category>
		<category><![CDATA[credit card]]></category>
		<category><![CDATA[credit card payment]]></category>
		<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[Small Business]]></category>

		<guid isPermaLink="false">http://www.zendzign.com/?p=26</guid>
		<description><![CDATA[Any merchant who accepts credit cards and has a merchant account must validate compliance. It does not matter if you use a 3rd party processor or if you outsource all of your credit card processing. It&#8217;s the ownership of the merchant account that defines if you must validate compliance. The only to avoid PCI compliance [...]]]></description>
			<content:encoded><![CDATA[<p>Any merchant who accepts credit cards and has a merchant account must validate compliance. It does not matter if you use a 3rd party processor or if you outsource all of your credit card processing. It&#8217;s the ownership of the merchant account that defines if you must validate compliance. <strong><em>The only to avoid PCI compliance is by not having a merchant account. </em></strong>Below are some charts which will help you decide which category and merchant type your business fits into.<span id="more-26"></span></p>
<h4>Merchant levels and Compliance Validation Requirements</h4>
<table style="height: 416px;" border="1" width="547">
<tbody>
<tr>
<td colspan="3" align="center" valign="top"><strong>PCI Merchant Levels</strong></td>
</tr>
<tr>
<td align="center" valign="top"><strong>Level</strong></td>
<td align="center" valign="top"><strong>Description</strong></td>
<td align="center" valign="top"><strong>Validation Requirements</strong></td>
</tr>
<tr>
<td align="center" valign="middle">1</td>
<td align="left" valign="top">
<ul>
<li>Any merchant, &#8220;regardless of acceptance channel, processing over 6,000,000 Visa transactions per year</li>
<li>Any merchant that has suffered a hack or an attack that resulted in an account data compromise.</li>
<li>Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.</li>
<li>Any merchant identified by any other payment card brand as Level 1</li>
</ul>
</td>
<td align="left" valign="top">
<ul>
<li>Annual Report on Compliance (“ROC”) by Qualified Security Assessor (“QSA”)</li>
<li>Quarterly network scan by Approved Scan Vendor (“ASV”)</li>
<li>Attestation of Compliance Form</li>
</ul>
</td>
</tr>
<tr>
<td align="center" valign="middle">2</td>
<td align="left" valign="top">
<ul>
<li>Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 transactions per year</li>
</ul>
</td>
<td align="left" valign="top">
<ul>
<li>Annual Self-Assessment Questionnaire (“SAQ”)</li>
<li>Quarterly network scan by ASV</li>
<li>Attestation of Compliance Form</li>
</ul>
</td>
</tr>
<tr>
<td align="center" valign="middle">3</td>
<td align="left" valign="top">
<ul>
<li>Any merchant processing 20,000 to 1,000,000 transactions per year.</li>
</ul>
</td>
<td align="left" valign="top">
<ul>
<li>Annual SAQ</li>
<li>Quarterly network scan by ASV</li>
<li>Attestation of Compliance Form</li>
</ul>
</td>
</tr>
<tr>
<td align="center" valign="middle">4</td>
<td align="left" valign="top">
<ul>
<li>Any merchant processing fewer than 20,000 transactions per year.</li>
</ul>
</td>
<td align="left" valign="top">
<ul>
<li>Annual SAQ recommended</li>
<li>Quarterly network scan by ASV if applicable</li>
<li>Compliance validation requirements set by acquirer</li>
</ul>
</td>
</tr>
</tbody>
</table>
<p><strong>Merchant Types</strong></p>
<p>The “SAQ” is a self-validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions. In order to align more closely with merchants and their compliance validation process, the SAQ was revised and now allows for flexibility based on the complexity of a particular merchant’s or service provider’s business situation (see chart below). The SAQ validation type does not correlate to the merchant classification or risk level.</p>
<table border="1" width="100%">
<tbody>
<tr>
<td colspan="3" align="center" valign="top"><strong>Self-Assessment Questionnaires and Validation Types</strong></td>
</tr>
<tr>
<td align="center" valign="top"><strong>SAQ Validation</strong><strong>Type</strong></td>
<td align="center" valign="top"><strong>Description</strong></td>
<td align="center" valign="top"><strong>SAQ</strong></td>
</tr>
<tr>
<td align="center" valign="middle">1</td>
<td align="left" valign="top">Card-Not-Present (e-commerce or MO/TO) merchants, all cardholder data<br />
functions outsourced. This would never apply to face-to-face merchants.</td>
<td align="center" valign="middle">A</td>
</tr>
<tr>
<td align="center" valign="middle">2</td>
<td align="left" valign="top">Imprint-only merchants with no cardholder data storage.</td>
<td align="center" valign="middle">B</td>
</tr>
<tr>
<td align="center" valign="middle">3</td>
<td align="left" valign="top">Standalone dial-up terminal merchants, no cardholder data storage.</td>
<td align="center" valign="middle">B</td>
</tr>
<tr>
<td align="center" valign="middle">4</td>
<td align="left" valign="top">Merchants with payment application systems connected to the Internet, no<br />
cardholder data storage.</td>
<td align="center" valign="middle">C</td>
</tr>
<tr>
<td align="center" valign="middle">5</td>
<td align="left" valign="top">All other merchants (not included in descriptions for SAQs A, B or C above), and<br />
all service providers defined by a card brand as eligible to complete a SAQ.</td>
<td align="center" valign="middle">D</td>
</tr>
</tbody>
</table>
<p><strong>Service Provider Levels</strong></p>
<p>Service providers are organizations that process, store, or transmit cardholder data on behalf of clients, merchants, or other service providers. Service provider levels are defined as:</p>
<table border="1" width="100%">
<tbody>
<tr>
<td colspan="3" align="center" valign="top"><strong>Self-Assessment Questionnaires and Validation Types</strong></td>
</tr>
<tr>
<td align="center" valign="top"><strong>Service Provider Level</strong></td>
<td align="center" valign="top"><strong>Description</strong></td>
<td align="center" valign="top"><strong>Validation Requirements</strong></td>
</tr>
<tr>
<td align="center" valign="middle">1</td>
<td align="left" valign="top">Processors or any service providers that stores, processes and/or transmits over 300,000 transactions per year.</td>
<td align="left" valign="top">
<ul>
<li>Annual On-Site PCI Data Security Assessment validated Qualified Security Assessor (“QSA”)</li>
<li>Quarterly network scan by Approved Scan Vendor (“ASV”)</li>
</ul>
</td>
</tr>
<tr>
<td height="42" align="center" valign="middle">2</td>
<td align="left" valign="top">Any service provider that stores, processes and/or transmits less than 300,000 transactions per year.</td>
<td align="left" valign="top">
<ul>
<li>Validated by Service Provider</li>
</ul>
<ul>
<li>Quarterly network scan by Approved Scan Vendor (“ASV”)</li>
</ul>
</td>
</tr>
</tbody>
</table>
<p>By using the charts above, you should be able to easily determine your level and validation type. Knowing this details will go a long way in guiding you through your compliance but it is important to partner with other qualified businesses for your service. <a href="http://www.zzservers.com">ZZ Servers</a> provides PCI focused hosted infrastructure designed for PCI compliance and includes many of controls and measures required for your business infrastructure to be fully compliant.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.zendzign.com/2009/06/understanding-pci-levels-and-types/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PCI Compliance and Receiving Credit Card Payments by Fax</title>
		<link>http://www.zendzign.com/2008/10/pci-compliance-and-receiving-credit-card-payments-by-fax/</link>
		<comments>http://www.zendzign.com/2008/10/pci-compliance-and-receiving-credit-card-payments-by-fax/#comments</comments>
		<pubDate>Fri, 31 Oct 2008 17:09:35 +0000</pubDate>
		<dc:creator>David M. Zendzian</dc:creator>
				<category><![CDATA[PCI]]></category>
		<category><![CDATA[credit card payment]]></category>
		<category><![CDATA[Small Business]]></category>

		<guid isPermaLink="false">http://www.zendzign.com/?p=21</guid>
		<description><![CDATA[The low cost of web and email based fax delivery services may seem like a good way to save your business money but not if you receive credit card payments by fax. This would fall under the Payment Card Industry standard section 4 that requires transmission of cardholder data across open-public networks to be encrypted [...]]]></description>
			<content:encoded><![CDATA[<p>The low cost of web and email based fax delivery services may seem like a good way to save your business money but not if you receive credit card payments by fax. This would fall under the Payment Card Industry standard section 4 that requires transmission of cardholder data across open-public networks to be encrypted and section 12 for contracts that require partners or service providers who handle card data for your company be PCI compliant and accept all PCI security requirements. You will not find an affordable PCI compliant solution without using your own dedicated fax machine.</p>
<p><span id="more-21"></span></p>
<p>Many on-line fax services send received faxes by unencrypted email with cleartext (TIFF/JPG or PDF) attachments which are not PCI compliant. One reason for this is PCI clearly states that credit card numbers are not to be emailed in clear-text, they must be encrypted. A fax converted to PDF &amp; emailed is not encrypted and if done that way then both the service provider and the receiver are non-compliant.  During an audit you can&#8217;t say you didn&#8217;t know, you signed up for the service knowing you were going to receive card numbers.</p>
<p>So, how do you receive credit card payments by fax? The first step is get a phone line w/a $50 fax machine from your local office supplier and come up with a security policy for how to secure the fax machine and incoming faxes. This is cheaper and easier to deal with than trying to make some digital systems PCI compliant. The fax needs to be classified as confidential and handled how your data retention policy dictates, assuming your retention policy is PCI compliant. An example would be a secured fax machine in accounting or other area set aside for receiving secure faxes. Additionally faxes containing credit card numbers need to be stored or archived properly and when disposed of, it needs to again follow your data retention policy and be securely destroyed (cross cut / incinerate, whatever:).</p>
<p>If your company is receiving card data on behalf of your customers, you are liable for all the paths it takes to get to you. Claiming you didn&#8217;t know or that it&#8217;s out of your hands is not enough when there are secure solutions. Don&#8217;t use a fax service unless they can send encrypted emails and securely purge the fax data when sent; otherwise get a real fax machine &amp; secure it and instruct those who have access what it may contain and how to handle it appropriately, and yes training for your employees is a PCI requirement.</p>
<p>In the end, you will find a phone line with $50 fax from your local office supplier is cheaper and easier to deal with than trying to make some digital systems PCI compliant.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.zendzign.com/2008/10/pci-compliance-and-receiving-credit-card-payments-by-fax/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

