Payment Security: The Developer’s Duty

This content is sponsored by Vantiv.

Liz Crider, Vantiv

Merchants want ease of use. Customers want mobile. Everyone wants security.

It’s clear that hackers are taking advantage of unsecured mobile apps and public Wi-Fi networks—both of which are experiencing explosive growth right now—to break into not just the valuable data on retail mobile devices, but within the broader retail network. In a collective haste to rush mobile applications into the hands of consumers, the door is left wide open to cybercriminals.

Payment-enabled mobile applications are running rampant in retail, and their security is of profound importance to developers and ISVs

As merchants and consumers alike become more aware of the growing risks associated with mobile applications—specifically those that are payment and customer data-enabled—developers and ISVs are being pressured to ensure that security is “baked into” their applications.

For a payment application to be deemed PA-DSS (Payment Application Data Security Standards) compliant, the PCI SSC (Payment Card Industry Security Standards Council) mandates developers to ensure that their applications contain 12 protections, including:

  • Protect stored cardholder data
  • Provide secure authentication features
  • Protect wireless transmissions
  • Cardholder data must never be stored on a server connected to the internet
  • Encrypt sensitive traffic over public networks

The majority of PCI SSC requirements can be met quite simply by enlisting the five “fingers” of payment security:

  1. EMV to authenticate the card is not counterfeit
  2. END-TO-END ENCRYPTION (E2EE) to protect the transmission of data
  3. TOKENIZATION to protect stored data
  4. PCI to protect consumer data
  5. ANTI-FRAUD SERVICES to proactively address payment anomalies

Of course, these five elements aren’t all the sole responsibility of the developer. A secure payments environment is the product of a collaborative effort among developers, software vendors, dealers/integrators, acquirers, and merchants. For their part, developers can ensure EMV readiness, E2EE, and tokenization are “baked into” their applications by working with a merchant acquirer that offers integrated payment solutions.

Developers who employ standard security protocols will dierentiate their oerings and end up the winners in the long run.

Retailers and consumers alike are increasingly demanding highly-secure applications, which make security a cornerstone of the developer’s value proposition.

To get there, many ISVs and developers are finding it attractive to work with a merchant acquirer that can save them from the overhead and expertise associated with aggregating secure technology protocols on their own, and that embrace support of mobile payment applications on the back end. Those developers are realizing the value of partnering with an acquirer that offers an appropriate level of security for the application’s use case based on the five fingers of security, one set of services through unobtrusive integration, and managed security support and services throughout the application’s lifecycle.

For more information, read the full Vantiv paper here.