Integration and Testing

[brucerowe]

Due to the new PCI / DSS rules, we are removing the ability for our desktop app to use the Card Present / AIM method. We have converted our application to use the SIM interface.

SIM works well, but there is 1 problem. It does not support swiped transactions. If I tell our customers that they cannot use their card swipes, they will scream. They have good reasons:

1. Swiped transactions are faster and more accurate

2. A non-swiped (card not present) transaction is charged about ½ percent more for the merchant discount rate.

What we are looking for is a way to pass information back and forth - like in the SIM interface. The only difference is that with the swiped transaction, there would be a field on the Authorize.net for that could accept a card swipe.

It would work like this:

1. The initial form gets submitted with the fingerprint in a post (same as now). However, there would be another variable that indicated that a card swipe will be used.

2. Authorize.net will send the information back to display the payment gateway hosted payment form

3. The merchant would swipe the card and click submit.

4. Authorize.net returns the receipt (same as it does now).

The transactions would be faster, more accurate and PCI compliant. And, there is not much programming to be done.

This is a matter of some importance. We have several hundred merchants as customers. This issue is enough to force us to use another payment gateway.

Is there any way that we can stay with Authorize.net?

Thanks in advance.

Bruce

[TJPride Expert]

I'm not understanding your issue with using AIM? In a card-present situation, the card information is already right there (you're holding it in your hand), and regardless of implementation method, is always going to pass through your computer on its way to the merchant system. How is using SIM going to reduce your PCI exposure at all?

[brucerowe]

The real problem is the way that the PCI compliance rules are worded. The regulations say that "any application that processes, stores or transmits card numbers" is affected. Using SIM is the most practical way to not transmit the card number. My application never sees the card number. All it gets is what Authorize.net sends back.

But, I can't use a card swipe.

[TJPride Expert]

Hmm. How is the card data getting from your swiper to Authorize.net then?

[brucerowe]

I can't. The benefits of SIM are not available for swiped cards.

Swiped cards are only available for AIM. And, we cannot use AIM without certification which it too expensive.

[TJPride Expert]

What I'm getting at is that the credit card data can not magically beam itself straight from your swiper to Authorize.net. It's going to have to pass through your computer somehow, and given that fact, you are not going to gain anything by using an API other than AIM. The terminal computer, regardless of API, will still have the credit card info in RAM temporarily, and potentially in virtual memory, which means the cache on your hard disk. This will not change regardless of what merchant system you use, the only way to avoid it would be to have the customer pay from their own computer - obviously not an option - or to get a device issued by the merchant processor that connects directly to them and only sends a status code to your computer with pass/fail and amount charged. The latter is probably expensive as well and limits your options.

[brucerowe]

In other words, Authorize.net cannot do it. . .

[TJPride Expert]

In other words, nobody can do it without an "official" integrated swiper. It is technically impossible.