Client reports 30% decrease in sales since implementing Authorize.net

[deepsand]

I've set up numerous clients that have been using authorize.net. A.net has crazy fees.

What do you mean by "crazy fees?"

An A.net virtual terminal is $20/mo., plus $0.15/transaction & settled batch.

[deepsand]

Over three months now they have records that, while their site visits have increased, actual sales have decreased by 30% ...

Have you examined these data yourself?

Is the data set a sample large enough to be statistically significant?

While traffic may have increased, did shopping increase?

Was the decrease in sales a dollar measure or a conversion rate measure?

Were the data for the three months in question compared to same calendar periods of past years? If not, what seasonal factors might be in play?

Did the product line and prices remain the same throughout the said three months as they were previous to such?

Is there any increased competition, be it new competitors or existing competitors changing their product lines and/or prices?

Have you considered doing a test by reverting to the previous system to see if sales revert to their previous level(s)?

[deepsand]

I can tell you what's wrong with the decrease in sales. I been there and done that! When ever I see the letters AOL or any other letters or words that give me a bad taste in my mouth I stay away from that company no matter if I have bought something from them in the past or not. People that shop online are smart and we will never forget who gives us good service or does us wrong. I have been buying from tigerdirect.com for years because of the good deals but, after one deal gone sour on me about a $54.00 return that the order was wrong and when I called them the support employee spoke to me in a bad way, I stopped buying from them and I will never buy from them again. And I have spent thousands with them too. I bought 3 computers and much more with tigerdirect.com but never again. They would have been better off biting the bullet on that one, because it will cost tigerdirect thousands in future sales. So, there you have it in a nut shell. I do not care if AOL sent me a brand new car I would never do any business with them again and so there goes the neighborhood.

What have AOL and Tiger.com to do with the OP's case?

Did you leave something out?

[deepsand]

Authorize.net is going to raise the bar on card verification which means that you'll have more automated card rejections.

Given that A.net does, at least for virtual terminal use, put the merchant in control of what verifications need to stand and pass muster - a valid card account no. and expiry date are sufficient if the merchant so chooses - I'm lost as to your meaning here.

[Shift4SMS]

WOW! Of course there's a osCommerce plugin for Auth.net. OsCommerce isnt on "the list" because it isnt a gateway.

You didn't get my point. The list the link points to is the PCI certified application list, not the certified gateway list. All canned applications that handle credit card data must be PCI certified. Also I know it has a plug-in, but what I saw used a traditional payment interface where CC information was posted to the merchant server then forwarded to the gateway for approval. This type of interface does not quailify for a PCI SAQ-A that requires the use of hosted payment pages by a PCI certified gateway or processor.

PCI DSS is concerned with the storage of and access to persistent data, not that which is transient.

Very incorrect. Per various PCI FAQ's and documents: "It is required that any cardholder data that any entity stores, processes, or transmits must be protected in accordance with PCI DSS." Storage is only one of the three factors.

My statements are based on very recent personal experience, as noted above.

Was a QSA involved? Unless the CC information was encrypted in the email (and various related key management requirements were met), it is not a PCI compliant system. I hope the merchant got written documentation from First Data that this was all up to PCI snuff. If so, if and when a breach occurs, First Data better have a "make this go away" fund for this type of shady work.

[deepsand]

Very incorrect. Per various PCI FAQ's and documents: "It is required that any cardholder data that any entity stores, processes, or transmits must be protected in accordance with PCI DSS." Storage is only one of the three factors.

What constitutes "accordance" is dependent on the merchant classification and acquirer specified requirements.

Was a QSA involved?

As stated, Security Metrics. The merchant in question is Level 4, for which compliance validation requirements are set by the acquirer.

Unless the CC information was encrypted in the email (and various related key management requirements were met), it is not a PCI compliant system.

In the particular case cited, such e-mails are initiated by and sent directly from the customer, and are therefore not within the purview of PCI with respect to the transmission, but only as regards the merchants storage.

I hope the merchant got written documentation from First Data that this was all up to PCI snuff. If so, if and when a breach occurs, First Data better have a "make this go away" fund for this type of shady work.

The auditing and certification are done by Security Metrics, not First Data, with First Data, being the acquirer, setting the requirements for Level 4 merchants.

[Shift4SMS]

In the particular case cited, such e-mails are initiated by and sent directly from the customer, and are therefore not within the purview of PCI with respect to the transmission, but only as regards the merchants storage.

Customer initiated emails is a different topic. The topic here was a merchant website that received CC data from the customer and forwarded this info to the merchant via email. For customer initiated emails many factors come into question: how often, is the merchant providing a form, is the merchant instructing customers to email CC data to them, etc. I think it was Security Metrics that told us we had to implement filters on the inbound emails to strip out CC data -- basically a CC firewall for emails -- so I'm confused that they would be telling anyone else differently (unless it does not receive enough to worry about it).

[deepsand]

Aside from the fact that requirements differ according to the merchant's classification level, and that it is the acquirer who sets them for Level 4, the PCI guidelines themselves are open to multiple reasonable interpretations.

[CraigAllen]

Have you examined these data yourself?

No, only going on what the client says. Am implementing some of the suggestions that youse guys have made. Since they didn't have google analytics on this site, that's my first step. Hard to diagnose something without having something to go by.

[deepsand]

Even in the absence of web based analytics, you still have a wealth of information from the server logs available for analysis.

Would not be surprised to learn that the client's perceptions are less than accurate.