Archive for June, 2010

SQUARE, a venture funded startup, debuted in December 2009 as a ‘revolutionary’ payment mechanism.  The device is a small square magnetic stripe reader that fits into the audio port of an iphone and allows consumers as well as merchants to accept credit card payments.  Square did not require a merchant account instead was designed to use a ‘master merchant’ type account which agregated transactions under a single merchant account.  For many of us (at least this author) that have been involved in payment card security and risk for sometime, it appeared to be a very risky business model.  It appears that Square now has some concerns.  In an article posted on mocoNews.net the founder of Square, Jack Dorsey states that the Square delivery has been suspended as:  ““We need to strengthen our underwriting infrastructure so that we can handle the huge demand for readers and still manage the risk of chargebacks and fraud,”.  Additionally, it appears that the device may not have been ready for prime time.  The other co-founder, Jim McKelvey stated that: ““We’ve let our excitement get the best of us and have released parts of Square before they were fully baked”. 

While it is never good to see a company struggle, kudos should be given to Square for addressing the fraud and risk issues before they got out of hand.  Unfortunately, it is often the merchant or consumer that suffers when a solution is not ready for the challenges of accepting credit card payments.  Although a novel idea to allow payments to be accepted without a merchant account there are distinct advantages to having a merchant account.  With a merchant account, all transactions are guaranteed by the card brands (assuming authentication etc. are appropriate) and there are protections in place for both the buyer and seller.  Whether this exists and to what degree is not so clear when processes are established that allows peoplet make purchases without a merchant account. 

ProPay specializes in providing merchant accounts with near immediate underwriting.  As a single source provider, ProPay allows companies (or individuals) to sign up for an account and start accepting payment cards almost immediately without the need for a third party gateway or other processor.  Additionally, ProPay does not charge a monthly fee and our rates are very competitive.  To signup for a merchant account today click here.

There has recently been a rise in the rate of social networking or recruiting scams in which a fraudster attempts to dupe an unsuspecting individual into opening merchant accounts under the individual’s own name that can then be used to process stolen credit cards.

Due to the availability of information on many social networks it is relatively easy for a fraudster to find those people who are unemployed or need extra income to make ends meet. Once the fraudster identifies a target, the fraudster presents the target with an opportunity to make money quickly and easily. Essentially the fraudster will convince the victim to open one or more merchant accounts under the victim’s personal information and provide the victim with stolen credit card information claiming the charges are for software licenses or some other non-tangible product. The victim is told to process transactions through the victim’s own merchant account, keep a certain percentage of all sales, and then is asked to send the remaining funds to the fraudster via a money transmitter that is difficult to trace.
Clearly this creates a unique type of fraud to detect and prevent. Since the individual signing up for the account is truly who they say they are, few red flags go up during a routine sign up and identity validation process. However, these scams are certainly not undetectable. The key, as with most fraud scams, is to understand how it works. It is crucial that situations like these are detected and resolved quickly before the chargebacks come in and the victims find themselves owing funds they don’t have.

This, like many fraudulent situations, can generally be resolved through due diligence and a little common sense. Research any potential opportunity that comes your way, and make sure you verify its legitimacy. Remember, the old adage is often correct, if something seems too good to be true it probably is.

In an article published on Friday in the USA Today, Microsoft launched a coalition intended to support the prevention of cybercrime.  The Internet Fraud Alert Center which is headed by MS and manged by the National Cyber Forensics and Training Alliance will server as a reporting hub for stolen information.  According to the article when stolen data is located by researchers it will be provided to the FAC which will then provide the information to the appropriate banks (in the case of credit card numbers) or the authorities in the case of social security numbers and other PII.  This is a continuing trend within the industry and is consistent with some of the other initiatives.

With Visa’ deadline for PA DSS looming and many companies focused upon complying with the PCI DSS it is a good time to give some practical advice on how to easily (more easily) comply with the standard.  For review, the PCI DSS applies to any organization that stores, transmits, or processes Cardholder Data.  In simple terms if you dont’ store, transmit, or process CHD then you don’t have to comply with the requirements.  The question then is what is CHD and how do you not store, transmit or process.  It is actually more easily accomplished then may first be apparent.

Carholder Data consists of the Primary Account Number (PAN) at a minimum and also includes the Cardholder Name, Expiration Date, and Service Code IF they are stored in conjunction with the PAN.  As can be seen, the determining element as to whether or not CHD is present is the PAN.  In short…no PAN…not Cardholder Data….no PCI.

There are several techniques and technologies that can be used to remove the PAN from the transaction process.  Tokenization removes the need to store PAN thus removing one of the three legs (store, transmit, and/or process) and thereby removes many of the requirements which apply to storage of data. (PCI DSS 3.4 as an example).  To address the other two legs (transmit/process) it is wise to evaluate Point to Point (end to end) encryption technologies.  There is a MAJOR caveat here, however.  The solution must not allow the merchant to decrypt the data. If the solutions is using public key crypto or some variation (DUKPT, for example) which doe not permit the merchant to decrypt the data then the data being transmitted would not be considered CHD and therefore would not be in scope of the PCI DSS.

Another technology that can be effectively used in eCommerce environments is to bypass the merchant location and enable the transaction data to flow directly from the consumer to the processor or gateway.  The processor or gateway would then authorize the transaction and return a token or other acknowledgment to the merchant.  Secure ‘redirects’ (I hate that word but it works here) allow merchants to accept credit card transactions without actually touching the data.

Each of these technologies used alone or together reduces and may eliminate the need to comply with the PCI DSS requirements.  Obviously the discussion is more detailed than what can be addressed in this blog post.  For more information please read the following whitepapers which describe the concepts in detail.  The Data Dilemma 2010., ProtectPay Overview 2010.

The good folks at Visa have recently published a new blog that should be on everyone’s short list of reading.  The blog is called Drop the Data and can be found here.  It provides great information on a number of security related topics.  Make sure you take a spin through the site to stay abreast of any new developments.