When you initially set up your merchant account, your business name (DBA) is normally used as your descriptor. The descriptor is the name that your customer will see on their credit card statement. While this is a fairly simply process, many times processors mess up the descriptor, or they put something that a customer would not immediately associate with the business they just purchased from. A long business name can be difficult to logically squeeze into the few characters allowed in a descriptor. Websites are especially susceptible to this dissociation, as a domain name may not directly match the business name. Some customers will remember the domain, and some the business. In most cases I recommend using the domain name rather than the business name. If they don’t recognize it, they can pull up the website: “Oh yeah, I remember buying something here.”

Here’s an actual screen shot from my bank account. I have no idea what this is…

When you open your merchant account, you should always run a test transaction (NOT WITH THE MERCHANT ACCOUNT OWNER’S CARD!) for a few dollars to make sure the money goes into the correct bank account. This is a perfect time to check the descriptor and make sure it is something that makes sense.

These types of chargebacks are a waste of money and time for business owners to deal with especially since they are normally legitimate transactions. Make sure your descriptor looks the way you want it to. If you start receiving “Cardholder does not recognize transaction ” chargebacks, it is a good idea to verify that your descriptor is not what is causing the problem. If there’s something wrong with it, your processor should be able to fix it for you.

Lastly, operating multiple websites on the same merchant account will often result in an increase of chargebacks. Unless the products are the same and the domain names are similar enough that a customer will recognize the charge on their statement, business’s should have a unique merchant account for every website they operate. Visa and MC routinely shut merchants down for operating multiple unrelated websites on the same merchant account. How do they find out about them? Almost 100% of the time it’s from: “Cardholder does not recognize transaction” chargebacks.

If you find any ridiculous descriptors on your statements feel free to send them to me, and I will post them up here. Use a service like photobucket or flickr to upload them and send me the link to your photos through the form.

I stumbled on a Visa operating regulation that I was not aware of. “You cannot require an ID in order to complete a Credit transaction.” Furthermore, you cannot decline or refuse a transaction if your customer refuses to provide an ID.

Although Visa rules do not preclude merchants from asking for cardholder ID, merchants cannot make an ID a condition of acceptance. Therefore, merchants cannot refuse to complete a purchase transaction because a cardholder refuses to provide ID. Visa believes merchants should not ask for ID as part of their regular card acceptance procedures.

The author was completely wrong as far as MasterCard goes, who takes a different approach to the situation…

For unique transactions processed in a face-to-face environment (with the exception of truck stop transactions and card-read transactions where a non-signature CVM is used), request personal identification of the cardholder in the form of an unexpired, official government document. Compare the signature on the personal identification with the signature on the card.

American express is a little vague, but still states that the identity should be verified…

Verify that the customer is the Card-member. Cards are not transferable.

It’s actually hard for me to believe that Visa goes this far in trying to protect their cardholder’s convenience at the expense of their merchants being exposed to potential fraud. I strongly recommend checking the ID of every card holder. No regulation prevents a merchant from asking for an ID, and I can’t imagine a customer seriously refusing under any normal circumstance. Merchants are not allowed to ask for an ID on “PIN” debit transactions where a customer enters their PIN number into a pinpad. For signature debit, where the card is processed like a credit card, treat the transaction just like credit and ask for an ID.

If anyone would like to see the various card regulations, they can be found here:
Visa
MasterCard Chargeback Guide
AMEX

Discover’s site requires registration, and I was unable to register with the Discover numbers of the 4 merchant accounts that we have. If anyone has a copy of Discover operating regulations, I would love to see them.

I’ll try to answer these question in a weekly Dear MSP post.

Thanks
Jamie

I see merchants on a daily basis surcharging for credit transactions, and while I see it more as an inconvenience, the government doesn’t see it the same way. Currently there are 10 states with laws against credit surcharging, California, Colorado, Connecticut, Florida, Kansas, Maine, Massachusetts, New York, Oklahoma and Texas. Some of these states have very easy ways to report businesses that are illegally surcharging, creating a quick path to fines, bad publicity, and lawsuits.

Apart from state laws, all that an angry customer needs to do is call their card issuer and report the business. The issuer passes the message down to the business’s processor, who then tells the business to stop. If more complaints are received, fines are assessed ($10,000 – $20,000 for the first offense), and then the business is shut down and placed on the TMF list by the issuer. They are then prohibited from accepting credit cards by just about every processor in the world until they get off the list.

It’s true that many businesses get away with surcharging for a long time, but I urge any business owner to seriously consider the potential consequences from breaking the surcharging regulations. It may seem like a logical idea from a financial standpoint, but the repercussions can be quick and severe.

Just to dispel any hopes that these might be going away soon, they’re not. If anything, PCI is going to get much stricter, as congress has openly stated that PCI-DSS is not nearly enough.

How did we get to this point?

The entire PCI-DSS concept materialized about 5 years ago when Visa created PCI and MasterCard created a program called SDP. By creating a security framework based on history, logic, and anticipated weaknesses, these programs were designed to be a model for safely storing and transmitting credit card data. Eventually the issuers joined together and created the PCI security council, which was supposed to be an envelope organization in charge of PCI standards. The idea was that it would be far easier for merchants to handle a single version of PCI, rather than Visa, MasterCard, Amex and Discover separately having their own standards. Over time, PCI-DSS gained an adoption time-line, and became much more organized. PCI covers general operating principals, but is primarily geared to network and data security, as the internet and broadband access have created unseen opportunity for thieves to remotely steal large amounts of credit card and sensitive data.

In the beginning, PCI-DSS was rightfully pushed to large merchants (level 1, and 2) because the affect from a Level 1 data breach could be massive, and the processing and storage methods and procedures that these large companies have are often vast. Becoming PCI compliant for large companies is no easy task even if their systems are already secure beyond PCI standards.

Once level 1 and 2 merchants were compliant, or in the process of becoming compliant, PCI focused on the smaller level 3 and 4 merchants. Level 3 and 4 merchants are generally much smaller and simpler organizations than level 1 and 2 merchants, but there’s millions of them, which has created an entirely different and no less challenging task of compliance, which leads us to where we are now…

Where are we now?

We are now at the point where processors (We’ll get to why it’s the processors…) are forcing their level 4 merchants to become compliant. Since only a small handful of the millions of level 4 merchants were compliant before 2008, it’s an enormous task to get them compliant. There’s so many level 4 merchants in the US that most processors outsourced compliance to a 3rd party such as SecurityMetrics. Most merchants who were not PCI compliant were charged a PCI setup fee (Monthly, Quarterly, or Yearly), and most will be further charged if they do not become compliant. Just about every processor’s PCI fees and methods are different, but just about every processor now has them.

At this point merchants of any size and type must get PCI compliant of face fines and or potential closure.

What PCI has never been.

There’s a huge misconception that PCI provides security, but this is not the case.

PCI has never been a seal of security. It does not provide security. It is not the ends-all solution to becoming secure and most would agree that it isn’t near enough.

It is a standard, a framework, covering the minimum steps to be somewhat secure. If at any time all of the requirements of PCI are not met, a business is not compliant and is not secure. You cannot get compliant and then not worry about security until you fill out the PCI questionnaire next year. Security can only be achieved if you are always secure. And security usually requires work well beyond what is covered in PCI.

Where things went awry…

There are 2 factors that I contribute to the mess that everyone is seeing right now.

First off, MasterCard broke away from PCI and made some of their own, and more strict, policies. MasterCard requires all merchants to get security scans even if they don’t process over the internet or an IP connection. Unfortunately, the lack of ambiguity in this policy creates a lot more work for small merchants who don’t process over the internet. Logically this makes no sense, and I believe is a truly terrible policy by MasterCard’s administration. Even so, I don’t see them reversing their position, ever…

Secondly, processors were made accountable for breaches and for compliance of level 4 merchants. This is extremely irresponsible because processors do not have the means of providing these services, and the issuers are making the majority of the money from merchants’ credit card processing. By dumping this on processors, one can only expect them to charge for the huge amount of time that is required to get this task done. About a million PCI scanning companies popped up in the past 2 years because there’s just so much scanning that needs to be done.

Why PCI (Not security!) is a joke!

I had a business owner explain to me how easy it was to get PCI compliant.. All he needed to do was check YES in all the boxes.

When I explained to another business owner a few weeks ago that even if they get PCI compliant, PCI does not provide any protection from fines or other fees if they do suffer a breach, he just laughed.

And that’s the way that most people view it, a joke. PCI is a facade to placate consumers and the government (Who’s not buying it) into thinking that issuers are actually trying to do something for data security. In reality, if that was the case PCI would provide some damn protection to those who take the steps to get secure and go through the hassle of becoming compliant, and it would be significantly more strict. PCI doesn’t go far enough to properly secure data, so instead of helping anyone, another multi-billion dollar industry was created (The PCI Scanning Folks) on the backs of businesses and it isn’t actually doing any good.

I fear that until there’s some benefit from becoming compliant, and until issuers stop creating ridiculous standards like forcing merchants to get a security scan when they don’t store or process cards over the internet, PCI wont be taken seriously. And truly, what is the deal with all the scanning?

Some more good PCI related resources:
Thoughts and Notes from PCI DSS Hearing in US House of Representatives
PCI DSS checklist: Mistakes and problem areas to avoid
PGP Archive for PCI-DSS

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 of losing customer data just by the fact that they have it. Apart from PCI, it’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.

But, sometimes we still need to store credit card numbers, so how do we do it?

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’s data, so your reputation is on the line, but not necessarily your wallet. What’s even better is that with some of today’s available services, outsourcing this can give us an easier method of re-billing our customer than if we could easily store credit cards.

Who can we store these with?

This is the easy part. Your payment gateway may have a customer storage mechanism, or customer vault. If it doesn’t, find one that does.

What this does is store your customer’s information and credit card number in the payment gateway’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’s stored card.

With a system like this, a developer can create a custom recurring billing system, or a user friendly “remember card” feature with your ecommerce site’s checkout system.

Which gateways support this?

The Network Merchants Gateway which we developed an integration module a few weeks ago, supports customer storage at a very low cost per month. Network Merchant’s customer storage is called the Customer Vault.

Authorize.net has a similar system called the Customer Information Manager.

There’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.

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 in Network Merchant’s secure customer vault. The API allows charging customers stored in the vault without a merchant ever storing a credit card number.

View and download the class here »

When a new business goes out to setup a merchant account, they will be asked for a voided check. Many processors will no longer accept temporary checks, so we developed this too to print a voided check until you get your real ones.

Generally a merchant can ask their bank for a letter of an accounts existence, but many banks are now refusing to do this, in an effort to force customers to process with them. Since it’s perfectly legal to print your own checks, here’s our response to this dilemma.

So, if you need a voided check, take a look at our Voided Check Generator.

Phase V – July 1, 2010
Phase V mandates the use of payment applications that support PCI OSS compliance, requiring acquirers, merchants and agents to use only those payment applications that can be validated as PA-DSS compliant.

Put this into perspective. There are currently millions of websites using paid and open source software for their online stores. Software like Oscommerce, Zen Cart, Magento, and others have millions of users. There are only 2, online store software packages that are PA-DSS compliant. If there is not a mass-movement to get software PA-DSS compliant in the next year, almost every single online store will be out of compliance and subject to fines, or being shut down. This is only a small part of the problem. There’s still thousands of retail businesses using older payment software and the cost of upgrading would be in the millions, assuming it’s even possible.

As written by Evan Schuman
“Essentially, this standard could cause merchants of all sizes in all industries to have to switch payment application vendors.”

Where the real mess begins…

There are currently about 40 companies certified to perform PA-DSS validation. The cost to certify a single payment application could be $100,000 or more if the application is extremely complicated. There is an additional “mandatory” yearly fee of $1250 just to be listed as a Validated Payment Application. Based on cost, and complexity, there’s not many shopping cart software providers that can come close to getting PA-DSS certified in the next year. Even then, that still leaves the open source solutions, which the majority of all ecommerce sites are using.

From Rick Wilson
“What about home grown and open source shopping cart solutions? What happens to them on July 1st, 2010. I asked this question to our auditor and his answer was telling, he said that “essentially if an application can’t be PA-DSS certified because it’s not developed by a single entity for example, then the service provider of that entity will need to become PCI Level 1 certified in order to keep offering that and be in compliance”.

Level 1 certification is nearly as expensive as PA-DSS certification, so don’t expect any relief from if you’re using a custom or open source solution. They’ve truly left no way out this time…

In conclusion…

We’re about to experience a payment industry nightmare potentially having the ability to halt commerce as we know it. If you thought that the $20 per month fee from your processor was bad, you’ll really hate the $50,000 bill when you go to get level 1 certified. If Visa takes the hard-line stance that merchants not using PA-DSS certified software get shut down, it’s going to get really ugly. The current focus of the processing industry is on PCI-DSS compliance and a slew of new fees and charges related to it. But, in about a year, we’re going to see the true fallout of implementing ineffective regulations without foresight into what it actually takes to adopt them, or whether they actually do anything. The only thing we got out of the congressional hearing on PCI is that congress thinks it’s not enough, and merchants think it’s way too much.

Houston, we’re about to have a problem!

Related reading…
PA DSS in One Easy Lesson…Sort Of
PA DSS Is Remarkably Misunderstood
PA-DSS and Ecommerce Web Hosting

As always, please send any recommendations of websites that should be included. Please keep in mind that blogs and websites will only be added if they’re mostly objective. Many of the merchant account blogs out there are only for self-promotional purposes, and these will not be included in the search engine.

Equipment:
http://www.magtek.com/
http://www.apriva.com/
http://www.bluebamboo.com/
http://www.waysystems.com
http://www.dejavoosystems.com
http://www.hypercom.com/
http://www.verifone.com/
http://www.ingenico.com/
http://www.magtek.com/
http://www.chargeanywhere.com/
http://www.commerciant.com/

Blogs:
http://www.paysimple.com/blog
http://paymenttalk.blogspot.com/
http://www.glenbrook.com/
http://blog.bwplawyer.com/
http://googlecheckout.blogspot.com/
http://www.paymentsystemsblog.com/
http://www.amazonpaymentsblog.com/amazon_payments_blog/
http://www.andyorrock.com/
http://blog.elementps.com/element_payment_solutions/
https://www.thepaypalblog.com/
http://waytoohigh.wordpress.com/
http://pindebit.blogspot.com/
http://aneace.blogspot.com/
http://www.storefrontbacktalk.com/
http://www.merchant-account-services.org/blog/
http://digitaldebateblogs.typepad.com/digital_money/
http://www.creditcardsonline101.com/

Data Security:
http://pcidss.wordpress.com/
http://www.pcianswers.com/
http://www.askaboutpci.com/