Status of this module?

I too would love to know the status of this module. Any chance it will be working with UC 2.2 in the near future?

I'd be willing to contribute financially to the production of this module.

I'm also interested in knowing what the status is here. I'd like as robust a functionality as possible, even if that means rolling uc_cim functionality into core Ubercart.

Same here, subscribing. Looking for a way to generate renewal emails prior to subscription renewal so customers can update their card's expiration date if necessary.

We've been hitting a bunch of issues with this module, and have made some patches, but it really needs a bit of a rewrite for the current ubercart architecture...

We do have it mostly working, but there are some issues with anonymous checkout...

I'm interested in collaborating with some of you guys if we have a clear idea of what needs to be done. I really need this working.

Freelock, would you mind posting your patches? If you can that'd be great. Also, feel free to let me know what other issues you're having. I think we should get these issues created here so that we can track them and start patching.

Hi,

Ok, looks like our patches are pretty minor, but essential -- we were getting some validation errors when trying to post transactions, related to extra commas in the amount and minor stuff like that.

We also found some cim profiles associated with the anonymous user, and I did a simple patch to prevent that -- which doesn't work. Our client called back with no anonymous users being able to check out, and we found an error log saying Authorize.net would not store any more than 10 profiles for a single account (which was the anonymous account!) Our solution, since the client was out of budget: turn off anonymous checkout. (and delete those scary stored profiles!)

So this really does need a much bigger rewrite. We have another client interested, but they've gone away until September or so, so I expect we won't have much time to devote to this for the next couple months. Always happy to give feedback -- I created the uc_epn payment module with uc_recurring support, so I'm getting fairly familiar with what's needed for uc_recurring and payment methods...

-- John

Cool, thanks for posting that. I am also interested in getting anonymous checkout enabled. What do you think would be required to get the two to play nicely together? I imagine some other kind of unique identifier for the anonymous user - perhaps an IP address? Or some kind of a token that updates the user from 0 to whatever the uid is created once the user checks out? (If I recall correctly, Ubercart still *does* create an account for the anonymous user. Is that still the case?)

I haven't done a really deep dive into this just yet, but I'm starting to think the implementation of this module has some deep flaws...

It tries to do too much, and it introduces a lot of brittleness into the system.

What I'd like to see is splitting out some of the functionality into the right places, and I'm thinking as follows:

uc_cim - largely responsible for interfacing with the CIM API, associating payment profiles with user accounts, implementing profile creation, charging, and deletion

uc_recurring - a deeper layer controller for determining when to do recurring charges, providing a common user interface for managing stored cards that calls hooks implemented by uc_cim (and other payment gateways that offer similar functionality)

uc_authorizenet - handles one-time transactions, anonymous checkouts - and uc_cim should use uc_authorize.net for some transactions

uc_cim does some great stuff, but the duplicate billing address section really gets in the way, and I think it should just plain not handle anonymous checkouts. Plus, we're working on a uc_epn payment gateway that provides similar functionality to uc_cim (although it won't let you update stored card details), and it would be great to make some of the user interface screens available to other gateways without having to just copy code...

I really think uc_recurring should be a base layer for handling repeated transactions, whether they're one off or regular subscriptions, instead of having a bunch of similar code scattered across a bunch of individual gateway modules.

I may have to dig into this shortly -- it turns out a recent update to uc_recurring broke recurring payments on our site -- which means money out of my pocket! See #779406: Breaking uc_recurring up into an API focued module and product feature module. for more on uc_recurring...

Cheers,
John

Hi freelock,

Are you available to chat about this anytime on IRC? I would love to get this banged out. I think the anonymous user handling can wait, but in the end I think it should definitely be added / fixed. My idea is that the anon info is only temporary, and should be destroyed once the order is completed, and a new user account is created. The only question I have is when in the process does this happen? The $user account should be created before the order gets completed - if this were the case, we'd never run into any issues, because there would never be an anonymous user. Do you think this issue is more an Ubercart than a UC Cim issue?

If you can, I'd like to have a quick convo about the parts of the module you think are duplicating functionality and what else you think we can do to get everything in ship-shape. Let me know what your availability is like - it doesn't have to be for very long, but this is a longstanding feature I'd like to get rolled into our site :)

OOoohhh! subscribe!

Hi,

I'm often on IRC in #drupal, as freelock... not often paying attention, but if you ping me I should respond...

Cheers,
John

Subscribing

subscribe

subscribing... would love to see this module as an "addon" to the existing core authorize.net cim module

+1 http://drupal.org/node/725954#comment-3147222

uc_cim mostly works with latest dev version of ubercart... doesn't work with uc_recurring.

trying to get the ball rolling with uc_recurring: http://drupal.org/node/915084 any takers?

subscribe

I too would like to know where this module stands.

My company's site needs to reuse a stored CC (on auth.net with CIM). But we actually need to authorize-only a transaction up to 72 hours BEFORE we capture funds (which may be less than the authorized amount). These are not recurring fees, but unique product purchases that can be different in each order.

If such functionality doesn't exist (I'm doing more research now), I'll likely be attacking this at some point in the next few weeks (or look for an alternate approach, such as paypal).

As for the anonymous user issue, why not just hide the CIM payment method and instead display a message saying that a registered users can securely save credit info for later use?

I'll be digging into this module over the next week or so. If we find that it is the best solution for our use-case, we would love to contribute my hours to making the module more usable.

Thoughts, comments, complaints?

Myself and jaypark are now co-maintainers as we're going to begin using uc_cim on our production sites. (At least, I am, can't speak for jaypark.)

There are some outstanding issues in the queue. Please take a look at them and provide your input. This module is the furthest along as far as CIM goes, and Authorize is a pretty decent gateway (I do plan on switching to Braintree in the future) so I'm more than happy to commit bugfixes to this module, but I'm not sure what other development I can do beyond that - but I'll do whatever I can to make sure the module is usable for everyone!

Super! Glad to see some new effort going into this. I'll review/contribute when I can...

TorgosPizza, what version of uc_recurring and ubercart are you using? I am noticing some missing items (no cancel buttons) on uc_recurring so I'm thinking I need to downgrade a bit.

uc_cim has been in production use for an independent movie production subscription site for about a half year now. i think we need to start looking at a d7 port.

Hello! I'm about to experiment with implementing this module vs. the authorize.net module included with Ubercart, however i see this on the project page:

This module is compatible with Ubercart 6.x-2.0-rc3 and the uc_recurring 6.x-2.x-dev dated 2009/06/23.
It is not yet compatible with the latest releases of Ubercart (6.x-2.0-RC7) and UC Recurring (6.x-2.0-alpha1).

Is this still true?

I'm using Ubercart 2.6 and UC Recurring and am excited / hoping to get this working.

I haven't seen any major code updates since earlier this year so I'm guessing there hasn't been any major updates. Ideally I'll get the greenlight to work off this module and push it back to the community.

cridenour, I'd love to know if you've made any progress. Do you have a sandbox module setup?

If not, I'd like to look at potentially rewriting the module to be more of a CIM API integration ("glue") module, and break out the other functionality into submodules, similar to how the Paymant modules for UC are handled.

It would be really nice if someone can point me the versions/patches to use with uc_cim module to get it working with uc_recurring module.

I tried the latest version of uc_recurring module 6.x-2.0-alpha6 but it is not working as /admin/store/settings/payment/edit/recurring shows only credit card option there. I'm not able to add cim_creditcard as a recurring payment option.

I've applied the patch available at http://drupal.org/node/925860#comment-3718794 to the current uc_cim module. I've used the latest version of uc_recurring (6.x-2.0-alpha6) and ubercart (6.x-2.7) and the recurring payment worked properly.

Development has resumed on this module. The new maintainers are working to get all the patches in the issue queue into the 6.x-1.x branch.

Some of them, however, will no longer apply to the 6.x-1.x branch, since we've started cleaning it up (including the one in this issue). If you absolutely need to use this patch, or one of the other ones in another issue (for example: #925860: uc_cim patches for ubercart 6.x-2.x-dev, uc_recurring 6.x-2.x-dev), please download the 6.x-1.0-alpha1 release. It is a snapshot of the 6.x-1.x branch, before we started new development. Patches should apply cleanly to it.

All new patches and development should be done on the 6.x-1.x branch.

Leaving this issues as "active" for now, until I can parse through it for useful information.

Thanks for the update and taking the reigns with this, m.stenta! Are you taking the "glue module" approach or something else?

Yea hopefully we'll be able to get this module working great! It could certainly use it!

amorsent and I would love to talk to you about it in more detail, if you're interested. Any thoughts or knowledge you have would be greatly appreciated! And if you still have any interest in developing for it, that would be equally welcome! (it sounded like you've moved on to another solution though)

Feel free to send me a message.

@m.stenta I think we're going to be working with this module for a project that's due in August. Can you let me know what issues you'd like help with in moving this forward?

@kostajh: If you need to, I would suggest starting with the alpha1 release. That was the version of the module before amorsent and myself took over. The 6.x-1.x dev branch is currently considered unstable, as we've been making a lot of changes and some of them need further testing.

The alpha1 release is FAR from perfect, however, as you can see from the issue queues. Take a look at this recent issue too: #1673216: Lessons learned / feedback on recent usage of uc_cim.

We're in the process right now of weighing options... trying to decide if it makes more sense to rehabilitate this module, or start fresh with submodules of the new http://drupal.org/project/authnet module.

I personally need CIM functionality for customer credit card management for a client site, so that's my incentive, but we're trying to take an approach that's as clean and generalized as possible with the authnet module. What are your needs exactly? Perhaps you can help us get where we all need to go.

@m.stenta - I was using the 6.x-1.x-dev release that corresponded to the alpha1 release you created. After updating my local environment to the new 6.x-1.x-dev branch, a bunch of issues we were dealing with were resolved. The alpha1 release is usable but has some major usability issues.

I need users of my client's site to be able to manage credit cards - save new credit cards, edit existing ones, and delete old ones - through Auth.net's CIM interface, and I need them to be able to use card info stored via CIM when making purchases in Ubercart.

I'll keep an eye on the authnet module. thanks for your efforts!