GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?

Table of Contents

Lead Story

Reload with prepaid


Industry Update

Cynergy acquired by ComVest

A certified alternative

Dueling Strategies: VeriFone-Chase, Heartland-Hypercom

Optimism prevails at WSAA


Special report on the ETA's 2009 Strategic Leadership Forum

Brandes Elitch
CrossCheck Inc.

Wal-Mart and the unbanked

Patti Murphy
The Takoma Group

Glossary of common payments industry terms

Research Rundown

Selling Prepaid

Prepaid in brief

Prepaid players expand to meet demand

From coins to customers

In-house, SaaS or PaaS that solution?


Sell, rent, lease or give it away - what to do?

Biff Matthews
CardWare International

Use security to retain merchants

Scott Henry


Street SmartsSM:
Why do we think we're different?

Jon Perry and Vanessa Lang

Start with ripples, not waves

Jeff Fortney
Clearent LLC

Legal aspects of high-risk processing

Adam Atlas
Attorney at Law

Digging into PCI - Part 4:
Encrypt transmission of cardholder data across open, public networks

Tim Cranny
Panoptic Security Inc.

Company Profile

Merchant e-Solutions Inc.

New Products

Consolidated purchasing for truckers

Smart Solutions
Comdata Corp.

A gateway into e-commerce

Brick and Click
First Data Corp., Yahoo! Inc.


Twenty tips for lifelong learning



Resource Guide


A Bigger Thing

The Green Sheet Online Edition

November 09, 2009  •  Issue 09:11:01

previous next

Use security to retain merchants

By Scott Henry

Significant attention in the industry is focused on how to protect cardholder data. But when it comes to protecting the acquirer? Not so much. At VeriFone, we applaud and are heavily engaged in the effort to shore up defenses against efforts to intercept cardholder data.

Yet we recognize there are other security aspects that can hit you in the pocketbook: unauthorized access to the terminals you have deployed, either to embed rogue applications or to poach your acquirer and merchant relationships.

As the payments industry continues to embrace a multi-application environment - with payment, payment-related and nonpayment applications increasingly likely to run on a single terminal - it is critical to ensure that each application is authorized to run on those terminals.

Responsibility and liability

Many are tempted to throw up their hands at the prospect of investing in security, assuming there will be little, if any, return on investment. But we think the same technologies that help you secure your terminal are just as adept at helping you retain your merchant accounts and solidify relationships between you and your customers.

Nobody can or should attempt to prevent a merchant from switching to another service provider if that's what the merchant really wants. Yet you should be able to ensure that no one can surreptitiously convert a terminal you have installed or, worse, install a rogue application that can capture cardholder data or perform other illicit functions.

In the era of the Payment Card Industry (PCI) Data Security Standard (DSS), nobody involved in the payments value chain can afford to be asleep at the wheel when it comes to securing POS terminals.

To some extent, everybody involved in that chain shares responsibility for PCI compliance. And that means everybody shares liability in the event of a breach of cardholder data security.

Many grey areas surface when it comes to determining who ultimately is at fault for noncompliance. But lawyers will always trace liability to whoever has the capacity to pay up.

The PCI mandates that applications that prompt for entry of non-PIN data (virtually all existing applications) must be properly authenticated to ensure their proper use. This means a mechanism must be in place that:

Fortunately, the same security that protects your terminals from being infected with malware can also be used to prevent unauthorized reconfiguration of devices to other service providers. Software has been designed with a set of highly sophisticated file authentication capabilities to provide increased control over access to system software, applications and data.

How it works

With file authentication enabled, your competitors can't just walk in and quickly switch the terminal to their services. If a merchant wants to change processors, the merchant must contact you for approval before downloading new application software.

Once you've verified that the merchant wants to make a change, you can remotely (and securely) supply the reset mechanism to allow the new payment processor's software to be downloaded.

For this level of security, each terminal requires a digital certificate using the public key infrastructure. (A certificate is a digital file that specifies that a particular public key belongs to a given entity or individual.) For a file to be authenticated on a properly protected device, the file must be digitally "signed" by an authorized party.

For example, a merchant uses a protected device supplied by Bank A. Bank B offers the merchant substantial incentives to change payment processors. The merchant cannot execute the new application(s) until a replacement certificate is provided. Merchant calls Bank A to find out how to do this. Bank A can then try to retain the merchant before agreeing to the request for a replacement certificate.

The payoff

With this type of file authentication protection, you ensure unsurpassed security and protection against unauthorized access to payment devices, while also securely accommodating trusted third parties.

At the same time, payment devices - and merchant relationships - are no longer easy targets for competitors. Nobody can assume control of your devices by placing their own applications on them without permission.

Scott Henry is Director, North America Product Marketing, for VeriFone. He can be contacted at

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

previous next

Spotlight Innovators:

North American Bancard | USAePay | Board Studios