Integration and Testing

[MartinMcCaulley]

Are there plans to provide the ability to encrypt cardholder data from a POS device through to CIM?

I have been investigating "hosted CIM" and I am liking what I see.  It introduces the least amount of changes to our web pages and server code, yet enables the cardholder data to be collected at the auth.net site.  This was going to enable us to move to a different PCI classification, until I started investigating auth.net's POS solution (VPOS).  The VPOS solution does not integrate with CIM (that I know of) and has very stringent requirements as to how it can be used (must use IE and log into a specific page, etc.).

Thinking about this, I can't help but think of much better solutions.  Like requesting a public key via some CIM API.  Utilizing the public key to initialize an encrypting card reader and then sending the encrypted cardholder data directly to auth.net.  This would make it so that nothing could decrypt the data except auth.net (which is the only entity that knows the private key).  Another option would be that auth.net works directly with card reader manufacturers and supports a driver that can talk directly to auth.net.

Watching the video for VPOS, I get the sense that this team "just doesn't get it".  They seem to be stuck in some coding era gone by and they just don't seem to have the same briliance, innovation and integration that other parts of the auth.net team exhibits (especially the CIM team, I really like that team).

So, the main question here is, "am I missing something" and is there a way of integrating VPOS with CIM?  Does the VPOS team have any plans to support other browsers (Chrome is our reference platform, ActiveX?...   ...why not build an extension or a plugin?)?  Is the "less then friendly" site that is exhibited in the VPOS video the only way of interfacing with the VPOS solution?  How do I know that a payment was successful in my application if the VPOS solution is in a whole different browser?  Is there an API for determining successful payments and matching them up with CIM customer profiles or safing a separate VPOS profile?

So I'm hoping there is a way to integrate VPOS with CIM.  Otherwise, I'm at a loss and will need to accept the added rigors of extended PCI requirements.  I was hopeful that auth.net could ease the burden, but I'm less confident now that I have seen the VPOS "solution".

Help please!

Thanks,
Martin

[RichardH Administrator]

Hello Martin,

You are correct that our existing VPOS solution does not support encrypted readers.  However, could you expand on your use case for using customer profiles?

Richard

[MartinMcCaulley]

Hi Richard,

Thanks for your reply (I'm new to this forum).

To expand, the app I write/support utilizes CIM for storing customer profiles and we utilize the stored profiles in order to bill our customers for subscriptions on a recurring basis and to charge customers during checkout from our shopping cart.  This is just one element of our business.

The other element to our business are big/major events where we have computers setup to take orders and either utilize our customer's payment profile or allow them to swipe their credit card on checkout.  So this element of the application is a point of sales (POS) system.  Lately, I put a good deal of effort into the POS portion of our application in order to make the process more seemless for our customers and the "cashiers".  We do not currently use encrypted readers, but I have worked with cryptography extensively, so I have a good idea as to how this type of thing should work (public key to encrypt and only the owner of the private key can decrypt).

I am using the CIM APIs in both cases and I really like the CIM APIs.

Now, I am in the middle of doing a PCI review and contemplating taking any sort of unencrypted data flow of cardholder data out of our application.  So for the non-POS portion of our application, "hosted CIM" is looking like an encredible solution (awesome!).

However, I had to consider POS as well, since it is a major part of the customer's business (big events).  So I took a look at auth.net's VPOS solution and was under-welmed (to say the least).

So I have to say (at this point) I am not very familiar with encrypted readers (yet), but here is how I would like the POS process to work.  I call a CIM API to retrieve a public key from auth.net.  I then install the public key on the encrypting card reader.  Subsequently, when a POS "customer" swipes their card the reader encrypts the cardholder data with auth.net's public key. I then call the CIM API in order to store the cardholder data with CIM or just to make a one time charge with the card.  Since auth.net is in possession of the private key, auth.net is the only one that can decrypt the cardholder data.  The data is encrypted as it passes through our application, which makes PCI compliance much simpler.

CIM supporting this scenario would simplify my life tremendously and I would totally be willing to work with the CIM dev team in order to see this accomplished.

Please help!

Thanks,
Martin

[MartinMcCaulley]

Okay, I think I was stuck on a scenario in my mind because a developer here in our office simply asked me the question, "why wouldn't auth.net's hosted CIM page work for keeping the data secure?".

I think this is a true statement.  So, if I create a hosted CIM page and the card reader scans the information into the hosted CIM page, then our server would never have unencrypted cardholder data pass through our server.  Instead, the data would pass directly through to auth.net's server and auth.net would tell my iFrame that everything was successful.

Does this sound correct to you?

If so, I think I'm ready to roll with hosted CIM pages in a BIG way!!!

Thanks,

Martin

[RichardH Administrator]

Hello @MartinMcCaulley 

At a high level, using the hosted payment form with CIM will help you meet your PCI requirements.  However, it's not possible to use an encrypted reader with the hosted payment form.

Encrypted readers are injected with a key specific to our payment gateway, but it also requires using the SDK from the reader manufacturer to communicate with the device.

At present, Authorize.Net supports several mobile encrypted readers.  You can see a list long with purchasing information here: http://www.authorize.net/mobile

We are also working with several reader manufacturers to add support for Authorize.Net with their devices.

Richard

[MartinMcCaulley]

Hi Richard,

So if we were to separate this out into two elements:

1. 1. not passing unencrypted data through our web server
2. 2. encrypted readers

It sounds like hosted CIM pages solves #1 but does not solve #2.  Which brings us much closer to PCI nirvana, but doesn't incorporate the added protection of encrypted readers.

That said, it still sounds like hosted CIM pages are worth persuing in order to stop flowing the unencrypted cardholder data through our web server.  Please confirm this assumption (just say yes, unless this statement is false).

Since our solution is hosted in a browser (Chrome), the mPOS solution looks like it may or may not work for our application.  Question:  would it be possible to communicate between our POS web application and the mPOS solution? Meaning, if a "cashier" is on our application in the browser and uses a scanner to add items to a cart, is it possible to communicate the total to auth.net and have the total transaction amount communicated back to the mPOS device? If not, I think it would be a very worthwhile feature to add to the mPOS device! It would enable a very seamless workflow while keeping the payment flow secure. (this would basically establish a link between the mPOS device and the cart system). In fact this would be a great solution.

Thank you for your responses, you have been most helpful!

Thanks,

Martin