Act as an extension of Ubercart's uc_authorizenet, not a replacement

Subscribing....

Subscribing

Once again, I'd be willing to contribute financially.

I agree with the original post. We already have a website running with existing customers and would love a functionality to remember/update the CC info.

We can contribute some $$ toward the development of this.

Best,
Andrey.

willing to contribute financially...

We are also willing to contribute $$ to development of this module to provide better integration with core and clean up outstanding issues

Interestingaftermath, mr. andrey, and frankrizzo - perhaps we can come up with a number we can agree to for development and features needed, and run it by some specific programming houses instead of us hoping for someone with the skills and interest to stumble on this thread :o

One issue I've discovered that will hinder progress: core CIM stuff is stored as part of the $data array in the $order object. This is problematic especially to administrators who want to take a birds-eye view of all CIM profiles; getting all that data unserialized and in a table will be expensive.

So, part of the issue is refactoring the way core handles the CIM stuff. It can definitely utilize it for uc_recurring (I have tested it myself) but this wouldn't exactly be a trivial change.

torgos! :D

Curious what kind of number you would put on getting this module up to snuff with core uc? Sounds like a significant amount of work, but I bet we could pool enough funds together

Throw me an email if you start on this. I'd really like to see this feature, and can pull some funds together.

This would be great. Please see also http://drupal.org/project/uc_authnet and #925860: uc_cim patches for ubercart 6.x-2.x-dev, uc_recurring 6.x-2.x-dev. Maybe now would be the time to start collaborating, and consolidating funding.

Looks like I might have a client with some funding available, too -- and with funding, we can work on development of this. Perhaps divide and conquer?

Who's interested in development? I'm thinking we'll get our client to sponsor one piece, and work with whoever else has time/interest in working on this to make sure we're all on the same page, make a complete solution...

I'd be happy to help. I've done a little bit of work massaging some parts of the UI but put it on hold a while back. Wouldn't mind getting back into it soon.

My friend and I are both interested in doing development on this module... we contacted the original maintainer and torgosPizza to see if we can get commit access.

We both have clients that could use this module, so they might be able to contribute funding as well. Perhaps we can pool resources and put together a list of the top issues and do what we can.

It looks like it's been a while since this has been updated... are people still interested in sponsoring this?

I'd be happy to make you a committer. (You could always start by making a sandbox project with your changes if you like.)

At this time the module is too broken for our use, and we've decided to start upgrading to D7 for some of its many benefits. But all modules should stay maintained so for that reason I've gone ahead and given you both commit access. Thanks!

Thanks torgosPizza!

As I'm digging into #1145236: Refactor to use PHP SDK from Authorize.net, I'm getting a better understanding of both this module (uc_cim), and the original Authorize.net module that ships with Ubercart (uc_authorizenet). I'm starting to see more and more possibility for simplifying this module and turning it into an extension of uc_authorizenet, rather than a replacement.

I think it would close a number of the other issues in the queue, as well, including:
#1649208: Change "CIM Credit Card" to "Credit Card"
#725954: Status of this module?
#615692: Transaction Types
#942566: Paid Bounty to make CIM module work with other payment methods when creating order manually
#1328132: Payment method information repeats on the checkout review page when uc_cim is used.

I plan to start working on this as soon as I'm done with #1145236: Refactor to use PHP SDK from Authorize.net.

Just some "note-to-self"s about things to consider:

• Use hook_payment_gateway_alter to replace the default uc_authorizenet_charge() gateway callback function with our own (uc_cim_charge() perhaps).
  • Rewrite existing uc_cim_charge() to work as a gateway callback, and to simplify it.
  • Possible issue: how will this affect AIM and ARB?
• Form alter the gateway settings form.
  • Add a description to the gateway URL fields explaining that they will not be used if the CIM service is used (URLs are hard-coded in SDK).
  • Add fields for test login id and transaction key.
• If "Developer test" is selected for "Transaction Mode" in the "CIM settings" of the uc_authorizenet gateway configuration, then use the {uc_cim_TEST} database table, rather than {uc_cim}.
• Use uc_authorizenet variables for login id and transaction key in uc_cim.
• Get rid of all duplicate code and variables in uc_cim.

uc_cim_charge actually IS already a payment_gateway callback. But none the less, it's a really absurdly complex function that needs to be broken into smaller pieces.

The relevant hooks integrating with ubercart are:

• hook_payment_gateway
• hook_payment_method
• hook_order_pane
• hook_checkout_pane

The standard payment method checkout and order panes are provided by the uc_payment module. These panes call out to _payment_method_list() which basically invokes hook_payment_method to get a list of payment methods from modules.

The uc_credit module implements hook_payment_method to provide a "Credit Card" payment method. The callback for this payment method is uc_payment_method_credit

The uc_authorizenet module only provides the payment_gateway. It does not implement any panes or payment methods. uc_authorizenet is basically just:

• a uc specific reimplementation of the authnet sdk
• a uc payment gateway wrapper
• a settings form
• some integration with uc_recurring ( actually a fair amount ... )

(And almost everything is fully loaded on every single page request - BLAH.. WTF! )

If we're not dead set on making a separate authnet sdk wrapper as a stand alone dependency, then we COULD see if uc_authorizenet's existing CIM functions give us what we need for uc_cim. Otherwise I don't see much point in extending uc_authorizenet - Better to create uc integration module for the proposed authnet api that just provides the payment gateway wrapper, and the uc_recurring integration. - This is also almost what uc_authnet is ... ( ? )

uc_cim Is currently implementing all 4 of the hooks mentioned above. It provides separate panes, a separate payment method, and a payment gateway.

Perhaps we CAN look into throwing out the uc_cim implementations of hook_order_pane, and hook_checkout_pane in favor of working with uc_credit and uc_payment they way they expect?

According to the readme, you can either use uc_cim's combo pane, or the payment / billing panes provided by the uc_payment and uc_order modules respectively. If using the uc_cim's pane you get the benefit of selecting from saved billing info, BUT it currently does not support an order total preview. Using the regular panes instead is fine, but it means uc_cim is only adding cim profiles in the background, not allowing customers to select an existing profile. Maybe this is the real issue to fix??

uc_cim can exist without uc_authorizenet ( which some might like ). Considering it also currently provides it's own payment_method, I'm sort of also wondering it it renders uc_credit unnecessary ?? The callback for uc_credit's payment_method is uc_payment_method_credit - a huge monstrosity dappled with $_POST ... ( blah! ) uc_cim's is actually MUCH smaller ( not sure what the full differences are ).

Anyway, That's where my research stands. It seems to me that uc_cim is not entirely off base...
The payment gateway - I think uc_cim is best cast as a bridge for the API replacing uc_authorizenet. Either that, or we throw out the SDK and use uc_authorizenet as the "API" if that's even possible...

The payment method - This is mostly a wrapper around the credit card editing form itself ( i think ). We could try to adapt and re-use uc_credit's functionality on this ?? But I don't know .. the code there looks awful.

The checkout / order panes - This seems to me like the area that could be tweaked. There are currently 2 options on how to set this up, each with advantages and disadvantages. Maybe we can consolidate them, or maybe we can help each option work a little better.

Woops, that's a tags field, not title ..

uc_cim does list uc_credit as a dependency, and does use some of it's functions.

@amorsent: all good points. I think there was some confusion about what the uc_authorizenet module actually provided, and the more I look into it, the less necessary it seems in the grand scheme of things. I think the bigger pieces are the panes that are used in the Order and Checkout interfaces, including the Payment pane provided by uc_cim.

Currently, managing orders from the admin side is almost completely broken with the uc_cim module. That's a big issue, and it mainly stems from the fact that uc_cim requires that your replace Ubercart's default "Payment" pane with it's own "Credit Card Payment" pane. Not only is this custom pane broken, and duplicating some of the code that already exists in Ubercart, it also makes it impossible to accept any other payment besides a credit card (ie: checks). This is reported already here: #942566: Paid Bounty to make CIM module work with other payment methods when creating order manually.

I'm starting to get overwhelemed by all of the big long issues in the issue queue. I'm inclined to say that we should put our heads together and create one overarching "Roadmap" issue, that outlines the bigger picture of what we need to do. This will take some thought, but ultimately it will help us keep all these other issues organized.

We may end up closing this issue entirely, if we find that replacing uc_authorizenet DOES make sense, and starting some other smaller issues for each of the main pieces of the roadmap.

I'd like to congratulate you guys on taking ownership of this module. I've always felt uc_cim has a ton of potential, and the Ubercart community would benefit greatly by having the features this module provides.

As a side note, we just wrapped up a large-scale site that uses uc_cim (6.x-1.x-dev) as one of the payment gateways. The ability for customers to update their card profiles was a huge need for the client, and was a key factor in deciding to use uc_cim instead of other options.

We had to make some modifications to get the module to work the way the client needed, and we have been able to implement a decent solution. There were many lessons learned from using 1.x-dev, so if you're interested in hearing more about some of our experiences I can put you in touch with developers who worked on the code.

Let me know, and thanks again for jumping in to make this happen.

@ron_s: yes please! I would love to hear what you learned. Feel free to contact me separately, or maybe start a new issue so we can exchange thoughts.

Also, you said you used the 6.x-1.x-dev version. Was this the version BEFORE amorsent and myself started working on it? Just curious if any of the changes we made are being used on a live site, or if it's still the old code. FYI: we made an "official" release of the 6.x-1.x-dev branch at the point right before we started changing things, and called it 6.x-1.0-alpha1... so if you want to have a "real" release in your codebase that is always at the same point, you should be able to safely drop that one into place. We started making changes to the 6.x-1.x branch about 2 weeks ago, so if you downloaded it before that, then you have that original code. As I said on the project page, the 6.x-1.x branch is no longer considered "stable"... mostly because we started making changes, but haven't been testing them very thoroughly yet. That's why we created the 6.x-1.0-alpha1 release, in case anyone wants to use the code that was considered "stable" (relatively) for the past 2 years...

Update: we built a new Authorize.net API module from scratch: http://drupal.org/project/authnet. And we took over the uc_authnet project to provide CIM integration with Ubercart: http://drupal.org/project/uc_authnet.

Let's focus on those project now. UC CIM is officially abandoned, as far as I'm concerned.