Lessons learned / feedback on recent usage of uc_cim

@m.stenta: Per your message here (http://drupal.org/node/624972#comment-6195840), I've started this thread to offer some feedback on our recent usage of uc_cim. I'm going to see if the other developers can also get on this thread and provide some thoughts.

To answer your question from the previous post, the version we have used pre-dates your involvement. This project started in Nov 2011 and we were using the available version of uc_cim from that timeframe. I believe its status then was purely dev and there was no recommended version or even a release candidate or alpha. We took the code as-is and modified it for our own purposes. This is what's in the info file for the version we are running:

name = Authorize.net CIM gateway
description = "The Authorize.net Customer Information Manager gateway."
dependencies[] = uc_payment
dependencies[] = uc_credit
package = Ubercart - payment
core = 6.x
; Information added by drupal.org packaging script on 2011-02-25
version = "6.x-1.x-dev"
core = "6.x"
project = "uc_cim"
datestamp = "1298620483"

While I didn't work as closely with the module as the developers, there are certainly a few issues that I noticed. Here they are in no particular order:

1) Code needs a lot of cleanup -- I get the sense that the previous version was written under the rush of building something quickly to meet a client's needs, without a lot of planning in advance. The uc_cim_charge() function in particular needs a *lot* of work. The entire process is crammed into one 350-line function and really should be broken out into many sub-processes. The way this was written led to us having to do some strange things to get the code to work the way we needed it to be.

2) Provide validationMode as a option -- When creating customer profiles, the current module forces a value of "testMode" when not on a production site and "liveMode" when on a live site. However what is missing is the third option, "none", which is provided by Authorize.net. While some clients might have a business need to use liveMode for validation on a live site, my guess is about 98% of them are going to want this set as "none". The reason why (as we found out from Authnet) is this process will always perform a $0.00 or $1.00 test transaction on a customer's account. The issue is there are quite a few processors and banks (and a growing number every day) that will flat out decline zero dollar transactions. Processors and banks see it as a security risk. So when this happens, the customer's transaction is declined even before an attempt is made to charge their account.

If validationMode is set to "none", Authnet still runs through their standard AVS and fraud detection steps, they're just not validating it with the credit card processor. The huge problem with uc_cim is that create_customer_payment_profile_request is called multiple times and in multiple situations, so there's no easy way to decouple it in situations where you need to run the function versus not run it. To get this to work, we had to skip the validation step in uc_cim and basically "fake" it into returning a valid result set. Therefore the information had been pushed successfully to Authnet, run through its AVS and fraud detection, and as long as the step completed successfully, we never request it to run through the processor/bank $0.00 test transaction.

This is a convoluted way to have to handle the problem, but we really had no choice since we were not in a position to re-write the entire module.

3) Be consistent on credit card access -- The uc_user_edit_card function allows a user to edit his or her card. If we're signed in as uid = 1, we get an error message from Authnet saying we are unauthorized to view the page. That's because there is code in the module which restricts access on a users profile pages ("/user/[uid]/creditcards") to only be for the owner of the card. However in a strange twist, I can click on "edit" next to the credit card on an order form (link of the form "/admin/store/orders/[order-id]/cim-edit/[cim-profile-id]"), and I can modify a version of the form that is *exactly* the same as what is shown on "/user/[uid]/creditcards". It's silly that I can edit it when the URL is connected to an order but I can't when it's on the user profile.

There should be two things: first, uid = 1 should be able to modify anything in any situation. That's the way it is on all Drupal sites. Second, access to modifying credit card forms should be a module permission, where it can be granted to particular roles for "all" and for "my own".

4) Consider rebuilding leveraging standard uc_authorizenet and uc_recurring approaches -- I think most of the concepts offered in uc_cim can certainly be leveraged and the process for editing CIM Customer Profiles, credit cards, posting refunds, etc. can (and should) be incorporated in to a future version. However it might just be best to put uc_authorizenet, uc_recurring, and uc_cim side-by-side, and figure out a solution that puts uc_cim functionality into options available in uc_authorizenet and uc_recurring.

I see you've started the Authorize.net API module (http://drupal.org/project/authnet). Looks like an interesting idea. The key for us all along has been integration with uc_recurring. A CIM solution that only works for single Authnet transactions won't meet the need since we are usually building membership-based sites.

Let me know if I can answer other questions for you. Thanks.