<?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; Merchant Accounts</title>
	<atom:link href="http://www.merchantequip.com/merchant-account-blog/category/merchantaccounts/feed" rel="self" type="application/rss+xml" />
	<link>http://www.merchantequip.com/merchant-account-blog</link>
	<description>Merchant Accounts, Ecommerce, Processing Equipment</description>
	<lastBuildDate>Thu, 19 Aug 2010 14:08:09 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Paypal has nothing to worry about</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1143/paypal-has-nothing-to-worry-about</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1143/paypal-has-nothing-to-worry-about#comments</comments>
		<pubDate>Fri, 13 Aug 2010 14:34:15 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[3rd Party Processors]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1143</guid>
		<description><![CDATA[Paypal has long withstood scores of competitors, trying their hand at dethroning the king of online payments. It seems like every time a new payment service pops up, someone, myself included, once again brings up the end of Paypal question. Just a few months ago, MasterCard announced they would open up their API&#8217;s to developers. [...]]]></description>
			<content:encoded><![CDATA[<p>Paypal has long withstood scores of competitors, trying their hand at dethroning the king of online payments. It seems like every time a new payment service pops up, someone, myself included, once again brings up the end of Paypal question.</p>
<p>Just a few months ago, MasterCard announced they would open up their API&#8217;s to developers. Just before MasterCard, Visa purchased Cybersource, the company that owns Authorize.net. Amazon.com and Google, 2 of the largest presences on the internet, have their own payment systems, <a href="http://www.merchantequip.com/merchant-account-blog/1027/a-comparison-of-3-alternative-payment-methods">priced identically to Paypal</a>, already with millions of users. And yet, Paypal continues to dominate the alternative payment market. Just imagine if 4 of the largest, and most powerful companies on earth put your business in their cross-hairs&#8230;</p>
<p>So how is it that a company like Paypal can withstand competitors, despite their own fallacies, and still maintain near-unchecked dominance over online payments?</p>
<p><strong>Let&#8217;s start at the beginning&#8230;</strong></p>
<p>In the beginning there was eBay. eBay revolutionized online shopping and person-to-person sales, and not just on the internet. eBay was truly the first, very-successful, online auction and marketplace. No auction site to this day has even put a challenge to eBay&#8217;s huge user base. The primary competitors now, are Craigslist and Amazon.com, both operating on entirely different business models, and only 1 with their own payment system. In 2002 eBay purchased the already successful Paypal to replace their failing Billpoint service. Both were payment options that buyers and sellers could use for eBay transactions. Paypal at the time was beating eBay&#8217;s Billpoint in popularity, so the acquisition was obvious and well overdue. Eliminating all competition from eBay payments allowed Paypal to gain complete dominance over alternative payments. There were a few others out there, but since eBay was the place to sell stuff, and Paypal was virtually built-in, Paypal became the only choice. eBay&#8217;s structure has always made it difficult for traditional merchant accounts and payment gateways to be used, so Paypal was almost always chosen by businesses if not for any reason but convenience. All the while, Paypal continuously advanced on a second front which consisted of a simple shopping cart, customer invoicing and person-to-person payments. This allowed anyone to send and receive money from other people, and allowed just about anyone to sell products on a website. Through these 2 channels, Paypal quickly became the one and only online payment provider.</p>
<p>Paypal has also greatly expanded its website integration methods, allowing for very customized and efficient buying experiences, enticing large ecommerce sites to use them as well. </p>
<p><strong>Paypal plagued with problems</strong></p>
<p>Paypal as a service provider is not without problems. Since their inception, they have been plagued by their poor quality of customer service, virtually non-existent human support, and draconian risk management procedures.</p>
<p>Paypal has one of the poorest track records of customer service anywhere and I believe it rivals any company on earth. I can&#8217;t think of a single aspect of Paypal&#8217;s business that I haven&#8217;t heard major complaints about. Additionally, it&#8217;s not just the fact that Paypal has complaints, but the poor manner in which they address, or fail to address, their customer&#8217;s problems. There&#8217;s over 7,000 complaints with the BBB alone in the past 3 years. There&#8217;s millions of angry buyers and sellers that have lost money through Paypal, many of these while following Paypal&#8217;s policies to a T. To be quite honest, there&#8217;s probably few companies, that could survive with the amount of negative experiences and negative press as Paypal.</p>
<p>Many people, probably the majority, never have problems with Paypal, but many of those who do, often end up abandoning their service altogether.</p>
<h2>Onto the answer</h2>
<p>Paypal will continue to dominate payments despite complaints, problems, and time, for these reasons. </p>
<ol>
<li>They&#8217;re already accepted and used everywhere.</li>
<li>They are available where merchant accounts are not.</li>
<li>They offer P2P payments.</li>
<li>There&#8217;s no other option!</li>
</ol>
<p><strong>They&#8217;re already accepted and used everywhere</strong></p>
<p>Paypal&#8217;s user base is currently over 100 Million <em>(the number of active accounts is substantially lower)</em>. With the sheer number of web users that have a paypal account, and the number of businesses that accept it, it is going to be a daunting task to try and move people away from it.</p>
<p><strong>They are available where merchant accounts are not</strong></p>
<p>As someone who runs a merchant account provider, I can tell you that Paypal has an enormous advantage in that they are not restricted to the people they can service. Paypal is available in most countries in the world. Merchant account provides and most processors are restricted to a few countries. There&#8217;s no contracts with Paypal, no terms, monthly fees or termination fees. Lastly, Paypal can facilitate Person to person payments. Merchant account providers cannot do this, neither in principle nor the actual mechanism to facilitate them.</p>
<p><strong>There&#8217;s no other option</strong></p>
<p>Realistically, until there&#8217;s a huge Paypal abandonment, there&#8217;s no other option than Paypal. Payment services are a consumer driven industry. Until consumers want to pay with something else, they will continue to use Paypal. The catch 22 is that merchants accept what their customers use for payment and consumers wont switch until merchants accept it.</p>
<p>For a quick example of how slow payment technologies move, just look at contactless payments. They&#8217;ve been around for many years yet only a small percentage of card holders have contactless cards, and an even smaller percentage of merchants accept it. Nothing I have seen in the past 5 years offers compelling evidence that contactless or smart cards or mobile or any other technology will make a move any time soon. There&#8217;s often a lot of press and noise on these new technologies, but very little actual implementation.</p>
<p><strong>They offer P2P payments</strong></p>
<p>Paypal offers P2P (person-to-person) payments, allowing any person with an email address to send money to another person. This has 2 competitive advantages. It first gives Paypal the massive user base that&#8217;s not restricted just to businesses. Second, it gives them an enormous cost advantage over merchant account providers. Since roughly 50% of Paypal&#8217;s payments are funded from an account and not a credit card, Paypal isn&#8217;t charged any fee for these. They do however charge the merchant the fee. When you put this into their own cost/revenue breakdown, it effectively reducing their internal cost by 50%.</p>
<p>Visa and MasterCard have made it so difficult to create the type of business <em>(Called an aggregator or 3rd party processor)</em>, there&#8217;s little chance of anyone being able to successfully do it. Just try to find a relevant accurate guide on how to set up a payment aggregator or 3rd party processor. It doesn&#8217;t exist because it&#8217;s only been done a few times, and of those that have succeeded, even fewer have survived. In the research I&#8217;ve done and helped others with on this type of business, it would take tens of millions of dollars just to get established. A business like this would need to have an enormous user base or some very good reason to people to start using their service or they would simply fade away like the many that have tried.</p>
<h2>Where the competitors are going wrong.</h2>
<p>The key mistake that Visa, MasterCard, Google, and Amazon are making is that unless they can answer the P2P payment issue, they will never pose a real threat to Paypal. Paypal is <a href="http://pymnts.com/the-new-and-improved-paypal">just as innovative</a> on everything from mobile payments to ecommerce as anyone out there. They created their <a href="https://www.x.com/">X-platform</a> and are opening it up to developers, which allows for very advanced development like 3rd part payments, aggregating, and mobile or retail integration. Visa and MasterCard have no chance by themselves, it&#8217;s absurd for them to think that their brand is important enough without the other issuers to make in this space. I can&#8217;t see all of the issuers joining forces to create a massive P2P payment system any time soon, not to mention they would have more antitrust lawsuits flying than has ever been seen.</p>
<p>Realistically, these Paypal challengers are only banking on Paypal&#8217;s poor customer service reputation to try and gain a market share, and Paypal users aren&#8217;t jumping ship. </p>
<p>I would say that right now, Google and Amazon are the only ones with a shot, and based on their user base, they have a good one. Aside from the lack of P2P payments, they are still failing in getting consumers to switch their payment systems, and until they do, they will not pose a real challenge.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1143/paypal-has-nothing-to-worry-about/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Merchant Account Blog&#8217;s 5 Year Anniversary</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1331/merchant-account-blogs-5-year-anniversary</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1331/merchant-account-blogs-5-year-anniversary#comments</comments>
		<pubDate>Tue, 03 Aug 2010 14:50:27 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantequip.com/merchant-account-blog/?p=1331</guid>
		<description><![CDATA[I have been so busy the past few weeks that I didn&#8217;t notice that the merchant account blog&#8217;s 5 year anniversary just passed, July 27th. With several hundred posts related to merchant accounts it&#8217;s often difficult to find positive and informative topics to write about. However, with major changes in regulation, mobile, contact-less and alternative [...]]]></description>
			<content:encoded><![CDATA[<p>I have been so busy the past few weeks that I didn&#8217;t notice that the merchant account blog&#8217;s 5 year anniversary just passed, July 27th. With several hundred posts related to merchant accounts it&#8217;s often difficult to find positive and informative topics to write about. However, with major changes in regulation, mobile, contact-less and alternative payments, I anticipate the next year to be eventful. I am also hoping to add guest bloggers as I&#8217;ve been getting increasing interest from other bloggers and business owners in making guest posts here.</p>
<p>Thanks to everyone who reads the blog, and to those who email me their questions, which is currently 5 &#8211; 10 <em>non spam questions</em> every day. I do apologize if I am unable to answer everything that gets sent to me, and I will do my best in the future.</p>
<p>As always, if you have any questions or suggestions, please <a href="http://www.merchantequip.com/merchant-account-blog/contact-us">let me know</a>.</p>
<p>Thanks<br />
Jamie</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1331/merchant-account-blogs-5-year-anniversary/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>1 minute guide to PCI Compliance</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance#comments</comments>
		<pubDate>Thu, 15 Jul 2010 14:15:22 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1281</guid>
		<description><![CDATA[PCI-DSS has been around for several years now, and ignorance is less tolerated when it comes to data security. In case you are just learning about PCI, here&#8217;s the 1 minute breakdown on PCI compliance. PCI is a security framework created to help prevent/curb the loss of credit card data. It covers some of the [...]]]></description>
			<content:encoded><![CDATA[<p>PCI-DSS has been around for several years now, and ignorance is less tolerated when it comes to data security. In case you are just learning about PCI, here&#8217;s the 1 minute breakdown on PCI compliance.</p>
<ol>
<li>PCI is a security framework created to help prevent/curb the loss of credit card data. It covers some of the more basic  aspects of data   security, but is not security itself. <strong><br />
PCI compliance &ne; Security</strong>.</li>
<li>If <strong>you</strong> accept credit cards, you must be PCI compliant. No ifs, ands, or buts.</li>
<li>Most data breaches occur at small to medium size <strong>retail</strong> businesses. You  are a soft target and thieves know it! This is especially true if you  have a POS computer system.</li>
<li>Being PCI compliant does not remove liability in case you still suffer a data breach. It &#8220;may&#8221; reduce or eliminate fines but will not eliminate actual costs resulting from a data breach.</li>
<li>With respect to the actual process, gaining PCI compliance requires you to fill out a self assessment questionnaire (SAQ), and scan your networks periodically using an approved scanning vendor (ASV). Your exact requirements depend on <a href="http://www.mastercard.com/us/sdp/merchants/merchant_levels.html">which PCI level</a> your business is.</li>
<li>You can find a <a href="https://www.pcisecuritystandards.org/pdfs/asv_report.html">list of ASV&#8217;s here</a>. Most ASV&#8217;s can also assist in helping you fill out the correct SAQ.</li>
<li>If you are doing it yourself, you can <a href="https://www.pcisecuritystandards.org/saq/index.shtml">get the SAQ here</a>.</li>
<li>If you store credit card numbers electronically, you must fill out   SAQ &#8211; D. Have fun&#8230;</li>
<li>If you are PCI compliant, it does not mean that your networks and data are secure. Security is something that requires constant administration and vigilance, and requires far more than what PCI outlines.</li>
<li>If you don&#8217;t have the ability or expertise to be secure, hire or outsource to someone that does.</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Dejavoo credit card terminals</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1265/dejavoo-credit-card-terminals</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1265/dejavoo-credit-card-terminals#comments</comments>
		<pubDate>Fri, 09 Jul 2010 18:32:21 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Credit Card Equipment]]></category>
		<category><![CDATA[Merchant Accounts]]></category>
		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1265</guid>
		<description><![CDATA[In the US, there are 2 credit card equipment manufacturers that basically own the entire terminal market, Verifone and Hypercom. Lipman USA is another major player however, Verifone purchased Lipman several years ago effectively creating 2 major brands. Another major company Ingenico, has a larger global presence, but their usage in the US in minimal [...]]]></description>
			<content:encoded><![CDATA[<p>In the US, there are 2 credit card equipment manufacturers that basically own the entire terminal market, Verifone and Hypercom. Lipman USA is another major player however, Verifone purchased Lipman several years ago effectively creating 2 major brands. Another major company Ingenico, has a larger global presence, but their usage in the US in minimal at least in the independent sales markets.</p>
<p>A few years ago a new terminal company named <a href="http://www.dejavoosystems.com/">Dejavoo</a> was established. Dejavoo was founded by the original founder of Lipman USA, and seems to be founded on the same principles that Lipman was:  rock-solid products that are easy to use and very reliable. In my opinion Lipman&#8217;s Nurit 2085 is the most reliable and best land-line terminal to date. It isn&#8217;t very small, and it doesn&#8217;t look particularly classy, but it works well, it&#8217;s cheap, and it&#8217;s easy to use. Having watched the reliability of credit card terminals diminish over the past 10 years, I would love to see a highly-reliable brand emerge. Since the terminal market is monopolized by a few behemoths, it&#8217;s equally good to see a new competitor with a strong history of success in this specific industry.</p>
<p>Dejavoo currently offers several terminals which should meet the requirements of most merchants, whether retail or mobile. One of the coolest  things about the Dejavoo terminals, is that they all <em>(except the C5 and M3)</em> support a USB WiFi adapter, allowing a merchant with a secure WiFi network to eliminate an extra cord on their counter-top.</p>
<p>All Dejavoo terminals have quick thermal printers, and have internal PINpads. Dejavoo terminals meet the newer PCI-PED requirements for PINpads. Lastly, all Dejavoo terminals are at the lower end, if not the lowest, of cost for comparable terminals from other manufacturers.</p>
<h3><strong>Wired Dejavoo Terminals</strong><strong><img class="alignright size-full wp-image-1269" title="dejavoo-x-series" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/07/dejavoo-x-series.jpg" alt="" width="270" height="308" /></strong></h3>
<p><strong>Dejavoo C5</strong> &#8211; The C5 is the entry level terminal from Dejavoo. It is dial only, and does not support USB components like the X series. It is the lowest cost terminal from Dejavoo. It is PCI certified and would be a comparable replacement for Nurit 2085, Hypercom T7 Plus, and similar products. The C5 looks to be the most durable of the Dejavoo terminals, and is slightly larger than the X or M lines. Most merchants will probably want the additional features of the X line, as the entry X5 terminal is a significant improvement to the C5 without a significant price increase.</p>
<p><a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/dejavoo-x5/"><strong>Dejavoo X5</strong></a> &#8211; The X5 is the first terminal in the X-line. It uses a custom Linux operating system, dual processors, and supports USB peripherals including the USB WiFi adapter. It features a compact, well styled design, and supports a multitude of features all for a low price. It is a dial-only terminal, but has more memory than current Verifone or Hypercom terminals. It is PCI compliant, and features a smart card reader and internal PINpad.</p>
<p><a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/dejavoo-x8/"><strong>Dejavoo X8</strong></a> &#8211; The X8 is almost the same as the X5 except that it supports processing over an 10/100 IP/Ethernet connection in addition to a dial-connection, and has an additional USB port. It is currently the lowest cost Ethernet terminal that we know of, just edging out the <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/hypercom-t4220/">Hypercom T4220</a>.</p>
<h3><strong>Wireless Dejavoo Terminals</strong></h3>
<p><strong><img class="alignright size-medium wp-image-1272" title="dejavoo-m-series-with-docking" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/07/dejavoo-m-series-with-docking-300x256.jpg" alt="" width="300" height="256" /><a href="http://www.merchantequip.com/processing-equipment/wireless-terminals/dejavoo-m3/">Dejavoo M3</a>, M5 and <a title="Dejavoo M8" href="http://www.merchantequip.com/processing-equipment/wireless-terminals/dejavoo-m8/">M8</a></strong></p>
<p>The Dejavoo M series, are PCI certified, GPRS, wireless terminals. They are all based on the same M3 platform. The M5 has a base which includes a charging station. The M8 includes a base with an Ethernet port. The M5 and the M8 support the WiFi module, but the M3 does not.</p>
<p>The GPRS wireless network is normally used with ATT Wireless and is currently the most used network for credit card processing. So far I have not heard of development on the CDMA networks which would include Verizon and Sprint, but I imagine that there are plans in the future.</p>
<p>The M series terminals all include internal PINpads and thermal printers. They are compact, and use the same dual-processor system as the X terminals. Like X terminals, M series terminals accept normal credit cards as well as smart cards. The M series terminals aren&#8217;t the most elegant terminals out there, but it looks like Dejavoo traded fashion for a more robust and durable platform, which is far more important for wireless terminals.</p>
<p><a href="http://www.merchantequip.com/processing-equipment/supplies-accessories/dejavoo-wifi-adapter/"><strong>Dejavoo WiFi Module</strong></a></p>
<p>The Dejavoo WiFi module is an inexpensive USB WiFi stick that allows most Dejavoo terminals to process on a secure WiFi network. It theoretically works with the M3, M5, X5 and X8 terminals <em>(We&#8217;ve personally only tested it with the X8, but Dejavoo has assured us that it works with the rest)</em>. We&#8217;ve been playing with one for the past week and despite some minor issues in initially getting the connection to work, it seems like this is the <span style="text-decoration: line-through;">best</span> only WiFi processing option available. The Verifone VX 610 is completely unusable because it&#8217;s support for WPA security is horrendous. The VX 670 is equally bad because it requires an expensive base, pushing the price above $800.</p>
<p><strong>A note on wireless security and processing &#8211; </strong>WEP security is completely prohibited by PCI so do not under any circumstance use WEP or a non-secure connection to process using WiFi. Businesses should use WPA or WPA2 preferable and use a strong password like &#8220;4p%n&amp;1GiJF$*nK8n&#8221;.</p>
<p><strong>Conclusion</strong></p>
<p>Based on our initial experience with Dejavoo terminals, they look to be the most promising brand of terminals we&#8217;ve seen in a long time, especially with regard to their wireless M-series wireless terminals. Several processors have made Dejavoo their preferred brand. I would like to see their performance over the next year or two before making a commitment. In any case, if I were Verifone or Hypercom, I would probably be concerned.  The Dejavoo terminals appear to be superior to both brands in just about every way including price, and only time will tell if they live up to their founder&#8217;s reputation.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1265/dejavoo-credit-card-terminals/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The myth of bankcard deposit reconciliation</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1220/the-myth-of-bankcard-deposit-reconciliation</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1220/the-myth-of-bankcard-deposit-reconciliation#comments</comments>
		<pubDate>Wed, 09 Jun 2010 19:21:15 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Amex / Discover]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1220</guid>
		<description><![CDATA[I am often asked on how to reconcile bankcard settlements (batches) to the money coming into a bank account. While a seemingly simple theory, as most accountants and anyone who has tried to match up settlements to deposits know, it&#8217;s far from easy. In a perfect world we would see our settlement report at the [...]]]></description>
			<content:encoded><![CDATA[<p>I am often asked on how to reconcile bankcard settlements <em>(batches)</em> to the money coming into a bank account. While a seemingly simple theory, as most accountants and anyone who has tried to match up settlements to deposits know, it&#8217;s far from easy.</p>
<p align="center"><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/06/charges-dont-reconcile.gif" alt="" title="charges-dont-reconcile" width="500" height="95" class="alignnone size-full wp-image-1225" /></p>
<p>In a perfect world we would see our settlement report at the end of the day, and a day or two later would see the exact same amount deposited into our bank account. In reality, we see our settlement report at the end of the day, and then we see absolutely no resemblance of it in our bank account, at any point, ever! The exception may be if you run a single transaction per day. The more transactions you process, the less your deposits will reconcile.</p>
<h2>Why reconciling is often difficult&#8230;</h2>
<p><strong>Issuers don&#8217;t settle together</strong></p>
<p>This is becoming less of a problem as Discover and Amex are starting to settle with Visa and MasterCard, but it still exists with many accounts, probably still the majority. Since Amex and Discover historically operated on completely different networks, and completely different financial systems, they would never settle directly with Visa and MasterCard. While one shouldn&#8217;t expect an Amex deposit to be labeled the same as Visa/MC deposits, it&#8217;s still difficult to add the correct deposits together. This is mainly because Amex and Discover often take longer to be settled and deposited than Visa/MC. Your Visa/MC transaction may be in your bank in 48 hours, but your Amex may take a week. When your business&#8217;s bank account has hundreds of deposits and withdrawals like most do, it&#8217;s extremely difficult to match the correct deposits with the corresponding settlements.</p>
<p><strong>You accept PIN-debit, fleet and/or other proprietary cards</strong></p>
<p>The more types of cards you accept, the more unlikely your batches are to reconcile with your deposits. Everything from PIN debit, fleet and gas cards, JCB, Diners, EBT cards, to gift cards and anything other than a typical Visa or Master credit card requires different processing systems and networks to handle the transaction settlement. It&#8217;s rare that any of these follow the same protocols as Visa/MC which means the deposits don&#8217;t come in same deposit or even at the same time.</p>
<p><strong>Settlement times</strong></p>
<p>When you accept a credit card it must be settled at the end of the day. The method that your transaction are settled depends on how you are processing cards. You may be manually batching your terminal, you may have a terminal with auto-batch, or you may have a gateway that batches for you, and each of these methods can present different opportunities for something to get messed up or out of sync when settling. Once batched, these transactions are queued up to be settled and paid with the card issuer.</p>
<p>The problem, is that it&#8217;s fairly easy to end up with settlement time mismatches. You could batch at 3PM, and your platform could batch at 2:30, this would add a day to your deposit time. You may have some complicated setup on the back-end that involves multiple systems settling your transactions, and again if there is some mismatch, transactions can get pushed back. Some systems settle multiple times per day but give you a single report at the end of it. It&#8217;s even possible that some transactions get split between batches if there are time-mismatches somewhere in on the back-end. This is a nightmare to try and identify, let alone understand what is happening.</p>
<p>Since very few systems have been built from the ground up, many of these systems, which neither you nor your processor have any control over, are complicated and antiquated. Processing networks are often many layers of systems tied together to provide the functionality needed. This complexity can create virtual bottlenecks which can make a mess of settlement times.</p>
<p><strong>Your pricing may be the real reason</strong></p>
<p>There are several types of pricing structures, in reference to how and when your fees are taken out at the end of the month that are commonly used with merchant accounts. The primary 2 are daily and monthly discounting. If you are on daily discounting, your qualified percentage and transaction fee are subtracted from your deposits every day. At the end of the month, your surcharges <em>(mid and non qualified transaction)</em> are billed to your account. This makes the end of month bill substantially easier to swallow, but guarantees that deposits will never match settlement reports. Monthly discounting on the other hand, is where all of your fees are withdrawn at the end of the month. If you want any chance of reconciling to the dollar, you must be on monthly discounting. However, many businesses will not qualify for monthly discounting as your processor is taking a gamble in the event you do not have the money available at the end of the month. This has  become much more common over the past 2 years. If you are a new business or if you have ever had an ACH reject or NSF when your processor tried to collect your fees, you should expect to be on daily discounting, at least until you can establish better processing history. If you are an existing business without ACH rejects or any major risk factor, you should be able to get your processor to put your account on monthly discounting. Keep in mind, if your account does not have the available funds in it at the end of the month, you will be quickly switched to daily discounting.</p>
<h3>Is there any fix?</h3>
<p>Reconciling can be expected to become easier as issuers and different card types begin to settle with Visa and MasterCard, but it&#8217;s going to be a lengthy migration. If you accept fleet cards, or some of the non-bankcard types, it&#8217;s unlikely that these will ever be deposited with your normal transactions. </p>
<p>If you understand the type of transactions you are accepting, whether your Discover and/or Amex transactions settle with your Visa/MC ones, the amount of time that it takes for your batches to hit your bank, and you are processing on monthly discounting, it is possible to get your transactions to reconcile, or mostly reconcile. If you end up running into a situation where back-end systems are causing the problems, it&#8217;s unlikely you will be able to easily remedy the situation. Depending on what type of terminal, POS system or software you are using, there may be no other option than to continue processing without an easy ability to reconcile your transactions</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1220/the-myth-of-bankcard-deposit-reconciliation/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Payment Resources</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1210/payment-resources</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1210/payment-resources#comments</comments>
		<pubDate>Tue, 08 Jun 2010 16:02:09 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1210</guid>
		<description><![CDATA[Here is a list of the payment related resources I read on a regular basis. If you&#8217;re looking for good payments, merchant account and data security resources, these are some good ones. If you have any recommendations, please feel free to post them up. I&#8217;m always looking to add to my list of regular payment [...]]]></description>
			<content:encoded><![CDATA[<p>Here is a list of the payment related resources I read on a regular basis. If you&#8217;re looking for good payments, merchant account and data security resources, these are some good ones. If you have any recommendations, please feel free to post them up. I&#8217;m always looking to add to my list of regular payment reading.</p>
<p><strong>Websites:</strong><br />
<a href="http://www.federalreserve.gov/paymentsystems/default.htm">Federal Reserve Payment Board</a><br />
<a href="http://www.paymentsnews.com/">Payment News</a><br />
<a href="https://partnernetwork.visa.com/vpn/global/home.do">Visa Partner Network</a></p>
<p><strong>Blogs:</strong><br />
<a href="http://www.amazonpaymentsblog.com/amazon_payments_blog/">Amazon Payment Blog</a><br />
<a href="http://aneace.blogspot.com/">Anceace&#8217;s Blog</a><br />
<a href="http://www.andyorrock.com/">Andy Orrock | Payment Systems</a><br />
<a href="http://www.askaboutpci.com/">Ask About PCI</a><br />
<a href="http://chuvakin.blogspot.com/">Anton Chuvakin Blog</a><br />
<a href="http://blog.bwplawyer.com/">Broox Peterson</a><br />
<a href="http://www.creditcardsonline101.com/">Credit Cards Online 101</a><br />
<a href="http://digitaldebateblogs.typepad.com/digital_money/">Digital Money Blog</a><br />
<a href="http://googlecheckout.blogspot.com/">Google Checkout Blog</a><br />
<a href="http://www.infolawgroup.com/">Info Law Group</a><br />
<a href="http://www.mckeay.net/">Network Security Blog</a><br />
<a href="http://pcidss.wordpress.com/">Payment Card Security &#038; IT Controls Explained</a><br />
<a href="http://www.paymentsystemsblog.com/">Payment Systems Blog</a><br />
<a href="http://paymenttalk.blogspot.com/">Payment Talk</a><br />
<a href="https://www.thepaypalblog.com/">The Paypal Blog</a><br />
<a href="http://www.retailinfosec.com/">Retail Information Security</a><br />
<a href="http://www.storefrontbacktalk.com/">Storefront Backtalk</a><br />
<a href="http://transfs.com/blog/">TransFs | Financially Speaking</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1210/payment-resources/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>VOIP + Credit Card Terminal = Bad Idea</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea#comments</comments>
		<pubDate>Mon, 07 Jun 2010 20:49:37 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1198</guid>
		<description><![CDATA[I&#8217;ve heard an alarming trend from a number of sources about how to hook up a credit card terminal to a VOIP (Voice Over Internet Protocol) telephone system. Several of the examples I&#8217;ve seen probably worked as well, so let&#8217;s get right to the point. Do not connect your dial-up credit card terminal to a [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve heard an alarming trend from a number of sources about how to hook up a credit card terminal to a VOIP <em>(Voice Over Internet Protocol)</em> telephone system. Several of the examples I&#8217;ve seen probably worked as well, so let&#8217;s get right to the point. </p>
<p><strong>Do not connect your dial-up credit card terminal to a VOIP connection!</strong></p>
<p>Even if you get this to properly work, which is apparently possible using an analog adapter, you are now violating a number of PCI regulations regarding data security. When you process using a dial-up connection, the data transmission <strong>is not encrypted</strong>. Since the transaction is going over a phone network which operates differently, with regards to security, than internet, it&#8217;s OK by PCI and issuer data security standards <em>(Whether the existing security is enough, is another debate)</em>. When you put that terminal on a VOIP connection, you are now transmitting unencrypted data directly over the internet.</p>
<blockquote><p>Encrypt transmission of cardholder data across open, public networks</p></blockquote>
<p>Do not do this, do not try to do this, and do not let your cable or other internet provider tell you that it&#8217;s safe and secure. I&#8217;ve heard of both Time Warner and ATT service reps telling customers that it is perfectly secure to do this. It&#8217;s not. Same thing goes for Magic Jack, Vonage, Packet 8, Comcast, or any other VOIP provider out there.</p>
<p>There is almost no way to encrypt data from your terminal over the internet unless your terminal supports end-to-end encryption, which realistically barely exists as of yet, or you have some extremely fancy and expensive telecom equipment. You would certainly know if you fall into this category.</p>
<p>If you have a VOIP only connection, you need to purchase an Ethernet compatible terminal, like a <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/verifone-vx-570/">Verifone VX570</a> or <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/verifone-vx-510/">VX510 (Dual Comm)</a>, <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/nurit-8400/">Nurit 8400</a> (Dual Comm) or a <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/hypercom-t4220/">Hypercom T4220</a>. The T4220 and VX510 are the lowest cost out of this group. Get your new terminal programmed to connect over the internet by your processor. Connect your Ethernet terminal to a spare port on your Ethernet switch, hub or router.</p>
<p>Don&#8217;t try to get your dial-up terminal to work over VOIP even though it may be possible.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>PCI-DSS compliance becoming justifiable?</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable#comments</comments>
		<pubDate>Thu, 13 May 2010 17:49:47 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Industry News]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1115</guid>
		<description><![CDATA[Since I have became involved with PCI-DSS several years ago I have always had a major complaint about PCI-DSS. Merchants do not have protection from liabilities if they take the steps to become compliant! Now before QSA&#8217;s light their torches, let me just say that I completely understand and agree that PCI Compliance &#8800; Security. [...]]]></description>
			<content:encoded><![CDATA[<p>Since I have became involved with PCI-DSS several years ago I have always had a major complaint about PCI-DSS.</p>
<p><strong>Merchants do not have protection from liabilities if they take the steps to become compliant!</strong></p>
<p>Now before QSA&#8217;s light their torches, let me just say that I completely understand and agree that <strong>PCI Compliance &ne; Security</strong>. Nevertheless, from a business perspective it&#8217;s hard to take a program like this seriously when there is no real benefit from becoming compliant. One can always argue that security is a benefit, but in reality it&#8217;s not unless you actually prevent a data loss with it, and there&#8217;s no measurable monetary benefit of something that you don&#8217;t know was prevented.</p>
<p align="center"><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/pci-stamp.png" alt="" title="pci-stamp" width="420" height="344" class="alignnone size-full wp-image-1132" /></p>
<p>I do have a strong belief, which I think is further illustrated by the slow adoption rates of level 3 and level 4 merchants, that most merchants don&#8217;t take PCI seriously. Losing customer data is nothing to be joking about, but they way PCI has been implemented with liability dumped on merchants and processors, and the fact that compliant businesses get no protection over non-compliant ones, is laughable. Independent of the PCI Council which they helped start, MasterCard now requires security scans for all merchants even if they don&#8217;t process on the Internet or over an IP connection. How can PCI possibly be taken seriously if the founding companies create independent standards after they start an organization specifically to make sure they all have the same standards?</p>
<p><strong>So what&#8217;s the big news?</strong></p>
<p>Washington state <a href="http://www.storefrontbacktalk.com/securityfraud/washington-states-new-data-breach-law-says-assessor%E2%80%94not-visa%E2%80%94has-the-final-word/">just passed a law</a> (<a href="http://apps.leg.wa.gov/documents/billdocs/2009-10/Pdf/Bills/Session%20Law%202010/1149-S2.SL.pdf">HB 1149 <sup>pdf</sup></a>) that effectively legitimizes PCI, or at least legitimizes much of the cost in becoming compliant. What this law will do is grant a merchant safe harbor from liabilities resulting from a data breach, provided that the merchant was PCI compliant when the breach occurred. It also states that the breached organization&#8217;s compliance cannot be revoked as a result of a breach. Basically, if you were compliant at the time of the breach, you are still compliant after the breach. This sort of retroactive revocation of PCI compliance has occurred in several major breaches. From my observation, this law is the first breath of reason that I have seen pushed towards PCI compliance.</p>
<p>Business owners <em>(at least in Washington)</em> can look at PCI and assume, if we become secure and become PCI compliant, we&#8217;re no longer as-liable if some extraordinary circumstance results in us losing data. The proactive response is: let&#8217;s get this taken care of, lets make sure that our data is secure, and let&#8217;s get compliant!</p>
<p>Currently that same business owner is checking [YES] to all the boxes and emailing in their questionnaire. They&#8217;re asking, so it doesn&#8217;t matter if I&#8217;m PCI compliant, I&#8217;m still fully liable for any costs and damages if someone steals my data? Hmm&#8230; [YES] to all&#8230; DONE!</p>
<p><strong>The pitfalls</strong></p>
<p>With legislation like this there are pitfalls, and probably some big ones.</p>
<p>First off, the law states that merchants must be validated compliant within 1 year of the breach occurring. 1 year is far too long for a business that was compliant to be assumed to be still compliant. Additionally, this doesn&#8217;t address the fact that the business could quite easily take steps to actually become secure, but intentionally remove them for operations sake once they pass a security scan or self assessment.</p>
<p>Second, the law is only for Washington which makes it worthless in all practicality. However, the fact that one state is passing it may push Visa/MC/AMex/Disc to look at adding real protection to PCI.</p>
<p>Third, the law doesn&#8217;t address actual costs to consumers such as fees from bounced checks or other bank and credit associated fees. Merchant&#8217;s would most likely still be liable for many of these fees <em>(assuming that there are some)</em> if they suffered a breach.</p>
<p>Lastly, the law would justify costs for becoming compliant, but could put huge costs on someone else <em>(and it&#8217;s unclear who)</em>. If the merchant does suffer a sizable breach, it&#8217;s clear that there are real costs in re-issuing cards. What&#8217;s not clear is who would end up paying for them if this law is passed.</p>
<p><strong>Meaningless?</strong></p>
<p>Until this law is adopted by the issuers or put into effect on a national level, the benefits from it on a widespread scale, are going to be little to none. I&#8217;m openly against government regulation in any industry, yours or mine, so I do hope that card issuers and PCI security council take a serious look into adopting similar measures directly into PCI. I think that providing some sort of protection like this would greatly legitimize PCI especially in the minds of the business owners that are forced to become compliant and feel that PCI does not give them any benefit. It&#8217;s time for PCI to give small business owners a real reason to become secure and to become PCI compliant. A measure like this law is that reason!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The right to accept credit cards</title>
		<link>http://www.merchantequip.com/merchant-account-blog/609/the-right-to-accept-credit-cards</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/609/the-right-to-accept-credit-cards#comments</comments>
		<pubDate>Tue, 04 May 2010 19:00:11 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=609</guid>
		<description><![CDATA[US amendment 28 guarantees businesses the right to accept credit cards, or not so much&#8230; Plastic cards have become the normal way for businesses to accept payments. Electronic transactions passed up cash and paper checks a few years ago, and are now so integrated into our lifestyles that carrying cash is far less common than [...]]]></description>
			<content:encoded><![CDATA[<p>US amendment 28 guarantees businesses the right to accept credit cards, or not so much&#8230;</p>
<p><img class="alignright size-full wp-image-1099" title="remarkable-merchant-account" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/remarkable-merchant-account.jpg" alt="" width="282" height="282" />Plastic cards have become the normal way for businesses to accept payments. Electronic transactions passed up cash and paper checks a few years ago, and are now so integrated into our lifestyles that carrying cash is far less common than several plastic cards. With this complacency to the idea of credit cards, many have become equally complacent on how much of a privilege it is to be able to take your customers card.</p>
<p><strong>Let&#8217;s quickly break down what is really happening when your customer hands you their card for a purchase.</strong></p>
<p><strong>Your customer</strong> &#8211; To start off with, your customer is granting you an enormous amount of trust that you will charge them the correct amount for their purchase, and that the product you sold them isn&#8217;t a complete piece of crap. Let&#8217;s face it, in reality you could just type in a number much higher than the actual cost, and they may not notice for several weeks. If it&#8217;s a debit card, the money&#8217;s completely gone from their checking account! With every transaction, your customer is basically giving you the key to their bank account, telling you to take the money yourself. <strong>How often do you hand your wallet of cash to a cashier, and just tell them to get it themselves?</strong></p>
<p><strong>Your processor</strong> <em>(or acquirer)</em> &#8211; Next, let&#8217;s look at the service your merchant account provider is actually providing you. Yes, they magically move the money from your customer to your bank account. However, that&#8217;s the least significant role that they play when you process a credit card. What a processor is really doing is granting your business instant credit, every time your customer makes a purchase from you. Let me word this in another way: <strong>when you accept a payment, your processor is depositing the money into your bank account on 100% credit</strong>. In 99% of cases, the processor has no collateral against the money they are giving you. Your processor may not see any revenue from your processing for 2 months, and they&#8217;re not collecting a dollar of interest on that money while they wait! Would your bank allow you to walk in every day and give you cash for your invoices only on your word that you&#8217;ll pay them in a few weeks or so, without asking for interest&#8230; Probably not. </p>
<p>If you take into consideration that there are millions of businesses in the US, and that some large businesses accept millions of dollars in credit cards a month, it is truly remarkable how much credit is continuously issued. Sure, there&#8217;s sometimes errors but fact that billions of dollars of credit is available at any time, without further qualification, without any input from a bank, and considering how smoothly the entire system works, it is simple amazing.</p>
<p>In the age of today, it&#8217;s easy to overlook the amount of trust that merchants receive when they do something as simple as swipe a card through their terminal. In addition, many interchange regulation activists skew the actual role of how processors fit into the merchant account industry, and where the fees that you pay each month actually go. Next time your business accepts a card, just remember the amount of trust that you are given for that money to end up in your bank account. It&#8217;s far more remarkable than just some electronic transfer between your customer&#8217;s bank and you.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/609/the-right-to-accept-credit-cards/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>A Comparison of 3 Alternative Payment Methods</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1027/a-comparison-of-3-alternative-payment-methods</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1027/a-comparison-of-3-alternative-payment-methods#comments</comments>
		<pubDate>Mon, 03 May 2010 20:53:14 +0000</pubDate>
		<dc:creator>jestep</dc:creator>
				<category><![CDATA[3rd Party Processors]]></category>
		<category><![CDATA[Merchant Accounts]]></category>
		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1027</guid>
		<description><![CDATA[Ecommerce website owners have typically had 2 payment methods their customers would want to pay with, Paypal and credit cards. In the the past 10 years there have been many attempts and many failures to dethrone Paypal&#8217;s dominance as the primary alternate payment method on the internet. In the past 2 years, 2 services, Google [...]]]></description>
			<content:encoded><![CDATA[<p>Ecommerce website owners have typically had 2 payment methods their customers would want to pay with, Paypal and credit cards. In the the past 10 years there have been many attempts and many failures to dethrone Paypal&#8217;s dominance as the primary alternate payment method on the internet. In the past 2 years, 2 services, Google Checkout, and Amazon Payments, have emerged as at least a distant-contender in the alternate payment landscape, both using their massive presence and customer base to establish an immediate threat to Paypal&#8217;s dominance.</p>
<p><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/alternate-payments.png" alt="" title="alternate-payments" width="525" height="61" class="alignnone size-full wp-image-1066" /></p>
<p>So, how do the 3 alternate payment methods compare to each-other from a merchant&#8217;s perspective? There are 3 main areas that merchants are generally interested in, cost, protection, and integration. The following is a comparison of Google Checkout, Paypal, and Amazon payments in these 3 areas.</p>
<h2><strong>Cost</strong></h2>
<p>Since cost is one of the most, if not the most, important aspects of any payment system, we&#8217;ll waste no time in comparing these. All of these services offer volume based pricing, meaning if you process many thousands of dollars per month the cost comes down considerable.</p>
<p><strong>Standard processing fees:</strong></p>
<table width="100%">
<thead>
<tr>
<th align="left">Monthly Volume</th>
<th align="left">Paypal</th>
<th align="left">Google Checkout</th>
<th align="left">Amazon Payments</th>
</tr>
</thead>
<tbody>
<tr>
<th align="left">0-$3,000</th>
<td>2.9% + $0.30</td>
<td>2.9% + $0.30</td>
<td>2.9% + $0.30</td>
</tr>
<tr>
<th align="left">$3,000-$10,000</th>
<td>2.5% + $0.30</td>
<td>2.5% + $0.30</td>
<td>2.5% + $0.30</td>
</tr>
<tr>
<th align="left">$10,000-$100,000</th>
<td>2.2% + $0.30</td>
<td>2.2% + $0.30</td>
<td>2.2% + $0.30</td>
</tr>
<tr>
<th align="left">&gt;$100,000</th>
<td>1.9% + $0.30</td>
<td>1.9% + $0.30</td>
<td>1.9% + $0.30</td>
</tr>
</tbody>
</table>
<p><strong>Micropayments:</strong></p>
<table width="100%">
<thead>
<tr>
<th align="left">Transaction Amount</th>
<th align="left">Paypal</th>
<th align="left">Amazon Payments</th>
</tr>
</thead>
<tbody>
<tr>
<th align="left">(&lt; $10 Amazon, &lt; $12 Paypal)</th>
<td>5% + $0.05</td>
<td>5% + $0.05</td>
</tr>
</tbody>
</table>
<p>It&#8217;s no coincidence that Google and Amazon have priced their services exactly the same as Paypal. Paypal has a terrible reputation from many sellers perspective, and I think that Amazon and Google are betting that by simply matching their costs, they will gain customers based on their quality of service.</p>
<h2><strong>Seller protection</strong></h2>
<p>Google Checkout, Paypal, and Amazon Payments are all considered 3rd party processing systems. What this means is that they are accepting payments on behalf of your business. With a traditional merchant account, your business has a direct relationship with Visa and MasterCard through your credit card processor, whereas a 3rd party processor, you are basically using the 3rd party processor&#8217;s merchant account.</p>
<p><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/credit-card-protection1.jpg" alt="" title="credit-card-protection" width="300" height="199" class="alignright size-full wp-image-1072" />Seller protection is of significant importance because the 3rd party processor is responsible for any expenses related to chargebacks and fraud from your business. If you receive a chargeback, they generally pass expenses down to your business, but the 3rd party processor is ultimately accountable to Visa and MasterCard for expenses associated with these. Google Checkout, Paypal, and Amazon Payments employ their own fraud screening, customer dispute, and chargeback management systems. Since you have very little control and access to your customer and transaction information, it is important to understand what sort of protection you have available, and what sort of pre-filtering you can setup to prevent unwanted transactions in the first place. One good note about Amazon payments in particular, is that many of the potential customers using this services have long standing relationships with Amazon.com, which can greatly reduce the number of potential fraudulent orders.</p>
<p>Account taken over? &#8211; All 3rd party processors introduce a second avenue for fraud that traditional merchant accounts do not have, which is when an account gets hacked and taken over. hacked accounts are not always immediately discovered creating a real chance that you accept payment and ship an order that was placed through a hacked account. As far as I have seen, seller protection is not extended to hacked accounts even though there is no way for you to know if you are accepting payment from a hacked account.</p>
<p>Lastly, since all 3rd party processors have their own dispute resolution systems, a customer actually has 2 chances to make a dispute or chargeback. The first is directly with the 3rd party processor through their dispute resolution system, and the second is directly with their credit card issuer. This gives customers 2 chances to recoup their money if they are unhappy with your services, or are trying to defraud a merchant by making a chargeback after receiving their order.</p>
<p><strong>Paypal</strong></p>
<p>Paypal allows for the most flexibility in the parameters that are required for you to accept a payment. You can specify countries, confirmed shipping addresses, payment types, among many others. For Paypal to provide protection to a seller a number of certain qualifications must be met otherwise Paypal will not cover the cost of a chargeback. Since a merchant can manually change their own requirements for accepting a Paypal transaction, it&#8217;s possible to inadvertently remove oneself from seller protection. </p>
<p>Additionally, likely due to the number of people using it, Paypal is probably the #1 avenue that fraud is committed over the internet. Search around and you&#8217;ll find thousands if not millions of cases where sellers have lost their money and product, and in many cases complying with all Paypal seller policies. You&#8217;ll find an equal number of upset buyers who lost money from an unethical sellers. </p>
<blockquote>
<ul>
<li> The transaction must be marked eligible or partially eligible for  Seller Protection on the Transaction Details page.</li>
<li>The item must be shipped within 7 calendar days of receiving payment  to the shipping address on the Transaction Details page, and in  accordance with our shipping requirements.</li>
<li>In the event a buyer files a claim, you need to respond to our  request for documents and other information in a timely manner.</li>
<li>The item must be a physical, tangible good that can be shipped. Your  primary residence, as listed in your PayPal account, must be in the  United States.</li>
</ul>
</blockquote>
<p>With that being said, Paypal does offer reasonable protection for merchants selling <strong>tangible products</strong> who can meet Paypal&#8217;s requirements on a transaction. Once such requirement is proof of shipping, which essentially requires a signature from the actual person whom placed the order. Anyone who has ever shipped for a business knows that the person making the purchase is the same person that signs for the package about 1% of the time, and packages are usually left on a doorstep or with the first person with a pen. In many circumstances, this does not count as verified delivery. </p>
<p>So, while Paypal is by far the most used 3rd party processor, they also offer the least amount of seller protection, and have an uncountable number of negative experiences reported with their customer service, and policies. Paypal&#8217;s risk management also leaves something to be desired, and I would say it is inevitable for a merchant&#8217;s funds to be help at some point with Paypal. While this is unrelated to seller protection it is a huge pain to send the documents to Paypal and then hope to have your account reinstated. Since Paypal does very little to pre-qualify buyers or sellers, the account-hold situation will forever be an undesired Paypal feature.</p>
<p><strong>Google Checkout</strong></p>
<p>Google offer&#8217;s excellent chargeback and fraud protection, however merchants have very little control over buyer requirements. This isn&#8217;t necessarily a problem considering that the buyer&#8217;s country / location can be a requirement for purchasing through your company via Google Checkout. Google takes a very lenient stance on chargebacks and will rarely charge a merchant for a chargeback or fraud even if the merchant loses. Google as a company has a way of commoditizing products and services and their payment service is no exception. I&#8217;ve personally seen Google absorb chargeback costs for merchants, where a merchant account provider or paypal would have billed the merchant every time. </p>
<p><strong>Google&#8217;s official policy is as follows:</strong></p>
<blockquote><p>Guaranteed Payment: Checkout&#8217;s Payment Guarantee protects 98% of Checkout orders on average &#8212; when an order is guaranteed, you get paid even if it results in a chargeback.</p>
<p>Free Protection: While merchants are typically charged for fraud protection services, Google&#8217;s comprehensive protection is free.</p>
<p>Lower Fraud Costs: Checkout&#8217;s fraud detection systems reduce fraud and manual review costs by proactively filtering out fraudulent orders.</p>
<p>More Sales: The same systems also help increase sales by identifying legitimate orders that you might otherwise mark as fraudulent.</p>
<p>Fair Treatment: Unlike other services that immediately deduct funds from you for chargebacks, Google does so only after a decision has been made as to who is at fault.</p></blockquote>
<p>With moderate success, Google applies their typical do-no-evil attitude to the Google Checkout service.</p>
<p><strong>Amazon Payments</strong><br />
Amazon offers protection similar to Google Checkout. Amazon&#8217;s official statement is:</p>
<blockquote><p>If a seller follows the Amazon.com Community Rules when listing, selling and shipping their item and, can document shipment to the  customer or that the buyer received the correct item, Amazon.com usually  does not hold the seller responsible for the reimbursement of the  claim. Otherwise, Amazon.com will usually debit the reimbursement for  the claim from the seller&#8217;s account.</p></blockquote>
<p>The gotcha here is again the &#8220;document shipment to the  customer&#8221;. As with Paypal, it is very difficult to actually prove that the person placing the order received the package.</p>
<p>Amazon payments is still a newcomer to the payments business, and has positioned themselves somewhere between Google and Paypal. Something that neither Paypal or Google Checkout have, Amazon has the huge benefit of millions of active Amazon.com customers, many with years of history purchasing from Amazon. This pre-qualification goes a long way in reducing fraudulent orders and chargebacks. Going out on a limb, I think it&#8217;s fairly safe to say that accepting payments from Amazon is going to be safer than any other payment method because of this existing relationship.</p>
<p>As far as potential customer service blunders, one thing to be careful of here is Amazon customers expect a certain degree of service when it comes to product delivery and return/refunding orders. Amazon&#8217;s policies on these are far more lax than most online retailers, so there&#8217;s definitely the potential for conflict if a customer wants to return a product outside a business&#8217;s normal policies.</p>
<p><em><strong>Non-tangible goods</strong></em></p>
<p>There&#8217;s very few processors who handle payments for non-tangible goods like digital downloads, consulting, and other services very well, 3rd party processors are hardly an exception. This is because a customer can make a chargeback with their card issuer for a number of reasons that are virtually un-challengable. Chargebacks like &#8220;product not as described&#8221; are almost impossible to beat even with superb descriptions, disclaimers, and anything else merchants try to throw at their customers. Until Visa/MC/Amex issuers change their chargeback policies, it&#8217;s unlikely that merchants will receive any relief from these types of chargebacks for non-tangible goods and services where the accuracy of the description is easily interpretable. Amazon is currently making the most public push to cater to digital sellers, and of the 3 they offer the most options and protection for this type of service.</p>
<h2>Integration</h2>
<p><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/integrate-payments.jpg" alt="" title="integrate-payments" width="300" height="200" class="alignright size-full wp-image-1075" />Integration is likely an afterthought for the business owners, but is the most important feature for a developer. All 3 providers offer integrations ranging from simple to advanced allowing developers to create unique and completely customized checkout systems. The most simple integrations require only pasting HTML into an existing website, while the advanced methods use API (Application programming interface) which allows for a seamless connection from an existing website to the processor. API&#8217;s allow for passing information like shipping and tax, in addition to a number of other data possibilities, directly to and from the website&#8217;s shopping cart.</p>
<p><strong>Paypal</strong></p>
<p>Paypal is probably the easiest to integrate with. There are literally thousands of scripts online, and just about every shopping cart software is ready to go with Paypal out of the box. Paypal offers several methods of integration.</p>
<ul>
<li>Website Payment Standard (HTML buttons to place on a website or blog)</li>
<li>Express Checkout or Website Payment Pro (API integration for simple and advanced payments on an existing shopping cart)</li>
<li>PayPal payment gateway (ex-Verisign&#8217;s Payflow gateway)</li>
</ul>
<p>The most simple Paypal integration is the buy now buttons that almost anyone could paste in their website to allow a customer to purchase an item from them.</p>
<p>Most website owners would want to use the express checkout or payments pro integration methods. These offer the cleanest user experience. I personally recommend the express checkout method of integration. Your customers start and end on your website, offering the best opportunity for the customer to complete a purchase and the least confusing checkout method possible. The API integration methods allow for uploading shipping and shopping cart information directly into Paypal, and offers support for calculating shipping and tax if the customer changes their address while on Paypal&#8217;s website. While the information and <a href="https://cms.paypal.com/us/cgi-bin/?&amp;cmd=_render-content&amp;content_ID=developer/library_code">code samples that Paypal provides</a> are severely lacking in documentation and organization, the pre-made scripts are a good start for many to get some of the more advanced checkout features going. My personal opinion on the pre-made scripts is that the <a href="http://www.saynotoflash.com/archives/when-do-you-have-too-much-code/">code is grossly overdone</a>, good programmers or those with a large number of website visitors, should really look into writing their own code to save system resources and reduce complexity.</p>
<p>The Paypal gateway is the former Verisign Payflow link and pro payment gateways. Using these requires a merchant to sign up for a more traditional merchant account through paypal. A merchant still needs to use one of the other integration methods to accept direct paypal payments from their customers.</p>
<p>Recently Paypal has been making huge advancements in <a href="https://www.x.com/index.jspa">developing their integration platforms</a>. Developers are beginning to gain access to systems allowing for aggregation, mobile payments, and a variety of other advanced payment resources. Paypal is pushing the front-line of web and mobile payment development and is desperately trying to get developers to buy into their platform, which in my opinion is working.</p>
<p><strong>Google Checkout</strong></p>
<p>Google also offers several methods of integration from the most simple paste in scripts to very advanced API functions. Google also offers email invoicing, and the Google checkout shopping cart, through their administration panel.</p>
<p>Google&#8217;s most basic integration is the <a href="http://code.google.com/apis/checkout/developer/Google_Checkout_Store_Gadget_How_To.html">Checkout Store Gadget</a> and buy now buttons,which allow website owners to visually create products and buy now buttons and then past them into their website. Multiple options can be added to a product and once clicked on the buyer can quickly make a purchase through the Google checkout system. The store gadgets are a great way to add a few products to a website, but if a store owner has an existing website or a full catalog of products, they&#8217;ll want to use one of the more advanced integration methods.</p>
<p>Google&#8217;s API offers advanced shopping cart integration and many features to streamline the purchasing process. Google also provides a number of <a href="http://code.google.com/apis/checkout/developer/index.html">well designed integration scripts</a> in just about every language to get programmers off to a quick start. The API supports fully uploading a customer&#8217;s shopping cart items and descriptions, and allows for custom shipping and tax calculations, sales, discounts, coupons and just about anything else a website owner can come up with. Google Checkout is a moderately difficult service to integrate with, but the pre-made scripts are great and most medium level programmers shouldn&#8217;t have too much trouble once familiar with Google&#8217;s API.</p>
<p>Once a user is setup with a Google checkout account, it takes about 2 clicks total to make subsequent purchases. This is very important to help sales, as 3rd party checkout systems offer a mixed bag of conversion rates compared to an on-site checkout.</p>
<p><strong>Amazon Payments</strong></p>
<p>Amazon offers several methods of integration again ranging from simple paste-in code, to the most advanced API integration.</p>
<p>Amazon&#8217;s most simple method of integration is the <a href="http://docs.amazonwebservices.com/AmazonSimplePay/latest/ASPGettingStartedGuide/">Amazon Simple Pay</a>, which is similar to Google and Paypal&#8217;s button creating features. Again like Paypal and Google, most website owners with more than a handful of products will want to use the more advanced integration methods.</p>
<p>Amazon&#8217;s API&#8217;s are very robust and offers a number of very advanced features. To list them all would be a post in itself, but they offer just about anything a business owner could want from pre and post transaction payments, variable amount donations, recurring payments, aggregation, 3rd party payments, credit card authorization and capturing, and all of the normal features a payment system would have. With the huge amount of features comes a the burden of trying to integrate Amazon&#8217;s system into a website, and I again stress that it is no easy task once a website moves past the basics.</p>
<p>The typical method that most merchants will want to use is Checkout by Amazon, which allows for a merchant to include shipping and tax information when their customer completes a purchase on Amazon&#8217;s checkout page. Checkout by Amazon will meet the needs of the majority or websites, and includes several sub-checkout methods for different situations, one allowing for a very quick conversion. The Amazon PayPhrase requires only that a customer enter their secret phrase on the checkout button, and the purchase is complete! Checkout by Amazon will not cater to developers with very special checkout needs, which is there Amazon&#8217;s most robust API comes into play, however 98% of website should be perfectly fine with Checkout by Amazon.</p>
<p>Amazon Flexible Payments represents the pinnacle of ecommerce payment technology at this point. Amazon Flexible Payments is also the obvious reason why Paypal has invested millions in their platform as it is truly a huge step ahead of anything out there. Amazon Flexible Payments allows for developers to create very complex payment mechanisms involving multiple parties and/or very flexible payment time-frames and parameters. Want to bill one customer, pay another and take a cut, Amazon Flexible Payments. Need to charge a customer a month after they download your software, Amazon Flexible Payments. If you can think it up, Amazon Flexible Payments can probably do it. However, with the huge set of features comes the difficulty in implementing them, and as stressed above is not an easy task. Amazon Flexible Payments is the most difficult payment system to integrate with, and is one of the more difficult API&#8217;s I&#8217;ve ever encountered. Amazon Flexible Payments supports only more advanced integration methods like SOAP <em>(If you don&#8217;t know what this means, don&#8217;t worry, you don&#8217;t need to know)</em>. Realistically most beginning and even some intermediate and advanced level programmers will have a very difficult time integrating with many of Amazon&#8217;s more advanced services. The benefits for the right business are worth it, but most websites will be better suited with Checkout by Amazon.</p>
<h2>Concluding thoughts</h2>
<p>I cannot make a judgment on which 3rd party payment method is better because in the end it all comes down to your customers. Naturally you should use what your customers want to pay with, and for hopes of better conversion, it is a good idea to offer your customers alternate payment methods in case they do decide to use them. In the almost 10 years I&#8217;ve been running ecommerce websites, I can still honestly say that nothing beats straight credit card acceptance, through a payment gateway, at least for tangible products. Paypal makes a very strong statement if your business sells very-tech related products. If I were to pick 2 payment methods that I think every ecommerce website will benefit from, it would be direct credit card acceptance through a merchant account / payment gateway and Paypal. Just based on the usage, these 2 are absolutely essential. Google and Amazon have some amazing features, usability, and speed, but until more customers want to pay with them, they are still not on a comparable level.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1027/a-comparison-of-3-alternative-payment-methods/feed</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
	</channel>
</rss>
