Quantcast
Channel: West Wind Message Board Messages
Viewing all articles
Browse latest Browse all 10393

Re: Authorize.net and cardswipes

$
0
0
Re: Authorize.net and cardswipes
FoxPro Programming
Re: Authorize.net and cardswipes
02/17/2012
06:56:06 PM
3FO14L21P Show this entire thread in new window
Gratar Image based on email address
From:
To:
Attachments:
None

Right. I think Bruce's point wasn't about not being compliant but being able to offer solutions so that you don't have to be compliant because you don't apply for PCI requirements (ie. you never handle the card data at all like some of the Web Solutions a la PayPal and Auth.NET SIM do).

The issue is really about who needs to be compliant, which at this point is just about everybody. It doesn't matter whether the system is electronic or old fashioned scanning/swiping because you still have access to the card. The official rules are that if the card or card data is accessed PCI compliance is required.

The rules are getting stricter and it's mainly to protect the CC company's butt not for any consumer or customer benefits. I know of lots of businesses that pass PCI with flying colors but have bad backend systems that are totally compromisable. No amount of testing is going to find those weaknesses unless the customers themselves acknowledge and address those holes.

Reality is that most PCI compliance tests are a big waste of money and while I definitely think that data security is an extremely important issue to deal with, PCI is just a bunch of hand waving that gives the impression that things are secure. Worse it's a bunch of misplaced money that that drives a lot of small companies to not have credit cards which is bad for business.

The way I read this is that *if* something should happen to your card data regardless whether it's at your end or anything else in your merchant chain (gateway, merchant bank, Visa etc.), you're 100% liable if you're found to be not compliant (again I think a thourough review beyond self-assesment is likely to find holes in just about any company). IOW, the banks are trying to set themselves up so that if anything goes wrong anywhere including on their end it's your fault. Ontop of it the CC company has the right to sue you for breach of contract while you have no rights to do the same if they compromise your data.

It's a whole rigged system that's designed to - once again - work in favor of banks who are already raking in ever increasing fees from merchants.

+++ Rick ---


Going to be hard to find too many places in compliance.

My clients tell me -- and they are probably wrong -- that if the customer never hands them the card and swipes it himself it is different. That does not really make much sense, as what happens if the customer hands the card to a clerk because their hands are full ?


If you hold the physical card you're required to be PCI compliant. It's not just the computer that's at issue. It's the physical access to the card even if you don't store it.

+++ Rick ---



If you do not want your software to "touch" the card when it is swiped, the swiping can go directly from the hardware to PC-Charge. You query the PC-Charge API for results etc, and can claim to never see the card info.

Authorize.net is easier to integrate agreed, but it is far removed from the desktop.


That doesn't really solve the PCI problem - you're still handling the card. Authorize.NET works fine for desktop validation and is a heck of a lot less of a hassle to integrate with then pc-Charge et al. from an application.


+++ Rick ---



I am not sure I understand the situation, but are you using authorize.net for desktop application transactions? if so, why not use something like P.C-Charge

Guys,

I have Been using Merchant Plus and Authorize.net for quite a while. The AIM interface has worked well. Now, I have run into a new situation. As we know, this year, the PCI regulations have expanded.

The challenge is the rule, "A payment application is anything that stores, processes, or *transmits* card data electronically." and "any piece of software that has been designed to touch credit card data is considered a payment application." Source: http://www.pcicomplianceguide.org/pcifaqs.php In other words, I need to process payments without touching the card numbers.

The internet side of my application is fine. We use SIM. The desktop application is giving trouble.

The Authorize.net SIM interface will do what I need. I can start a transaction by sending data in a post. The payment form appears in the browser control. I enter the card number on the Authorize.net website from within my app. The only data I save is what Authorize.net gives back to me. SIM works well. But, SIM does not support swiped data. Card swipes are necessary for efficient POS transactions.

Authorize.net has another interface: VPOS. VPOS does support card swipes. However, VPOS has limitations:

The operator needs to enter the invoice number
The operator needs to enter the amount
The operator needs to enter the customer's name
The operator needs to enter a note for what the customer is purchasing
VPOS does not return data to my application

Overcoming these limitations means manual entry. This slows the sales process to do the work accurately. In a POS environment, this is not possible.

Unless I can find a solution to this problem, my customers will be forced to use a non-compliant application. Or else, my customers will be forced to go to a different payment gateway.

Any ideas? Thanks in advance.





Rick Strahl
West Wind Technologies

Making waves on the Web

from Maui, Hawaii

Viewing all articles
Browse latest Browse all 10393

Trending Articles