07-16-2011 07:52 AM
I was "introduced" to CIM on the webinar a few days back and now experimenting with it as a possible solution for our payment processing (www.reachpeople.com - we currently use Google Checkout).
I've wrote a q&d "get" app for the CIM customers I've created using the CIM sample app. The app uses getCustomerProfileIdsRequest & getCustomerProfileRequest, and both seem to work as documented.
Where I'm stuck is (I suppose) an issue of policy. I want to access CIM via what the docs (pg 6) call "Standard API" - I do not want to use the "Hosted Option API".
Issue: When I "get" the CIM profile of a customer using the "Standard API", the cc info is masked off. I don't understand how I am supposed to offer that info for user edit if I can't retrieve it. It appears that if I want to allow the user (my customer) the option of editing their payment info, I *have* to use the CIM "hosted" option? Is that correct?
07-16-2011 08:27 AM
The difference between the Hosted CIM and using the API is this:
Hosted CIM: Customer payment data is entered by the customer on the AuthNet site and you only need to store basic information about the payment method(s) the customer has set up on the CIM.
API CIM: Customer payment data is entered/modified on your site, a copy of all of their payment data is stored on your site, and then you update that data through the API (customer never actually 'lands' on the AuthNet site).
Either way, you will never get the full card number, expiration date, or bank account number (if you're using echeck) back from AuthNet, but if you are using the API version, you'll have that data on record because the customer enters it on your site to begin with.
With the API version, it's basically done this way:
1. Customer enters/modifies/deletes their full credit card data on your site
2. You store/update that data on your server when the change is made
3. You immediately pass those changes/additions over to AuthNet through the API so it can be modified within the CIM system at AuthNet and used for making future payments.
With the Hosted version,
1. Customer is sent to AuthNet to manage their payment information
2. When they return, you retrieve their current payment info data from AuthNet
3. You change your stored data for that customer to reflect any additions/modification/deletions they performed while they were on AuthNet to any fields that you choose to store.
Technically, all you really need to store using the Hosted CIM is:
A. customerProfileId (unique number assigned to the individual customer)
B. customerPaymentProfileId (unique number(s) assigned to the individual payment types that customer has set up)
C. last 4 digits of the account (or something for you to help the customer identify the payment method associated with the customerPaymentProfileId they'll be using when they actually make a payment)
In my own opinion, the Hosted version is the one to use if you are concerned about security, PCI complience, don't have an ssl cert on your site, or just don't want to store full credit card data in your own system.
With the API version, since you've got ALL of the customer payment information stored on your server, you can display whatever you want and set up any kind of management system you want. The 'down side' to this method is that you will have to store and pass the full credit card information through your site, which is where PCI and SSL and all that come into play.
From a technical standpoint, the Hosted version is actually more difficult to set up, because you have to parse through a lot of XML (if you use the XML system) to get to any changes made to the customer inforation stored on the CIM.
Using the API version, you already know what changes were made, because they were made on your site before you sent them to be updated on the CIM, so all you'll really care about is whether your update call to AuthNet was a success or not (messages->resultCode = 'Ok')
Hope that helped :)
07-16-2011 10:34 AM
I already have ssl, but I'd rather not store cc info on my servers - the business insurance (and risk) goes way up when you do that sort of thing.
Are you *sure* about this reply? I can't see the reason for CIM if I have to store the cc info on my server - that's the whole point to CIM, right? At least that what the webinar host stated Thursday and what the web page alludes to: https://developer.authorize.net/api/cim/. As I understood it, CIM is basically a remote, secure, database that stores sensitive cc info.
If I have to store cc info on my server, then update CIM, what's the point? There's no reason to signup for CIM and pay $20 a month extra if that's the case.
dazed and confused,
07-16-2011 01:09 PM
To use the API version, the customer has to have some way to get their cc number and expiration date stored on the CIM.
Since they're not on the AuthNet server when they are putting the information in, it has to be passed to the CIM through the API that you fire up when they're done making changes/additions. (you probably already know this)
I was in the same boat you are in now.. thinking that all versions of the CIM meant I didn't have to actually pass any critical information through my own pages. But, since the only way a credit card number is going to get to the CIM if you're not using the Hosted system is sending it through a form, it has to be passed.
After the initial credit card number is passed and the CIM record set up, you wont have to pass it again if changes are made.. but whatever system you set up on your site to allow modifications to an individual payment profile record will not be able to show the entire credit card/bank account number, or expiration dates.
As far as storing the credit card data on your end.. I guess you technically dont have to store the actual credit card information at all. Just store the paymentProfileId for the card/account.
Then, if a customer needed to make a modification, you would just pull the data off the CIM server, populate a form with that data (minus the credit card number and expiration date), and allow the customer to make whatever changes they want.. or even delete the record.
When they're done, you just fire the modified information back to the CIM system with the API and you're done.
The reason I mentioned storing all of the data on your own server is just to keep from having to do the API call to the CIM to grab the information every time a customer views the page it displays on. If it's all on your own server you can just pull it from your own database to work with, and not have to pull it using the API to AuthNet.
The initial setup of the individual payment method is the only place you'd really need to pass the card number. After that, it's stored over on the CIM anyway, and AuthNet will pull that information from the stored record on their own server.
07-16-2011 01:16 PM - edited 07-16-2011 01:16 PM
I guess I should change the 'steps' for the API version of CIM...
1. You pull all payment method records from the CIM system using the API and the customerProfileId (if there are any)
2. Customer enters/modifies/deletes their payment information through a form on your site that you populate with the resulting data
3. You immediately pass that information over to AuthNet through the API so it can be stored/updated within the CIM system.
4. For a 'new' card/account, you would then pull down the new paymentProfileId and tie it to that customer for future use.
The only time you would need to pass critical data (credit card number, expiration, etc) would be in step 3 if the customer is either A.) adding a new payment method, or B.) changing any critical data.
Yeah.. that's better :)
07-19-2011 09:48 AM
Thanks, but somehow I must not be communicating the issue correctly. Let me try again:
When using AIM and CIM, I need to be able to display current cc info so the user can decide if they need to update that info. I do not want the complete cc number - the "short" form that is returned now is sufficient. What is lacking for this to work well (and without me needing to store any cc info on my servers) is the expire date - it's all X's.
It's the expire date that needs updating most often, so I need to display this to the user. Last four and expire. That's all. Auth.net gives us last four - just not expire. Yes, I can create/maintain a shadow db to track payment profile id's back to an expire date, but that's an awful kludge.