CIM integration and PCI compliance.

[trisynergy]

Hi folks, I have a 2-part question.  I've spent a fair amount of time reading through the various API's and playing with the sample code and the administration functions.  I believe right now that everything I need is available in the CIM API. 

My company's website has monthly recurring fees for accounts AND one-time transactions.  There's an initial setup fee (it's own one-time transaciton), and then you can upgrade your account later down the line resulting in another one-time transaction (upgrade fee) and most likely an increase in the recurring amount.  At any point, the user can log into the website and upgrade their payment device information.  It's ok if we have to completely wipe out their credit card and create a new customer record with authorize.net, but we'd prefer to pre-populate some fields (such as the users' address) on the billing form.

We would very much prefer not to use any i-frame or "hosted" or "redirect" solutions.  We want to have control over the entire look and feel of the site, and we're definitely running SSL.   We know we may incur some extra hoops for PCI compliance, but we're not sure what they are exactly.   We're not going to store anything really at all (save for the authorize.net customerProfileId and customerPaymentProfileId) on our systems.   If there are special PCI requirements, what are they?

If it's possible to use the CIM API to do recurring billing and one-off transactions, then why does the CIM API push the "hosted API'  iframe/lightbox solution at the top of the PDF documentation?  I just want to invoke all the proper API's myself.  They are specifically:

-createCustomerProfileRequest

-createCustomerProfileTransactionRequest (for one-off transactions AND monthly recurring transactions)

Given the requirements above, is it reasonable to assume we can use only the CIM API for our project?

Here's another question.  Up until now, I've been using the PHP/XML API that John Conde has graciously created at http://www.johnconde.net.   The sandbox account works fine.  I've been able to execute a bunch of API calls using my API Login ID and Transaction Key.  I can see my customer accounts and everything on the sandbox website (CIM manager).

However, my company just got a merchant account linked to an authorize.net account that is in "test mode".   Using this account against the production server, I attempted to execute "createCustomerProfileRequest" and got error code E00009, which the API very clearly states is because "The requested API method cannot be executed while the payment gateway account is in Test Mode."  At risk of sounding negative (I don't mean to), I'm very curious what the point is of production accounts in "test mode" if you cannot execute all of the API's?  Does anyone actually use their production accounts in test mode?

As a bonus question, is there any API where its possible to get transaction history given a customerProfileId or customerPaymentProfileId?  If not, is it OK to log non-sensitive information such as the transaction amount and date and line item information on our servers so we can quickly pull it up for our users?

[trisynergy]

I just wanted to answer my own quesiton here, in hopes it helps other developers.  I just had a conference call with someone at authorize.net who cleared everything up for me. 

For our scenario below, the CIM API will do everything required.  It's the preferred method.  The reason that the CIM API PDF document is "pushing" the hosted solution, is because it has less restrictions regarding compliance. And that's what most people are looking for (not us).

Regarding production accounts in "test mode", this is mostly a legacy thing and all your actual testing should be done on the sandbox servers (not with your real merchant account).  The "Test mode" doesn't really allow you to test any of the API's that store anything (such as basically all of the CIM API methods).

There is a transaction history API available, that you can call using transaction ID's handed back by the CIM API.  But it's not *inside* the CIM API itself.

[sikemullivan]

Thank you for answering yourself : P You had the same questions I did.

What compliance did you have to meet for just gathering the CC and passing it to the API? I'm curious, because I wouldn't think that you'd have to be completely PCI compliant since your not storing it anywhere.

How has the rest of the solution worked out for you?

[noalias77]

Hello,

Any pointers to the scope of PCI compliance for CIM? 

[TJPride]

If you are using regular CIM and not hosted CIM, you are transmitting credit card data. This opens you up to vulnerability right before the transmission, since any hacker with half a brain can just insert a bit of PHP to send themselves the credit card info, or store it to a file for later retrieval. This in turn means that your server must be secure, which means following strict procedures for keeping track of who has access, never having the login stored or transmitted on computers or devices that could potentially be compromised (basically, any PC...), having nothing installed on the server that could be vulnerable to external hacking (that means using the server only for processing payments, nothing else) or sideways hacking (no shared hosting), etc. Basically, it's quite difficult to pass the security requirements if you are transmitting credit card info, at least not without paying several hundred dollars minimum per month for your own PCI-compliant server. Given, it's SAQ-C, not SAQ-D, so I suppose it's theoretically possible.

If you use hosted CIM, you only have to pass SAQ-A, since all cardholder functions are effectively outsourced to Authorize.net.