E-checks and ACH debits are not direct alternative payment types to credit cards. This is primarily due to their respective validation and authorization capabilities.

With a credit card, a merchant can submit a request to the issuing financial institution and the approval or decline is returned in under 3 seconds. That ‘authorization amount’ is then guaranteed to the merchant for up to 30 days (depending on the institution and card type).

With an e-check or ach debit, there is ‘no real time validation’ capability. The closest thing to it is ‘networks’ owned by bank and company conglomerates that serve up a ’scoring’ system based on shared data. They use this information to make their best prediction regarding whether an account is open or closed. If there is insufficient information to provide a score, that response is provided as well. These networks typically cover a high percentage of financial institutions (~95%).

The most important thing to note however is that no e-check or ACH validation service verifies sufficient or insufficient funds. Even if it could, an authorization request can’t ‘hold’ or ‘guarantee’ the funds like a credit card transaction.

These limitations are why e-check and ACH payment methods have not been as widely adopted as credit cards. They are great payment types for ‘trusted’ payments such as recurring billing for gym membership and utilities, etc. but inadequate for ecommerce or other ‘arms length’ transactions.

Realizing these short comings, the industry has been trying to get their foot in the door by coming up with a better solution. One such approach allows consumers to choose to pay via their online banking. When that option is selected, the merchant redirects the consumer to their own financial institution’s website where they log in and complete the payment. Thumbs up for the innovation, but as a consumer, I love my credit card and the convenience and protection it provides.

It’s certainly a hot topic right now and will be interesting to watch how this plays out.

In a card-not-present environment, there are two levels of credit card validation. First, is the Luhn Algorithm which is also known as a ‘mod 10′ check. The Luhn algorithm will validate the number of characters for a particular card type. It doesn’t perform any other type of validation. I’d say almost all payment processing systems have this in place as a standard offering.

If merchants want to further validate the card they can do an authorization request to the issuing bank for 1) address verification (AVS) and 2) cvv2 - the three our four digit code on the card. When the auth is submitted the bank will respond with match or mismatch codes for street address, zip (5 and or 9 digits) and cvv2.

In most payment processing systems merchants can set up acceptance or denial rules so that if an authorization comes back as having an incorrect billing address, zip or cvv2 code, the transaction will be automatically accepted, denied or flagged.

For merchants that want to validate the card upon accepting a new customer but not charge them they can do a $1.00 authorization which will then usually fall off the card in a few days. Note however, that there is no standard in the amount of time a particular authorization stays on a debit or credit card. Issuing banks determine the exact duration but generally speaking, most stay valid for between 3 and 10 days but some up to 30 days. In a situation where a merchant accidentally authorizes a card 10 times for $1,000, tying up a customers entire credit limit, they can call the issuing bank and ask to void the transaction.

A few other related points:
1. AMEX recently stopped returning CID (their version of CVV2) responses leaving address verification as the only validation tool.
2. CVV2 does not affect credit card rates.
3. CVV2 data cannot be stored.

Most merchants gave up trying to read their monthly credit card processing statements a long time ago because of how unbelievable complex most providers choose to make them.

For those merchants that occasionally look at them, they may be surprised to see a new ‘PCI DSS Compliance’ fee in the amount of $4 to $20 per month. This fee is a bit perplexing to me because the merchant account provider, in all the cases I’m familiar with, is not actually providing any product or service to the merchant related to PCI DSS Compliance.

If a merchant get’s breached, the Card Associations fine the acquirer and then the acquirer passes the fine down to the merchant. So while the Card Associations have put the responsibility on the processors to make sure that their merchants are compliant, the merchant is ultimately responsible for becoming compliant and paying the fines if breached.

So why again are merchant account providers charging businesses this fee?

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 extreme example to demonstrate the risk of a TPPA account. Let’s say over a 30 day period an ecommerce merchant sells $1,000,000 dollars worth of vitamins that they have on net 30 terms from a wholesaler. The merchant could collect the $1,000,000 dollars, not pay the wholesaler, and then skip town with a suit case full of money. Each customer will soon be initiating a chargeback because the vitamins they paid for did not arrive.

When the chargebacks are initiated, the issuing bank will credit the cardholders account but because the merchant is nowhere to be found, and the business has no assets, the merchant account provider is left with $1,000,000 dollars in in liabilities.

This example of course suggests intentional fraud is at the core of the liability, but it also happens in other circumstances, e.g. an online booking site accepts payment for airfare and then the airline declares bankruptcy.

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 merchants 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.

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

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

Here is the entire press release:

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 CVV2 value 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 CVV2 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 CVV2 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.

Most merchants mistakenly believe that processing a cardholder’s three or four digit CVV2 value 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. CVV2 is most often confused with Address Verification Service (AVS) which can be used to qualify for lower credit card rates.

CVV2 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 information. So for example, if a merchant creates a rule to decline all transactions where the CVV2 value 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 code. For recurring billing, merchants can accept and validate the CVV2 value 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?

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.

A White Paper on our outsourced 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. Here’s a more detailed comparison of internal vs. outsourced compliance.