× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Exactly, Chris. Being "out of scope" would require a provider who supplies
"REMOTE TOKENIZATION". They store the data, but provide a token that you
can use to flag it to settle, or re-use it for returning customers.

The PCI Security Standards Council considers three things:
-STORAGE
-PROCESSING
-TRANSMISSION
https://www.pcisecuritystandards.org/pci_security/glossary

Any one of these three qualify a system to be IN PCI scope. Being in scope
means conforming to the requirements in the SAQ D,
https://www.pcisecuritystandards.org/documents/AOC-SAQ_D_Merchant-v3_2_1.pdf

a ponderous best-practices questionnaire that can take weeks or months to
complete. Everyone KNOWS about storing. But often overlooked is the
PROCESSING, which means merely TOUCHING the full card data (card number,
expiry, security code). Just touching it puts that system AND ALL CONNECTED
SYSTEMS, in PCI scope.

So if your order entry operators use your bank's credit card app in a
browser to get approvals, the fact that the operator (phone orders) is
KEYING the cards into their workstation puts the ENTIRE computing
infrastructure "in scope". Everything on the LAN is now IN scope.

Just because the browser is at an HTTPS site means nothing. The providers
of the browser-based authorization "virtual terminals" typically neglect to
identify this. To escape being in scope, PCI requires:

PCI SAQ C-VT Requirement 3 of 8:
"Merchant accesses the PCI DSS-compliant virtual terminal solution via a
computer that is isolated in a single location and is not connected to other
locations or systems within the merchant environment;"
https://www.pcisecuritystandards.org/documents/AOC-SAQ_C_VT-v3_2_1.pdf

So to even use a browser-based card auth system requires it to be done on an
ISOLATED system not connected to your existing infrastructure. Hmmmm.

A proper card processing system will return a TOKEN for each card processed
that will be used for several things:
1 - to allow the ERP to request the authorization be SETTLED in the nightly
batch once the goods or services are delivered, this is generally called
"flagging to settle".
2 - allow the re-use of the card data for returning customers, credits, or
recurring billing, generally called "cards-on-file".

These token should be provided for ALL of the transactions you process by
the three common methods, whether e-commerce, mail order/phone order, or
retail EMV. Ideally, any customer who visits you any of the three ways
should be able to use a card originating in another method. These tokens
have no inherent meaning. You could store the last four of the card number,
the card brand (Visa/MC, etc.) and the visible expiration associated with
the Customer ID in your ERP. This supports "cards-on-file'. You can then
display the last four, expiration, and card brand for the operator or
customer to choose, and then use the TOKEN associated with that to perform a
"referential" transaction, REFERRING to the card on file!

The challenges of taking your entire existing computing infrastructure OUT
of PCI scope have been solved, if integrated card handling is critical to
your organization. In fact, a proper system would allow for an RPG API that
you can use to provide the order details (billing address, billing zip,
total amount, tax amount, invoice number, etc.) so that WHEN the card data
(card, expiry and security code) is collected on an Isolated device (payment
tablet for phone orders, EMV terminal for retail, or iFrame for e-commerce),
it can be MERGED with the order info to obtain the best-qualified
transaction that will avoid downgrades.

This is not wishful thinking, systems that accomplish all of these goals
exist. Reducing vulnerabilities and PCI reporting burden are critical to
many companies based on the IBM i operating system. This ain't rocket
surgery...


Ira Chandler, PCI QIR
CTO, Curbstone Corporation
Support: https://curb911.com
Urgent Support: 888-844-8533

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Hiebert, Chris
Sent: Thursday, August 01, 2019 1:02 PM
To: Midrange Systems Technical Discussion
Subject: RE: pci compliance and iseries

A better suggestion may be to make sure your iSeries is Out of PCI Scope.

Our iSeries is out of PCI scope, but we still are allowed to save masked
card numbers and Reference numbers.
The key, from what I've been told, is that the iSeries never gets full
payment card information and doesn't touch the payment network.

The processing of payment cards is done by other systems. Not the iSeries.

Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author
and do not necessarily represent those of the company.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.