[NOT A BUG] Authorize CIM

[thenspdude]

The Authorize CIM module appears to be exactly the same as the primary authorize.net module.

 

When the customer goes to enter their credit card data, the form is still on our server, so what exactly is it supposed to do?

 

Essentially, this module isn't working the way that CIM is intended to. Is this how the module is supposed to behave, or is something seriously wrong here?

[thenspdude]

Very nice. I ask a question, and it's labeled not only as "not a bug," but my question is ignored. Is that how customer service works here? So I suppose, then, if it's "not a bug," then the CIM module is exactly like the main authorize.net module? If that's the case, then what's the point of the CIM module to begin with? There are still PCI concerns because the customer's card touches the server. Or does WHMCS not care, and is that why you flag legitimate concerns as "not a bug," and then ignore paying customers?

 

Is it possible to actually get answers instead of having something crapped on and ignored?

Edited August 23, 2010 by thenspdude

[Matt]

There's no need to be rude. If you want answers, then you need to ask a question not report something as a bug when it isn't. Please also read the bug report forum guidelines sticky.

 

If you actually read about the Auth.net CIM service from Authorize.net, you'll find it's a remote card storage solution. No it doesn't completely negate you from PCI requirements, and nobody ever said it does, it just means you aren't storing any customers CC info locally on your server so you have much less risk.

 

Matt

[thenspdude]

There's no need to be rude. If you want answers, then you need to ask a question not report something as a bug when it isn't. Please also read the bug report forum guidelines sticky.

 

If you actually read about the Auth.net CIM service from Authorize.net, you'll find it's a remote card storage solution. No it doesn't completely negate you from PCI requirements, and nobody ever said it does, it just means you aren't storing any customers CC info locally on your server so you have much less risk.

 

Matt

 

Believe it or not, Matt, the customer isn't always wrong. I DID read before I said anything. So now who's being rude? If you actually knew what you were talking about, you'd know that accepting the customer's credit card information on your server IS storing it on your server. So again, what's the point of the CIM module?

 

If you want me to not be rude, that's fine, but do the same, yeah?

[kcackler]

Not to fan the flames here, but the CIM module takes the card details, passes them to a secure storage area AT AUTHORIZE.NET and that is it. What that means is that you can repeatedly charge their card without storing their card on your server. With standard modules, like the authorize.net module, the card details are stored ON YOUR SERVER, and you charge their card based on the data stored ON YOUR SERVER. With the CIM module, you charge a card number that is stored in a secure area at authorize.net, thereby reducing your risk of accidentally exposing the number.

 

So, like Matt said, it does not completely solve your PCI compliance issues, but by you not storing the card details on your server, it greatly reduces your risk.

 

You need to relax and act a little bit more professional in this public forum. You're giving a very poor image for your business. Had you read the sales page for CIM at http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/ before blowing up, perhaps you wouldn't look so foolish.

[00Dante]

So you mean to tell me I can be paying an extra $20/mo for the CIM, and STILL have to worry about this PCI ****?

Hell I might as well drop the CIM all together, store the cards on my own server and focus on PCI alone.

[kcackler]

Or you could switch to Quantum Gateway and utilize their quantum vault service which is free and removes you completely from all PCI issues as the card details never touch your server.

 

That's what we did.