PCI DSS: Charging via Web Portal

CBAlexander used Ask the Experts™
I am attempting to prepare a solution for a level 3 merchant that needs to have the ability to capture payment card data remotely at workshops.  They are working on a web portal that will have a transaction service perform all of their payment processing.  Basically, I am thinking about setting up their firewall to use RSA SecurID tokens to provide a second authentication layer to create a secure VPN tunnel into their network, which will allow them to access their internal payment processing portal.  I just need to know if this will meet PCI DSS.


Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Since your client already accepts credit cards, do they have a vendor that scans their system every quarter or year?  Some merchant account providers actually charge the merchant a fee each month.  If so, you might see about contacting them.

PCI DSS Documents.  It sounds like you might be working on a wireless solution.  Besides reading PCI DSS v2.0, check out the Wireless Guideliness and Overview of the PCI DSS Wireless Guideline.

There are a number of things that should be done though.  You provided a few things, but left out some things.  For example, how are they obtaining this data at the remoate stations?  If they are keying in the entry, do you store the Primary Account Number (PAN)?  If so, do you do this because the customer might want a refund?  What numbers of the PAN do you show - the max you can show is the first 6 and the last 4 - all other numbers should be masked.  And you should not store the Card Verification Value - Card Verification Code - Card Identification Number.

Go through each of those requirements on PCI DSS 2 to make sure everything is covered.  Take a look at the documents in PCI DSS New Self-Assessment Questionnaire (SAQ) to see if everything on that list can be covered as well (the merchant should complete this as well).


Thanks for the info.

To clarify, the company tends to do a lot of business at trade shows, and they want to capture that data and charge on the spot while they've got the customer there.  The site they're entering the data into stores the PAN in an encrypted database, and none of the users has rights to read the full PAN (last 4 digts are displayed to provide additioanl means to confirm identity when the doctors call in to customer service).  The payment processing is done through an API on the site that polls the database and charges the customer for products.  The company deals with doctors and usually processes several hundred transactions per doctor per month, so as a matter of convenience they store the PAN and customer info to automate the purchase process as much as possible.

The HQ network stores all of the servers behind a firewall, and most of the internal network appears to be compliant, although I haven't had the chance to run a full-on audit yet.  The first question I have to answer for them concerns the ability to enter and process payments remotely.  My thought was to provide a laptop that they can take with them to trade shows, and also set up the RSA system with their firewall to provide 2 layer authentication (RSA to secure the VPN tunnel, and standard network login once the system has connected to the HQ network via VPN).  The payment processing system aslo has another authentication step that is seperate from the network login.  So at this point, my questions concern if this VPN tunnel approach would meet PCI compliance and if there are any concerns with authorizing charges to a remote system while traveling out of state.
Storing credit card numbers is risky, so they should have a company already scanning the system.

If they do a lot of business like this, storing credit card numbers and rebilling, you might consider the Quantum Gateway.  This gateway will store all the numbers for you at no charge, and the gateway itself is free.  And the users can get a USB Swipe if they are swiping the cards.  The gateway will then handle the transactions, and the administrator on the account can create users, applying what features they get.  The gateway can accept uploads of the credit card numbers already as well if needed.

Plus, if they have the ability to swipe the cards, the discount rate can be lowered by switching to a retail account.  

If they are already processing - you mentioned an API, which gives me the idea that you might have an electronic payment gateway.  I guess though, that gateway does not support storing the credit card numbers?  

The VPN though is supported by Requirement One (1.1.5a)


To correct, there are no card swipes conducted at all in this environment.  The card number and card holder information are entered into an intranet web portal, which houses an API provided by a third-party payment processor.  At the moment, payment information is written down by hand on worksheets at the workshop and transferred back to their HQ in their luggage.  This is not an acceptable solution.

Getting these workshop sales guys on a VPN connection to the HQ facility would essentially extend the HQ environment to where they are with their laptop.  From there, they would be required to log in to the Windows system, which will check their credentials against what is current in AD.  Once they have been authenticated, they would then have to log in to the intranet web portal (which is currently synching with AD to get ID and password info) in order to enter and process any payments.  Hopefully this arrangement makes sense.

As long as this VPN/Windows session/Intranet session authentication method satisfies PCI DSS for remote processing of payment card data, then I think that should answer my question, I just wanted to make sure there weren't any hidden interpretations or auditor experience that would say otherwise.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial