uc_recurring.module::uc_recurring_get_recurring_info()

Sounds to me like, the hook is there, but for some reason either the dynamic function doesn't exist or the $items being returned is NULL? I'd like to test your code out. Can you roll a patch, or did you just place these at the end of the module?

That function is a hook [hook_recurring_info()], so you need to use it as a hook, ie: modulename_recurring_info() so it can be found:

function uc_cim_recurring_info() {
  ...
}

I would also change all your callbacks to start with uc_cim, as that is what the module name is and you will only run into problems prefixing other modules namespaces at the front of your functions.

As for why do you need to declare $items['authorizenet'], because uc_recurring will look for a item with the same key as the gateway, which in the case of authorizenet payment gateway module is "authorizenet", that could be different for uc_cim (I haven't looked at the code and if it declares a different gateway?"

That hook is well documented in uc_recurring.api.php as its the key to make recurring payments work.

We might also be willing to put some cash toward it. I'd also like to help, although I'm not as familiar with the module as others.

Woohoo! Care to post a patch?

Those function names are still very strange names to me:

    'renew callback' => 'uc_cim_authorizenet_uc_cim_renew',
    'process callback' => 'uc_cim_authorizenet_uc_cim_process',

Something like:

uc_cim_recurring_renew()
uc_cim_recurring_process()

Would make much more sense and readable to me, if I was to look through that code for the first time.

I have glanced at the uc_cim module, I have an issue with that module, I think it would be fair greater to see effort focused on one solid authorizenet module instead of multiple modules, the reality is that the one in core is always going to get more users, so that seems like the better option to focus attention on. There are features in uc_cim that really shouldn't be there as they are not specific to that gateway and would have been so much better if the developers could integrated then into modules like uc_recurring and other ubercart modules where everyone using other gateways can benefit from the features.

That said I am potentially available to do some (paid) work on this if you still need help - otherwise if you have made progress do post your work, a patch to uc_cim makes the most sense here.

Agree completely.

I'd personally love to see the patch made to uc_cim first, to get it working, and then see if we can get that work (and the rest of the advanced CIM functionality) back into core. It really doesn't make sense to have both modules, especially when core authorize_net functionality in UC provides some level of CIM integration. I don't like that uc_cim provides its own cc form in checkout, either. Things like that which could be merged as a 2nd step of the process would make things much easier to focus efforts on.

It also removes one point of failure for things like uc_recurring; instead of making sure uc_recurring works with both core AND uc_cim, we can focus on just getting it to work with core.

Let me know what I can do to help. I'll try taking a look at some of the other CIM issues and see which ones I can try to patch in core, but if I do, I will put that into another issue so as to not hijack this one.

jaypark,

I'm really interested in getting your code as well. Let me know if I can help with any tasks and testing. We have a live a.n. account ready to go, could probably get a production test setup there as well.

Please post some code when you can, would love to get testing! Thanks for your hard work on it.

subscribing...

subscribing

Great news! Looking forward to it.

I've been digging into all the various threads here regarding getting the Authorize.net CIM stuff working, and am seeing a need for a level of abstraction that could make for bunny rabbits and rainbows in the long run.

uc_recurring does a great thing, in that it abstracts recurring payments away from the gateway that actually implements those recurring payments, such that I can swap out gateways, but not have to have a different UI for assigning recurring payments to products, selecting recurring payments during checkout, or allowing users to manage their own recurring payments (cancel/change card data etc).

uc_cim addresses the issue of secure customer data storage, but its only geared towards one specific gateway, which will help out those of us who want to use authorize.net's CIM service, but doesnt help any other CC tokenization or data vault implementation.

What I propose is that we either

• A. extend uc_recurring to incorporate the interface of customer data storage to allow gateway plugins to be written OR
• B. create a new module "uc_tokenization" or "uc_datavault" or "uc_secure_profiles" or something like that

The features that Im seeing that are the most universal with credit card tokenization solutions pretty much boil down to storage of CC data (card#, cvv, Expiration, Name on card), Billing address for the cards, the customer (id, name, etc), and *sometimes* shipping profiles as with CIM.

This abstraction would make for a consitent UI for customers, and a consistent API for other modules allowing for:

• Customers to reuse their existing cards/shipping data at checkout
• Customers to Update their data on their profile pages
• Cart to handle the 'anonymous user' issue cleanly and not save profiles if truly anonymous checkout is allowed
• Provide a single way for uc_recurring to interact with a recurring charge, independent of the gateway.

Probably More?

There are many other customer data storage solutions out there beyond just CIM, so this would allow for much easier implementation of those gateway interfaces e.g.:

• http://www.braintreepaymentsolutions.com/gateway/vault
• http://www.beanstream.com/public/payment_profiles.asp
• http://www.trustcommerce.com/risk-management/credit-card-and-privacy-dat...

Additionally we can create a test customer data storage gateway such that one can test this sort of functionality without actually having a gateway plugged in.

Im moving this back to uc_recurring since it appears as though the maintainer of uc_cim isnt actually doing anything with it, plus I'd like to ensure Univate's input on this matter..

@Mixologic - uc_recurring is in part already doing what you are after, with the right gateway (e.g. Auth CIM) its possible to use an existing details stored in a recurring fee to charge any amounts at anytime. Its just the front end requirements that need to be developed - so its possible to develop a module now to handle "single click checkout" using uc_recurring as the backed assuming you are using a gateway like Auth.net CIM that supports charging amounts to a stored profile. There certainly are other gateways that support these features I have used two in Australia uc_securepayau and uc_eway.

The way this is being handled in uc_recurring is the payment gateway module is in control of how recurring profiles are setup and charged when renewals are due. So there are two core functions that happen between uc_recurring and gateways:
* when a users checks out with an order, make a recurring fee out of it
* with this order and recurring fee, charge the user

With these two functions in place, we can build a lot of functionality on top without needing to know anything about the gateway or where the payments are coming from.

I'm not sure if you are suggesting that we actually store CC#'s (no-one is ever allowed to store cvv anywhere including in Auth CIM, I would encourage anyone dealing with online payments to read the PCI spec) - but heading down this path is a bit of a minefield, I think its best to deliberately leave in a technical hurdle to storing CC details (it is possible to do it with uc_recurring with a small amount of code now - the time consuming part is auditing your code and system for all security requirements). I know that I don't want my credit card details on some system where the site builder/developer does not have the required security skills/knowledge to protect my details.

Although having said that I certainly would like to have CC expiry dates stored somewhere useful, so we can monitor for upcoming details about to expire. But there is already another issue related to this specific problem.

Definitely not suggesting we store cc#'s.. I was more getting at the "single click checkout", and more specifically a standarized UI. If we are storing credit cards with a tokenization provider we should be able to allow users to add/update/delete their cc's from their user page (much like uc_cim does), and re-use those cc's on checkout.

At the moment updating credit cards in uc_recurring is an operation that can be provided by the gateway, not sure if its working in Auth.net CIM, but in the gateway I work with uc_securepayau I have created an 'update' operation that admin or users can use to update the cc details stored.

Its possible to streamline this although the form to enter the credit card details is the simple bit and we can already reuse the cc form form uc_credit, the complex part of the interaction with the gateway.

@jaypark, #23,

Can you explain more about why you need to add a uc_cim_check_fee_record($fee); call in uc_recurring module?

I had a look at the uc_cim code and can't see any reason why there is a need to patch uc_recurring to do anything.

The uc_cim_check_fee_record() does two things:
1) sets the order status to "complete"
2) sets the uid for anonymous purchases

Firstly uc_cim should not be setting the "order status" this should be done through CA when an order is paid and if not shippable. This is already setup and working with uc_recurring when an order is renewed.

Secondly the uid is set for anonymous purchases in uc_recurring through the hook_uc_checkout_complete()

/**
 * Implementation of hook_uc_checkout_complete().
 *
 * This function is require to complete recurring orders for anonymous
 * purchases as the uid is not set until the order has completed checkout.
 */
function uc_recurring_uc_checkout_complete($order, $account) {
  $fees = uc_recurring_get_fees($order);
  foreach ($fees as $fee) {
    if ($fee->uid == 0) { // check for anonymous uid
      $fee->uid = $order->uid;
      uc_recurring_fee_user_save($fee);
    }
  }
}