Archive for May, 2008

 
May
28
Posted (hbursi) in Design, General on May-28-2008

Payment Processing Application Performance

One of the frequent concerns about deploying any payment solution is “will it be able to process my transactions in a timely manner?” This is both an easy and hard question to answer. In some instances, a bad application design can lead to poor performance. In others, it is faulty system integration of one or more of the other components causing performance bottlenecks. Generally, there are several major components in the processing of a transaction that can significantly affect throughput and response time performance.

Read the rest of this entry »



 
May
21
Posted (db) in General on May-21-2008

Hugh has over 30 years experience in the payment industry including operations, development and marketing roles at leading providers such as Sterling Commerce, FFMC (now FDR) and S2 Systems (now ACI). He has managed operations as well as designed, developed, marketed and sold high volume payment software in the financial and retail industries.

Welcome Hugh and we look forward to your posts!



 
May
21
Posted (hbursi) in General on May-21-2008

The current public policy rage about payments is all about congressional motion toward issuing legislation to create a governmental entity to monitor and manage interchange fees. My first thought is yet another governmental watchdog is the absolute last thing we need. My second thought is, something needs to be done to move the majority of the costs of using credit cards to the banks that issue them and the cardholders that use them.  Oh, what a surprise that those who unilaterally decided the retailers would bear the cost burden are now portraying themselves as innocent victims!

The current system puts all the expense of using credit cards on the retailer with no say in what they are or how they are applied. They have a just cause in being up in arms about the situation. Who deemed them the fall guys in this situation? Whatever incremental sales benefit the retailer received in the early days of credit cards when Visa was BankAmericard was always suspect and have long since evaporated.

In the current system, there is no doubt that issuing  or using credit cards are not influenced in the least by  interchange fees.  Issuers change what they want and buyers shoulder none of the costs. There is no pain on the part of the issuer to NOT promote more and more rewards forms and there is no initial purchase cost to the cardholder to use their cards exclusively instead of cash or debit.

It is interesting to see the statements by the card associations where they say fees average 1.6%, when a quick read-through of the public information they provide on interchange fees reflect that is logically impossible. A fee of 1.6% is essentially the lowest fees shown on the rate charts and that rate is only for very basic cards presented for authorization using a very tight set of requirements. For everything else, the fees go up and up, to around 3%.

So, what is the solution? Actually, it is quite simple in concept, albeit a bit more complicated to implement. All that has to be done is change the credit payment system to remove the burden from the retailer and place it where it belongs, on the issuer and the cardholder. Just borrow from the debit model the processing fee pass through amount flows and apply a similar model to credit card transactions.

First, remove any and all restrictions in any agreements to allow the retailer, at its discretion, to pass on some or all the interchange fee to the cardholder or to charge a credit card fee if it wishes. Second, to facilitate this action, the authorizer could be required to supply the interchange fee in the authorization response.  Until that fee pass thru is available the retailer could approximate the fee based on transaction history.

Now, the retailer can decide to tack some or all the interchange costs to a credit transaction just as they do for ATM transactions. If you make a $100 purchase, you could get charged $102.43. If the consumer wants the convenience of credit, then they can pay for it. If not, they can use cash or debit. If the retailer wants a competitive edge; they can pay for some or all the interchange fee.  If the bank wants the consumer to use credit, they can reduce the interchange fee.

With this approach, the retailers no longer have a complaint about interchange fees because the may pass them through to the cardholder. And, the consumer can decide if they want to pay a convenience fee for their credit purchases or not.  The most likely outcome of this approach is consumers will demand lower interchange fees from their card issuer. And the issuers will have a choice of lowering fees or losing customers to debit. So the fight against interchange fees moves to the segment holding all the cards and all the clout.

Best of all, we keep the government, in its infinite wisdom, from destroying up yet another piece of the economy.



 
May
21
Posted (hbursi) in General on May-21-2008

The oft used distinction of banked versus unbanked is rapidly losing its meaning. Why? Because the  variety of payment  tools and options expand almost daily for the members of US society that do not have any direct relationship with a bank, thrift , or credit union.

The pace of change in how a large portion of the population pays for their consumption activities is accelerating rapidly. And the growth in how many of both banked and unbanked use the new payment methods is slowly but surely making banks irrelevant to the payment process.

Every day banks, thrifts and credit union eagerly act as the consolidation account point, card issuer and sponsor into the current payment system infrastructure.   Why? They love collecting those fees. Why not? They are charting their own demise.



 
May
21
Posted (db) in General on May-21-2008

eta



The Electronic Transaction Association (ETA) 2008 Annual Meeting Session Presentations from the 2008 Annual Meeting & Expo are now available for download here




The following presentations topics are available:

  • Selling the New Check — ACH vs. Check 21
  • Prospect, Call & Close! Proven Techniques for Sales Success
  • Healthcare RX — Making Sense of Health Savings Accounts, Flexible Spending Accounts and IIAS
  • When Interchange Really Isn’t Interchange: The Relevance of Interchange Optimization for Merchants
  • Mission Possible: Your Future As A Successful ISO
  • Optimizing Your Merchant Relationships and Portfolios
  • Mergers & Acquisitions — Growing Your Portfolio
  • PCI Security & You
  • Banking on the Unbanked
  • The Value-Add Edge — Increase Your Sales With Non-Traditional Offerings


 
May
15
Posted (db) in General on May-15-2008

visaVisa has provided its Operating Regulations here:

 

As Visa Inc. continues to serve the needs of our clients, we are committed to providing our partners with greater insight into Visa’s operations. We are pleased to provide access to the Visa International and Regional Operating Regulations as part of our effort.

While Visa’s Operating Regulations govern our client financial institutions’ use of the Visa payment system, we believe that providing access to them will benefit all of Visa’s stakeholders.

May not be a bad reference and provide some insight to Visa’a operations. There is a good “Glossary” and Merchant Category Code listing in the document as well, near the back.



 
May
14
Posted (db) in PCI on May-14-2008

pcilogoThe PCI Security Standards Council released a press release: PCI SECURITY STANDARDS COUNCIL TO RELEASE VERSION 1.2 OF THE PCI DATA SECURITY STANDARD IN OCTOBER 2008

 

Council to evolve PCI DSS with enhanced clarity on technical requirements, improved
flexibility and greater management of evolving risks and threats

Using feedback provided by this community, including more than 2,000 questions submitted to the Council since its formation in 2006, version 1.2 of PCI DSS:
• Incorporates existing and new best practices
• Provides further scoping and reporting clarification
• Eliminates overlapping sub-requirements and consolidates documentation
• Enhances the frequently asked questions and glossary to facilitate understanding of the
security process.

 

It will be interesting to see what the “new best practices” are and what new requirements will be based on “evolving risks and threats”

Stay tuned…



 
May
13
Posted (db) in Breach, General, PCI, Payment News, Point of Sale on May-13-2008

Dave & Busters (aka Chuck e Cheese for adults and with adult beverages) appears to be the latest in news stories of Data Breaches including magnetic stripe and track 2 data.
From Wired “International Hackers Indicted for Sniffing Credit Cards from Dave & Busters”

“The government said the Dave & Buster’s hackers illegally accessed 11 of the national chain’s servers and installed packet sniffers at each location. The sniffers vacuumed up “Track 2″ data from the credit card magstripes as it traveled from the restaurant’s servers to Dave & Buster’s headquarters in Dallas, according to the indictment.”

In my post titled, “Encrypted Traffic from within the PCI Zone” I discuss that we have adapted OLS.Switch’s point-of-sale (POS) TCP/IP interface to accept POS payment messages across the store’s PCI Zone (Protected network zone where CC Data would transverse) but include an encrypted account number field or data element instead of the clear text PAN (Primary Account Number), in the PAN field.  So this would act as a deterrent to network sniffing

That being said — it appears that there was a lack of montioring or mis-configuration or lax physical security around the POS, wiring closet, and network cable runs.

Again: I wouldn’t be surprised that if in future revisions of the PCI DSS - traffic from POS systems on private networks will be required to be transport encrypted in a tunnel or require encrypted fields/data elements.

BTW, Dave & Busters does have a pretty cool private stored value system and game card that you place in their games inorder to play and reload to play more.

EDIT:  CIO has an article here:   This is probably the best quote from the article.

Unfortunately for the criminals, Gonzalez’s code had some problems

In April 2007 it bombed its first test, on a point-of-sale server at the Dave & Buster’s in Arundel, Maryland. “The packet sniffer malfunctioned … and no credit or debit card account information was captured, ” Lynch said.

Even when the packet sniffer worked, the hackers were forced to keep returning to the Dave & Buster’s network and restarting their malicious software, Lynch said. A bug in the packet sniffer caused it to shut down whenever the computer it was monitoring rebooted.



 
May
06
Posted (db) in General, PA-DSS, PABP, PCI on May-6-2008

Jaime from The Merchant Account Blog writes:

Lately I’ve been hearing reports of processors that are starting to charge their customers $15 per month for not being PCI compliant. To fix this problem, these processors are requiring their customers to install some PC based scanning software that is supposed to magically make the business PCI compliant, thereby allowing them to avoid the monthly charge.

Let me start out by saying: This is a bunch of crap!

There is nothing that you can just put on your PC that will make your business PCI compliant. This is so far off course that it hardly can be related to PCI. PCI compliance is in reference to networks, computers, hardware and software that play a part in the processing, storage, or transfer of a credit card transaction.

Check out the rest of the post here: Forcing Software for PCI Compliance
Unbelievable. I don’t think I could of put it any better myself and really hits on the theme that a product (even if it is PABP or PA-DSS certified), or PCI Scan, or any other service, CANNOT make you PCI compliant — I have a blog post brewing on this very theme.



 
May
05
Posted (admin) in General, PA-DSS, PABP, PCI, Store and Forward on May-5-2008

If you read the PCI standards carefully and hang out with PCI geeks here or here you will notice that PCI applies to post-auth data and not necessarily pre-authorization data. — I think the official language is “subsequent to the authorization”

On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35.

Also, from a forum post from “andrewj

Another update on this (if you are from Australia) - there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04×0 messages. This should be released sometime this month.

This is a good trend in the industry, hopefully others will take this example and continue to trend.