High Risk Mechant Account: Third Party Payments Aggregation
Posted on Thursday, April 24, 2008 by Bryan Johnson
Third party payments aggregation (TPPA) is a description used for merchants that are selling a product or service that they do not own. The best example of a TPPA (aggregator) is PayPal. They simply facilitate the exchange of money between two parties.
There are, however, different shades of TPPA's. For example, an online air travel booking site may charge both their service fee and the actual airfare in a single transaction. If the merchant were only charging their service fee, they would not fall into the TPPA category as they are simply charging for the service they provide. But because they are also charging a credit card for a product they do not own, an airfare ticket, they fall into the TPPA category.
The value proposition of a TPPA is clear to both consumers and merchants, but the increased risk is not normally understood as well by the merchant. There are two reasons why TPPA's are considered higher risk in the credit card processing industry: 1) The merchant has reduced control over the quality and delivery of the product being sold, and 2) The merchant is being trusted to pay the third party for the money they've collected on their behalf.
Here is an example of TPPA risk. Let's say over a 30 day period an ecommerce merchant sells $1,000,000 worth of tickets for a third party event (something they don't control/own). The merchant could collect the $1,000,000 dollars from the cardholders, not buy the tickets from the event organizer and then skip town with a suit case full of money. Each customer would initiate a chargeback because they never received the tickets they purchsed. When the chargebacks are initiated, the issuing bank will credit the cardholders account and merchant processor will in turn try to debit the merchant's account which does not have any money.
The example could just have easily been that the event organizers cancel the event at the last minute for legitimate reasons and then refuse to refund the merchant who sold the tickets on their behalf. Either way, the point is that an unrelated third party greatly complicates the risk of processing risk.
Because the Card Associations have discouraged the practice of TPPA and the increased risk, most merchant account providers are justifiably reluctant to underwrite these types of accounts. That is not to say that merchant accounts cannot get approved for TPP processing, it is just more difficult and the underwriting conditions will more likely include a reserve and other similar safeguards.
Braintree Solutions:
Multi-Merchant - enabling multiple merchant accounts in a single application
Amazon FPS
Posted on Wednesday, April 23, 2008 by Bryan Johnson
Jim Daly of Digital Transactions wrote a good piece on Amazon's Flexible Payment System (FPS) in the April 08 issue. Here are some of the key takeaways:
- Amazon's investment in alternative payment provider Bill Me Later last December was their first public move into the payment processing space. Using Bill Me Later, Amazon expects to not only lower their own transaction costs (by ~.50 bps) but hopes to also increase sales by capturing more impulse buyers.
- The launch of FPS is most likely part of a larger play for Amazon, like......
- FPS pricing has some customers unhappy. For example, the 1.5% on bank transfers and amounts charged on stored value balances (Amazon essentially double dipping).
- Beta user Buxfer gave the FPS technology high reviews but cited the requirement that both buyer and seller need an Amazon account as the biggest drawback.
From my standpoint, I would call out two things. First, I wonder how many ewallet providers will be able to cross the tipping point of scale with both the consumer and merchant. If there aren't enough consumers demanding the payment option merchants won't offer it as an option and if merchants don't offer it as an option consumers won't use it.
Of the three major players, PayPal has become much more inclusive in their offering, Amazon remains exclusive (both buyer and seller must have an account), and without a larger user base to begin with, I just don't think Google checkout will be able to pick up enough steam.
Then of course there is a rush of new ewallet type providers (using a device like a mobile phone or payment instrument such as a phone number) crowding their way into the market as a preferred payment providers. Secondly, I think the most significant thing FPS did was build sophisticated payment processing logic on their end - instead of making that the merchants responsibility. In nearly all the payment systems today, the logic is built and maintained by the merchant. At the same time, in reading through all of it's capabilities - I'm left wondering, who again needs this?
The article is only available in pdf format and I had to post the entire April issue. If you're interested in reading the article it starts on page 24.
Payment Application Data Security Standard (PA-DSS) v1.1
Posted on Wednesday, April 16, 2008 by Bryan Johnson
The PCI Security Standards Council released version 1.1 of the PA-DSS today. The purpose of this program, which was formerly managed by Visa, is to ensure that software vendors and others that develop secure payment applications are not storing prohibited data and are complying with the PCI DSS. It applies to payment applications that are sold, distributed, or licensed to third parties.
Here are a few take aways:- This fall the council will roll out a program to maintain a list of validated payment applications.
- The Council will begin qualifying companies to become Payment Application Qualified Security Assessors (PA-QSAs) who can perform PA-DSS assessments and audits. (see also this post on QSA’s)
- PA-DSS FAQ’s
PCI Compliance and the cost of a credit card breach
Posted on Tuesday, April 15, 2008 by Bryan Johnson
TJX is now the poster child for credit card data breaches. Starting in July 2005, hackers spent 18 months exploiting weak wireless network security outside of thousands of TJX owned stores and downloaded nearly 100 million credit card numbers and other personal information. TJX recently estimated that the breach will cost them $118 million. Others, such as Forrester, estimate it will cost them $1.35 billion after including legal fees, call center costs, regulatory fines, etc.
While TJX has received all the recent attention, breaches are occurring more often than many realize. The exact number is unknown because only 31 states currently have laws requiring disclosure. One thing is for sure: if a business gets breached, the financial, business and PR risks are tremendous. A Forrester report determined that the cost per breached record will be anywhere from $90 to $305.
The profitable world of stealing credit card data The spike in this type of criminal activity is attributable to the lucrative business of selling stolen credit card information. Depending on the quality, the selling price of a single record can easily be $100. Criminals are using a host of tactics to steal credit card data.
One of the most common methods is remote access to servers that house the data, like in the case of TJX. WEP 104-bit encryption can be cracked in under a minute on an 802.11g network by using active ARP-relay packet-injection techniques. Another very common approach is "skimming", a practice through which an employee attaches an electronic reader to the point of sale machine to steal cardholder information including name, credit card number, and the CVV2 code (three or four-digit number on the front or back of the card). Employees have also been known to write down this information. In ecommerce environments, cyber criminals are using SQL Injection, Cross Site Scripting (XSS), and Buffer Overflow attacks.
PCI Compliance overview
The driving force behind the effort to secure all credit card data is the PCI Security Standards Council, which was founded by Visa, MasterCard, American Express, Discover and JCB. They have mandated that businesses meet 12 security requirements in order to protect cardholder data. To provide proper incentives, the Card Associations have offered both carrots and sticks. As a carrot, merchants are offered protection from PCI-related fines, which can be as high as $500,000 per incident, if they are compliant at the time of the breach - something called Safe Harbor.
As a stick, merchants can face the above-mentioned fines when breached as well as be fined for non-compliance. Some card brands have threatened to levy fines against larger merchants, up to $25,000 per month, until they obtain compliance. To start the process of becoming PCI compliant, a company should consider engaging a Qualified Security Assessor (QSA) who can advise regarding remediation and are approved to complete the official assessments for the Card Associations. There are fewer than 100 companies that offer these services. A few examples include Accuvant, Security Metrics, and Trustwave. The process of becoming compliant may take anywhere from 3 month to 2 years, depending on the business size and current IT and security infrastructure.
The cost and process of becoming PCI Compliant Becoming compliant can be a time-consuming, costly, and considerably complex effort. Gartner recently estimated that the nation's largest merchants will spend $568,000 on average during 2007 to meet the mandated requirements.
Taking matters into your own hands A few things that can be done right away is making sure prohibited information is being purged after authorization. That information includes full track data (on the magnetic strip), CVV2, CVC2 and CID codes (three and four-digit codes) and PIN data. If businesses need to store name, credit card number and expiration date, it needs to be secured either internally or stored remotely. Credit card tokenization, a remote storage technology, allows for a unique customer ID to be created for each record which is then used to remotely initiate transactions or change customer files without ever handling any sensitive credit card data.
Other simple ways to better protect from breaches include tightening remote access controls, changing wireless network security from WEP to WPA, properly configuring firewalls, changing vendor default passwords, and using encryption to transmit all sensitive data.
In summary
Regardless of a business's current situation, the cost of a breach can be enormous. TJX, a $17 billion dollar retailer will be able to weather the storm, but a smaller organization may not have the same financial depth, which means the consequences may be much more severe. So whether or not the required resources are available to pursue PCI Compliance and proper data storage, it might not be a bad idea to make it a priority in your organization.
Other related posts:
PCI DSS Compliance basics for credit card security
Braintree solutions: The Smart Approach for PCI DSS Compliance
PCI Compliance and Temporarily Storing the CVV2 Value
Posted on Friday, April 04, 2008 by Bryan Johnson
I’ve been working with software provider in the restaurant space and one of the questions that came up was whether a restaurant can temporarily store the Card Verification Value (CVV2, CVC2 andCID)when taking a reservation to later charge the card if the customer does not show. The word from the PCI Security Standards Council has been that the CVV value can never be stored. There are however a few exceptions provided for merchants that have a need to ‘store and forward’ the data.
I spoke to a few folks about this including Brian Serra CISSP, QSA from Accuvant and Michael Dahn at the Aegenis Group. For merchants that are given an exception to temporarily store the CVV value, there is always a limited number of days the data can be retained. It’s also ultimately up the specific merchant’s acquirer whether the practice will be allowed – as they bear the responsibility for the merchant’s compliance.
Other related posts: The cost of a credit card breach PCI Compliance basics The cost to become PCI Compliant
CVV2 Does Not Affect Credit Card Rate Qualification
Posted on Friday, April 04, 2008 by Bryan Johnson
Most merchants mistakenly believe that processing a cardholder's three or four digit value (CVV2, CVC2 or CID)for a card not present transaction (e.g. ecommerce) will help qualify for lower credit card rates. The CVV2 value is only valuable to protect against credit card fraud and has nothing to do with rate qualification. These three and four digit codes aremost often confused with Address Verification Service (AVS) which can be used to qualify for lower credit card rates.
CVV stands for Card Verification Value and was introduced by MasterCard in 1997 and Visa in 2001. For swiped transactions, the value is referred to as CVV1. Each of the card brands has its own acronym:
Visa: CVV2 - Card Verification Value MasterCard: CVC2 - Card Validation Code American Express: CID Unique Card Code (and 4 digits) Discover: CID Card Identification Number
Merchants are able to configure payment processing systems to accept or decline transaction requests based upon the match or mismatch of CVV2, CVC2 orCIDinformation. So for example, if a merchant creates a rule to decline all transactions where the CVV2, CVC2 orCIDvalue does not match, the authorization request could be successful with the issuing bank, but the transaction will be denied by the merchant. Even though the transaction was denied by the merchant, the consumer's card will still be authorized.
PCI DSS Compliance prohibits merchants from storing the CVV2, CVC2 or CID values. For recurring billing, merchants can accept and validate the code during the initial authorization but cannot store it for additional transactions. After the initial validation, there really is no value in storing it.
Other Related Blog Posts
PCI Prohibits the Storage of CVV2 Data
PCI DSS Compliance Basics
Where do Credit Card Fees Come From?
Sample Completed SAQ A Version 1.1
Posted on Saturday, March 08, 2008 by Bryan Johnson
We now have a downloadable SAQ A Version 1.1 that's been completed by a QSA as if our outsourced PCI Compliance solutions were in place. If you've been in or about to get into the PCI trenches, you'll be pleasantly surprised with the advantages and simplicity of this approach.
If you're new to PCI Compliance, merchants are required to fill out a Self Assessment Questionnaire (SAQ). A SAQ is designed to be a validation tool and checklist of sorts. Last month the Council moved away from a one size fits all approach that they had for years and rolled out four different SAQ's that better address varied merchant environments (Here is a more detailed overview of the changes, SAQ's, and other resources). SAQ A Version 1.1 is reserved for merchants that outsource all processing, transmission and storage of cardholder data.
White Paper on PCI DSS Compliance
Posted on Friday, March 07, 2008 by Bryan Johnson
A White Paper on our PCI Compliance solution is now available. Our solution helps merchants reduce the number of required controls from 200+ to 20 or less. This reduction translates into significant time and cost savings as well as increased security.
Other related posts:
The cost of a credit card breach
PCI Compliance basics
The cost to become PCI Compliant
A Do It Yourself Guide for PCI DSS Compliance
Posted on Tuesday, March 04, 2008 by Bryan Johnson
Security consultant Joel Dubin, CISSP, has written a helpful article for merchants that are seeking to become PCI DSS Compliant without engaging outside consultants. Here is an except (and the entire article):
Any company that accepts credit cards for its business is subject to the Payment Card Industry Data Security Standard (PCI DSS). As it is with other regulations, such as the Sarbanes-Oxley Act,the biggest component of being compliant is proving you're compliant. While it's unlikely a credit card company would make the effort to catch a midmarket company in the act, it can cut a business off at the knees for noncompliance. A business can be fined, or worse -- cut off completely from being able to process credit cards.
Better to have and not need, than to need and not have. PCI audit is something you can do without hiring an outside consultant. Your secret weapon: Documentation.
Auditors have a mystical attachment to paperwork, and if it isn't in writing in front of them, they won't see it. The only way to prove to an auditor that your company is compliant with PCI is to document every control required by the standard. In the eyes of the auditor, if a control isn't documented, it isn't compliant.
First, appoint someone to be the contact person for PCI auditors. This isn't a full-time job and doesn't necessarily even have to be someone from the IT department. The important thing is that this person has a sufficient background in IT and understands the technical terminology in the standard.
Next, go to the PCI Security Standards Council website and download three documents: the standard requirements, the self-assessment questionnaire and the security audit procedures.
Other related posts:
The cost of a credit card breach
PCI Compliance basics
The cost to become PCI Compliant
Visa PCI DSS Compliance Data Security Alert: Network Vulnerabilites for Financial Institutions
Posted on Tuesday, February 26, 2008 by Bryan Johnson
Visa's Fraud Investigations and Incident Management group released a data security alert for financial institutions. They're cautioning that hackers are targeting web facing systems that may be vulnerable to breach to steal cardholder information and introduce malicious software (malware) into internal networks. Visa has documented the following successful penetration incidents:
- Establishing continuous remote access to the internal network through a 'back door'
- Compromising internal systems passwords using a password-cracking system
- Mapping the internal network infrastructure
They make the following recommendations to guard against these threats:
Failure to use a Network-Based Intrusion Detection System Network-based intrusion detection systems (NIDS) are designed to monitor network traffic in order to distinguish between normal network activity and abnormal or suspicious activity that may identify an attack. The early detection of a network compromise is difficult without adequate network monitoring and intrusion detection capabilities. Risk Impact: Without the means to detect suspicious network events, network compromises can remain undetected. Risk Mitigation: In conjunction with achieving full compliance with the Payment Card Industry Data Security Standard, and implementing a robust security monitoring strategy, deploying NIDS can detect and mitigate suspicious events. Suspicious events that may be symptoms of a successful compromise include:
- Unexpected outbound transmission of sensitive data
- Network connections originating from internal critical systems that would not normally communicate outside the network, including untrusted networks and the Internet
- Failure to utilize a Host-Based Intrusion Detection System - Host-based intrusion detection systems (HIDS) are designed to monitor the behavior of host / computer systems to distinguish between normal activity and abnormal or suspicious activities. A key function of HIDS is to detect unknown activities caused by malware, packet sniffers or rootkits by monitoring incoming and outgoing communications traffic. HIDS will then check the integrity of critical system files and directories and watch for suspicious processes and executables. HIDS can also monitor the usage of system accounts with elevated or administrative privilege. Unexpected use of accounts with administrative privilege is often a sign of a larger compromise. Risk Impact:Without the means to detect suspicious events on a host system or critical files, unauthorized access by a user or malware can remain undetected. Risk Mitigation Strategy: Implement HIDS on critical systems, particularly those that involve the flow of payment card data, to monitor for suspicious or anomalous events.
- Improperly segmented network environment - Payment card account information can be compromised at financial institutions or merchant locations that lack proper network segmentation. For more information, please refer to the October 31, 2006, Visa Data Security Brief, Improperly Segmented Network Environment, available online.
- Poorly configured ingress and egress firewall rules - Firewall ingress (inbound) and egress (outbound) rules that are misconfigured or left unchanged from their default configurations represent an area of significant vulnerability. For more information on ingress and egress firewall rule misconfiguration, please refer to the Visa Business Review article (Issue No. 070911), Visa Identifies Top Network Vulnerabilities to Promote Data Security Awareness, available at https://www.us.visaonline.com.
- SQL injection - A review of recent data security breaches suggests Structured Query Language (SQL) injection attacks on e-commerce Web sites and Web-based applications that manage card accounts (e.g., PIN updates, monetary additions, account holder updates) have become more prevalent. SQL injection attacks are caused primarily by applications that lack input validation checks, un-patched Web servers and poorly configured Web and database servers. These attacks pose serious additional risks to cardholder data stored or transmitted within systems and networks connected to the affected environment.
