As of October 1st 2009 Visa has started to charge a fee of $.045 per misused authorization.

Visa defines a misused authorization as:

Authorizations that are not followed by a matching clearing transaction (or in the case of a cancelled or timed out authorization, not properly reversed)

For MOTO and e-commerce merchants who use payment gateways there may be some changes to how they perform Auth and Capture type of transactions, especially if they Authorize the transaction at order time, and later Capture or Complete the transaction when they ship a product. Or more typically, perform a $1.00 authorization first with AVS and CVV2 data, and followed by an authorization for the total amount of purchase.

Many payment gateways may or may have authorization reversals, authorization voids, or other transaction types – you will need to work with your gateway to identify what transaction types need to be performed to “reverse” an authorization for a product that you do not ship. Or if your practice is to re-auth after 10 days, and let the original expire – you will be hit with the fee.

Visa also supports a new transaction type called Account Verification – which is a $0.00 authorization – which they hope merchants will used instead of misused authorizations.

For processors and large merchants with direct connections to Visanet or Payment Gateways – These entities will want to verify that their reversal processing addresses credit reversals in the time-out scenario.

But here’s the thing: once we send the transaction to you, now you’re the switch.  What I mean by that is:  your application is now beholden to the same throughput, speed, efficiency, extensibility and 24×7x365 availability concerns that define our lives.  And while there have been many that have been up to the task, there have been countless other instances where that’s not been the case.

There are are few basic models that we have seen that work well:

1. OLS Implemented Business Logic based on customer developed prototypes.
2. OLS Implemented Business Logic and Customer provided Database or Flat File update feeds that drive authorization decisions. 
3. OLS Transaction Participants that call Customer Provided Software and CustomerSecretSauceManger.process() methods within our processing framework.
4. Under our guidance, interface remotely to an local endpoint via TCP/IP Sockets or WebServices, handling concerns that we address here with tech savvy customers.

The changes are listed below:

Track 2 data is no longer required for completion, reversal or void transaction types. With the elimination of the Track 2 Data (Field ID 35) these transaction types will now require the Account Number (Field ID 02) and Expiration Date (Field ID 14) to be provided. All clients should make these modifications prior to your next PCI assessment.

This is great news, the is one of the last processing gateways that we interface with that required the ISO8583 Data Element 35 – Track 2 Data for reversals and completions.  If you ever noted the specific wording in the PCI DSS specification about “subsequent to the authorization” this is part of why I believe that wording was left there.  The issue with this is while SAF queues are normally located in memory – there are times when they can be configured to be persisted to disk (If they are not, think of the cardholder impact of duplicate charges) This is less data, specifically pre-authorization data that is required to be stored prior to the authorization. We have leveraged “encrypted spaces” to help protect all types of SAF Queues and are happy Track 2 Data is not required for match-ups any more – Ideally, and we hope that processors will take this a step further and remove the requirement of sending the PAN, and leverage other unique transaction identifiers or composite identifiers: Take a look at one our our “FindOriginal” Transaction Participants for a MasterCard Interface:

CriteriaImpl(TranLog:this[][date>=Thu Sep 17 09:11:41 CDT 2009, irc=1816, stan=000000087625, originalItc=100.00, acquirer=987654999, mid=123456789012345, tid=12234501, banknetReference=MQWWRJ4QW ])

No Card Number there !

Update July 17/2009 – The Guide is now listed on the PCI Co Website and direct link is here.

From the Article these appears to be the relevant things from the Guidelines:

• The guidelines requires “a firewall that demarcates the edge of the organization’s CDE – cardholder data environment
• To combat the problem of the rogue access point, businesses will need to use a wireless analyzer or preventative measures such as a wireless intrusion detection/prevention system (IDS/IDP) regularly
• The council is advising large organizations to set up automated scanning using a centrally managed wireless IDS/IPS system.
• The guidelines suggest quarterly scans each year to detect rogue wireless devices that could be connected to the CDE at any location and have an incident-response plan to deal with them.
• To isolate wireless networks that don’t transmit, store or process cardholder data, a firewall must be used, and it has to perform the functions of filtering packets based on the 802.11 protocol; performing stateful inspection of connections; and monitoring and logging traffic allowed and denied by the firewall according to PCI DSS rule 10. The firewall logs would have to be monitored daily and the firewall rules verified once every six months.
• The wireless guideline also says “relying on a virtual LAN (VLAN) based on segmentation is not sufficient.”
• For “in-scope wireless networks,” physical security should apply, with options that include mounting wireless access points high up on a ceiling and disabling the console interface and factory rest options by using a tamper-proof chassis.
• Change the default settings of the access points in terms of default administrative passwords, encryption settings, reset function. Disable SNMP access to remote access points if possible. Do not advertise organization names in the SSID broadcast.
• Use of AES encryption is recommended for WLAN networks. Specifically, information flowing through certain network segments, including secure wireless devices that connect to the private WLAN through the access points, must be encrypted.
• Wireless usage policies should be established for “explicit management approval to use wireless networks in the CDE.” Usage policies require labeling of wireless devices with owner, contact information and purpose.

A New Hampshire man says he swiped his debit card at a gas station to buy a pack of cigarettes and was charged over 23 quadrillion dollars.

Bank of America tells WMUR-TV only the card issuer, Visa, could answer questions. Visa, in turn, referred questions to the bank.

Our Issuing systems have parameters to Delcine transactions over a certain amount, most of our clients set those to less then 1 quadrillion dollars, I believe.   I wonder what the amount on his receipt says, I wonder if this was a POS glitch or a settlement glitch.

In a statement, Visa said the rogue charges affected “fewer than 13,000 prepaid transactions” and resulted from a “temporary programming error at Visa Debit Processing Services … [which] caused some transactions to be inaccurately posted to a small number of Visa prepaid accounts.”

via cnn

[Update]

For a couple of months spanning the first and second quarters of this year, Integrated Solutions For Retailers surveyed its subscribers — hundreds of retailers from many segments, ranging the gamut from small and regional chains to tier-one enterprises — on their perceptions of the PCI DSS (Payment Card Industry Data Security Standard). The survey results surprised us. Respondents exuded nearly equal parts confidence, confusion, dismay, and ignorance. Some gloated. Some swore.

Some very interesting comments here, some of my favorites:

• From a regional grocer: “We’ve devoted no effort. PCI certification is an impossible-to-hit, moving target.”
• Only 23.9% of retailers surveyed indicated that they’re “very familiar” with the PCI DSS.
• 59.6% say fear of a breach is their motivation for achieving compliance.

Read it here.

As a Payment Switch there are times ( especially in development / testing ) that you will want to log or see what the switch is sent from a terminal or POS system, or sent and recieved from an authorization end-point. This feature is very handy during integration to new end-points, different message formats, changes with additional data elements and initial testing and certification efforts in test environments. In Production this is very, very bad, because raw messages contain card-numbers, Track Data, CVV2 Data, PIN Blocks, and all of the other “Bad” stuff one is prohibited to store according to PCI. OLS.Switch by default has this feature turned off, and recommends its use as a last resort for troubleshooting production problems.

Let me rip the introduction paragraph and a few bullets from our PABP Implementation Guide:

Secure Troubleshooting Procedures

OLS.Switch is configured to use various techniques to either protect or wipe sensitive cardholder and authentication data to prevent storage of prohibited data, or to use encryption to render the card number unreadable.

There may be instances in which sensitive cardholder information or sensitive authentication data needs to be viewed for troubleshooting purposes. Sensitive authentication information must only by collected when needed to solve a specific problem. The following are secure troubleshooting procedures designed to allow limited controlled access for troubleshooting purposes, all steps must be followed. You must be authorized and approved to make these system configuration changes.  Furthermore, it is recommended that your internal company’s Change Management and Problem Management policies and procedures are followed in conjunction with these procedures.

x.     Determine if troubleshooting can be performed on test environment with test card numbers.  Perform troubleshooting in that environment first.

….

x.     Only collect the limited amount of information needed to solve the specific problem. Only collect enough data in the troubleshooting log that is required to address the specific problem  

…

(There are lots of other steps and controls to verify that any changes are set back to default, appropriate destruction of captured data is handled, etc, etc, etc.)

Logging raw messages is a dangerous feature and much care needs to be taken with it, and is rightfully heavily scrutinized with knowledgeable PCI Auditors, while not an issue in a test environment using test card numbers, a system misconfiguration or human mistake or “forgotten” changed setting in production could prove disastrous. OLS has added some “controls” around this feature.
Previously there were columns in our TranLog that were called REQUEST and RESPONSE, in order to enable this type of logging an entity such as a store or specific terminal (Terminal ID) would need to be configured and enabled to do so, and would need to follow all of our “user controls” and recommended procedures (including preventive and detective controls) in our PABP guide. For the record non of our clients on our production system have any data in the REQUEST and RESPONSE columns of the TranLog in production environments. I’m happy that it is not a widely used feature in production.

With the new release we now have a single related table called raw_request that has a relationship with a transaction in the TranLog – a much cleaner and normailzed approach. In addition to this, there is a system-wide parameter called auditTrace for each OLS.Switch module that must be enabled by setting the value to true, it is defaulted to false. These system wide parameters are based off of configuration files, and we recommend that our clients use File Integrity Monitoring to detect and alert on any changes to application configuration files.  Once the system-wide parameter for the modules are enabled, a specific store or terminal needs to be configured and enabled; It is a two step process. In addition, This approch also makes it easier to detect if the system is configured in a “non-compliant” fashion – we have monitoring tasks and alerts that scan the raw_message table, and alerts if the row count is non-zero. Also if there is any Database replication or archiving, moving this data to a separate table, ensures that troubleshooting data remains and isn’t disseminated.

This feature is a necessary evil that most of our customers ask for or have in other Payment Switches (we do have the ability to remove the raw_message table and functionality completely). We hope that further adding preventive controls (Making it harder to enable, user controls to use dual control and have secure troubleshooting policies and detailed secure troubleshooting procedures to follow), detective controls (user controls to detect application configuration changes and monitor row counts of the raw_message table) ensure that it is an intentional change on the customer’s part to enable this functionality.

Also: the following paragraph by Andy shows off our different biases:

One follow-up to this Release Note:  I asked Dave how we should set ‘auditTrace’ in production – my thought was to set it to ‘true,’ thinking we’d be at the ready to turn on tracing without a service re-cycle.  Dave strongly disagreed and stated: OLS.Switch ought to be “Secure by Default” in production.  I really liked that.

Dave = Security Focused.
Andy = Operations and Timely Troubleshooting.

Key points were:

1. Long Holiday Weekend IT engineers were off on holiday and took time to address the issue.
2. Fire Department wouldn’t allow access to the building or operation of backup generators
3. Article raises concerns on the backup data center:

Of more concern is the question of a back-up data center. Authorize.net states that they were approaching capacity of their current backup data center and they were in the midst of transitioning to a new one: a true “hot” site (in other words, real-time synchronization), so that the Authorize.Net platform could be switched from one data center to the other “on the fly.” When the fire took out the primary data center, they attempted to fail over to the new, still-in-testing backup data center and encountered “a number of unanticipated errors.” They offer no explanation as to why they tried to fail over to the new backup data center rather than the old (presumably well-tested) one.

4. Authorize.Net did not have “out-of-band” communication methods and eventually opened a twitter account to communicate with customers.

Download the list here: http://www.visa.com/isolisting

Visa is offering a series of one-day Visa Key Management Training sessions as well as a three-day Visa PIN Security Compliance Validation Training session that will provide up-to-date information on the secure management of cryptographic keys used in ATMs, point-of-sale (POS) PIN pads, encrypting PIN pads and hardware security modules. These sessions are for staff involved in the management or operation of devices that accept PINs, and for personnel who need practical knowledge about the elements of Data Encryption Standard (DES) cryptography and the management of secret encryption keys. In addition to the material covered in the one-day Visa Key Management Training session, the three-day Visa PIN Security Compliance Validation Training session offers an in-depth review of the Payment Card Industry (PCI) PIN Security Requirements, providing internal and external assessors with the tools necessary to complete a PCI PIN security compliance review.

Should be fun.