Hosted CIM Question

[blade]

I'm really new to all the payment gateway stuff (but at least I'm a potential new customer!), so please forgive me if my question seems obvious. 

I just discovered the Hosted CIM option, which seems exactly like what I need.  I don't want to have to deal with any of the PCI compliance or SSL, etc..  I'd rather pay Authorize.net to deal with that for me.  But here is my question.  In reading the CIM XML Guide, I found one of the minimum requirements to state:

• The merchant’s website must use https.

But then other parts of the document say things like:  For more secure exchange of information, the API allows you to establish a hosted connection,
where any exchange of information occurs on the Authorize.Net secure servers.  This statement seems a little contradictory to the minimum requirement listed above.

So in summary, my question boils down to this:  Do I need an SSL certificate if I'm using hosted CIM?

Thanks in advance for any help!

[Trevor · Accepted solution]

The hosted CIM functionality is designed to be used primarily within an iFrame on your own site. In this configuration, the url shown in the customer's web browser will be your own.  If you do not have an SSL certificate on your site, the site will appear to be insecure to the end user.  From a technical stand point, the card data being entered would be scured because Authorize.Net's hosted form is secure.  However, consumer recommendations from almost every consumer financial institution (including Visa, Mastercard, and essentially every bank) all explicitly advise customers not to enter their payment details if they do not see https and the lock symbol at the top of their browser.  The recommendation of using SSL is considered a best practice so that customers feel secure on your site. This issue can be avoided by implementing the hosted CIM features as stand alone pop-up windows instead of iFrames within your site.

[blade]

Thank you very much for that explanation!  That makes a lot of sense, and the documentation didn't quite state that as succinctly as you did, so I appreciate your response.

[Sandeep]

First of all sorry, if this is the wrong place to post my question (as thread is already marked as SOLVED) but I found the discussion in the thread quite relative to my question.

So, my question is-

Do I need to be a PCI compliance(d) or SSL enabled while using the "Customer Profile ID" and "Payment Profile ID" for doing the transaction?

I will be using the "Hosted CIM" approach for add/edit of the Customer Profiles.

Thanks in Advance

Sandeep

[TJPride]

Depends on what you mean by "PCI compliant". No matter what solution you use, you need to follow the basic password security rules, as in make sure that you know exactly who has access to the hosting account and that they don't leave the login lying around or expose their work computer to trojans or so on. If a hacker gains access to your hosting, you're doomed if they know what they're doing, even if you're using hosted CIM, since it's child's play to redirect your customers to a different form on the hacker's server and then farm their credit card details that way.

Outside of that, you're fine. You can store the profile ID and payment profile ID and won't be breaking any rules. The really serious PCI stuff only has to do with credit card security, and none of that information ever passes through your server.

[Sandeep]

Thanks for your reply TJPride.

Yes, we do have the authentications so that only the authorized users can access the database or the scripts/pages through FTP.

What my concern is, we have the cron job set that runs daily to auto-renew the users account (if it is expiring today).

And if it is expiring then we retrieve the "Customer Profile ID" and the "Payment Profile ID" from the database (yes, we store this IDs on our server) of that user and do the transaction using "createCustomerProfileTransactionRequest" API call.

So is this valid? or Do we have to follow PCI rules for this kind of transactions too?

Regards,

Sandeep

[TJPride]

PCI covers credit card data, SSN's, that sort of thing. Customer Profile ID or Payment Profile ID are not protected values and don't give you access to protected values (the most you can get is the last 4 digits of the credit card), therefore they're not covered by PCI. As I said before, you only need to worry about securing your hosting.

[Sandeep]

Okay, that means I dont need to worry about the PCI rules at all if I use the "Hosted CIM" API.

I was just concerned for the page that uses the "createCustomerProfileTransactionRequest" API function that do the transaction against the passed "Customer Profile ID" and "Payment Profile ID".

But now as you said they ("Customer Profile ID" and "Payment Profile ID") are not the protected value and are not covered by the PCI, I just need to worry about securing my server and not the PCI stuff.

Please correct me if I misunderstood you.

And thanks for the explanation.

Regards,

Sandeep

[TJPride]

Even if you use hosted CIM, you should look over and implement the PCI rules having to do with password security (in this case, for your Authorize.net account and hosting). They probably still apply.

[Sandeep]

Okay, I will take care of that.

Thanks for all the help