cancel
Showing results for 
Search instead for 
Did you mean: 

Is CIM for me?

I am just getting started.  My goal is to make a Windows program that I run once a month.  This program will calculate the commissions owed to me by each customer (via my database) and then for each customer with an Authorize.net id, it will charge their stored card (can you charge over CIM or just authorise?).  Finally it will email out bills along with a payment transaction id if the payment was successful.  I only want to charge a bunch of different cards, variable amounts, once a month on the 1st.

 

I would also like to run this same Windows program when ever I get a new customer, to add their CC to Authorize.net and add the resulting Authorize.net customer id to my database so it will be automatically charged next 1st.

 

So, just to point me in the correct direction, can I do all this with CIM alone?  Is that the best choice, to ignore ARB?  What I would really love to see is some samples like this:

 

Sample XML to store credit card and retrieve ID.

POST to https://server

<xml to save a CC>

 

Expected response

<customerID or whatever is needed to charge that creditcard later>

 

Sample XML to charge multiple cards

POST to https://server

<list of customerID and AmountToCharge>

 

Expected response:

<list of customerID and either "charged" with a transactionID or "reason not charged">

 

 

Thanks for any help you can provide to help me get this done quick and easy.

slunilocim
Member
2 REPLIES 2

Yes, CIM does all that you mention in your post. It can charge cards as well as authorize them.

 

From your post, it sounds like you will have the card numbers locally, and then you will be personally uploading them to Authorize.net via CIM. Will you receive the card data via the telephone? Via a written form from the customer?

 

That will work fine. But remember that you should never store (on paper or elsewhere), the CVVC number from the back of the card. (You don't need it for charging.) It is only to be used one a per transaction basis by the cardholder (if needed).

 

Also, you should establish a business practice of deleting the orginal card data. You don't want it laying around. Eg if it comes in via paper then shred the paper. If it comes in via telephone then it'd probably be best to merely write the number on paper until it is entered into cim. 

 

If it is stored in the pc (until uploaded to cim), then be SURE it is really deleted from the PC after it's uploaded! And that it never appears in a log file, etc. 

 

Much much better than entering the data from the PC into CIM is to use the Hosted CIM option: that way, the form for entering the card number into CIM is hosted on the Auth.Net servers and the card data is never in the PC, not even momentarily.

 

To be safe and secure, you NEVER want the card data in your PC, not even momentarily. Hosted CIM enables that.

larrykluger
Contributor

For security purposes, your computer should be considered tainted if any credit card data passes through it. Using the hosted form does not necessarily protect you - your computer will have the data in RAM as it passes from your keyboard to memory and from memory over the Internet to Authorize.net. RAM may be swapped out to virtual memory, which is a section of your hard drive. If you want an easier SAQ level, the computer or device that connects to Authorize.net should be used solely for that purpose, which means it can't be on a shared hosting or even virtual dedicated environment. A laptop used solely for processing credit card transactions would qualify, as would a dedicated server at a hoster with sufficient security (SAQ C). Short of that, it's either use the Authorize.net terminal (SAQ C-VT) or get stuck with SAQ D, which has rather a lot of questions.

 

Short version - not storing credit cards on your hard disk will certainly improve security, but there's no guarantee that it's impossible to retrieve credit card data from your computer if someone knows what they're doing. Keeping people out of your computer is therefore obviously important.