Skip to main content

Overcome Payment Card Security Challenges

Any business that accepts credit cards is under jurisdiction of the PCI Security Standards Council. Companies running IBM i can face additional challenges.

Card security illustration.

Any business that accepts credit cards is under jurisdiction of the PCI Security Standards Council (SSC). Companies running IBM i can face additional challenges because of the limited options native to that ecosystem.

The PCI SSC—built by Visa, MasterCard, Discover Financial Services, American Express and JCB International—provides best practices and security standards for all businesses touching credit card data. Their requirements are enforced through the agreements merchants sign with their werchant services bank, or “acquirer."

Businesses that accept physical cards are mandated to use the new Europay, MasterCard and Visa terminals. Some software products will drive those terminals directly from IBM i, but this article focuses on real-time card authorization for telephone orders, called card-not-present processing. ERP systems involving order entry typically present a payment screen into which a person can enter the card data, putting that merchant squarely in the scope of PCI SSC security mandates.

The Challenges

Two main challenges exist for businesses that take these transactions:

  1. Security. Credit card processing puts data at risk of being stolen. Merchants can lose the ability to accept credit cards, resulting in devastating reputational damage. Fines and card reissuance lawsuits from card-issuing banks can compound the damage. The PCI SSC says merchants are in scope of its security standards if they store, process or transmit credit card data, which includes merely keying card data into a workstation (bit.ly/29cgIbx).
  2. Operations. Previously, Visa’s lowest-volume merchants that processed fewer than 20,000 e-commerce transactions and 1 million credit card transactions a year were exempt from completing a security self-audit, which the PCI SSC delivers as self-assessment questionnaires (SAQs). Effective Jan. 31, 2017, all merchants must complete, verify and submit their appropriate SAQ. Figure 1 below (click to view larger) summarizes this update (vi.sa/2hbxj1v).
Figure1_Overcome.jpg

If a notice hasn’t arrived, note that some acquirers are slower in PCI enforcement than others, but the merchant requirement remains.

To complicate matters, the PCI SSC publishes seven SAQs (bit.ly/2gpvxuK). Most IBM i merchants complete the SAQ D questionnaire when card data is touched on workstations, computers or servers. With an approved “virtual terminal” (VT) solution, they complete the SAQ C-VT questionnaire.

The voluminous SAQ D covers every element of a merchant’s computing infrastructure over 500-plus questions and is an ongoing effort.

The Best Approach

To maintain seamless integration and stop existing infrastructure from touching card data, the PCI SAQ C-VT documents the use of an alternate device for keying card data. Reduce the exposure and integrate a VT solution. Preferably, select one with back-end integration to an ERP order entry.

The SAQ C-VT dictates how to remove the entire existing infrastructure from scope by using a separate, browser-based input device (bit.ly/2h7w8SU) that can maintain real-time, seamless authorizations.

A separate device, into which card data is keyed, can qualify for the simpler, but more secure, SAQ C-VT. One cost-efficient option is a tablet with a dedicated Wi-Fi router/firewall to use on a vendor’s payment portal. By adding it to the network, the card data doesn’t mingle with other business data.

This can't be done in a browser on the existing order entry workstation, as that would put that workstation squarely back into scope of the dreaded SAQ D.

Some payment vendor solutions send purchase details to that device in real time, programmatically, using data directly from an order entry. They provide a back-end connection to a portal that combines transaction data, such as amount, with the sensitive card data from the tablet. This can also support address verification using customer data from the order entry app. Rekeying and its attendant errors are eliminated.

Remote Tokenization

The VT handles new card data entry. Remote tokenization can help a merchant refer to previous charges and cards to update the settlement amount or reuse cards on file for returning customers, refunds, credits and recurring billing.

A payment portal returns a “token” to the order entry application. PCI requires a tokenizing vendor to be a Service Provider Level 1, the highest level of security validation.

Merchants delivering goods or services days after taking the order first perform a pre-authorization and programmatically obtain a token representing that transaction. Upon delivery, the transaction is flagged to be settled by referring to that token, possibly also adjusting the final charge. That pre-authorization will be included in the nightly settlement batch.

This token refers to a card on file for repeat customers, refunds, credits and recurring billing.

Reducing Risk

Adherence to PCI security requirements is mandatory and reduces businesses’ exposure to card data loss, and risk of reputational and financial damage.

Choosing an SAQ C-VT solution using isolated payment terminals can take an existing infrastructure completely out of scope. This eliminates the annual SAQ D and its draconian 500-plus questions and intense ongoing compliance efforts. Remote tokenization securely stores cards on file for returning customers, expediting the payment process.

IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →