Hi everyone,
I took the new commit of 6.x-2.x-dev from Sept 3 for a test drive with authorize.net CIM and here is what I found:

Modules enabled:
uc_recurring 6.x-2.x-dev
Authorize.net 6.x-2.0-rc6
Credit Card 6.x-2.0-rc6

Credit Card enabled as a payment method in product features for recurring fees.

My transaction went through without a hitch, but I noticed the following:

- The order did not show up on the Recurring Fees report
- My user profile page (My Account) no longer has a recurring fees tab
- The order log had no reference to the transaction being recurring.

Previously, using the UC_CIM module, the missing elements noted above were all present.

As admin, when I viewed the order, I do see the Process Card item there and it appears to have all the correct information, including my customer's CIM profile as a selectable option.

Also, not sure if this is related, but I received the following error when I ran my Recent Log Entries report:
# warning: Invalid argument supplied for foreach() in /includes/common.inc on line 884.
# warning: strtr() [function.strtr]: The second argument is not an array in /includes/common.inc on line 901.

I am at your service to try things to move this forward.

CommentFileSizeAuthor
#21 Picture 3.png8.45 KBbearstar
#21 Picture 4.png58.07 KBbearstar
#21 Picture 5.png45.02 KBbearstar
#21 Picture 6.png31.47 KBbearstar
#11 uc_recurring-567896-11.patch1.29 KBunivate
#2 uc_recurring-567896.patch996 bytesunivate

Comments

bearstar’s picture

bearstar commented

One more item. When I plugged in my order number into the Recurring Fees Report filter, I got a blank screen.

univate’s picture

univate commented
Title: Testing the new commit of 6.x-2.x-dev with Authorize.net CIM » Credit payment method should be disabled for recurring orders if the default credit gateway doesn't support recurring payments
StatusFileSize
new uc_recurring-567896.patch996 bytes

Payment method/gateway modules (like uc_authorizenet) need to be uc_recurring aware, for ubercarts core gateway we are going to include them in a directory as part of this module.

That recent commit didn't include a file for "uc_recurring.uc_authorizenet.inc" that is required to support that gateway, I (or someone) needs to go through that other issue on authorizenet support to try and work out what works and create that file.

But you have brought up an issue which needs fixing and that is that the credit payment option should be disabled for recurring orders if the default credit payment gateway doesn't support. I hvae a patch to fix that, which i will commit shortly if there are no objections.

For the moment if you are keen to do some testing then it would be good to test on the test_gateway.

univate’s picture

univate commented
Status: Active » Needs review
bearstar’s picture

bearstar commented

Thanks...I applied your patch and ran my transaction again (just for kicks) and it didn't complain about the lack of an authorizenet inc file.

I then tried the test gateway and when I went to /admin/store/settings/products/edit/features I got the following error:

Fatal error: Cannot redeclare uc_recurring_test_gateway_renew() (previously declared in /sites/all/modules/ubercart/payment/uc_credit/test_gateway.module:74) in /sites/all/modules/uc_recurring/modules/uc_recurring.test_gateway.inc on line 84

So, I commented out that function in /sites/all/modules/uc_recurring/modules/uc_recurring.test_gateway.inc and the page loaded OK and I could see that Credit Card was selected as the payment method.

I then ran a test order using the test gateway and all went smoothly, but I still did not see any reference to the order being a recurring order (either when viewing order details or when running the recurring fee report). Also, there was no reference to recurring order in the My Account page.

Hope these comments are helpful and I look forward to testing the uc_recurring.uc_authorizenet.inc file.

univate’s picture

univate commented

getting a clean unpatched copy of the latest version of ubercart will fix the error you are getting with the redeclared functions, the whole point of the recent commit was to remove any need to change ubercart - so all previous patches are now no longer needed.

Other then that you just need to

* set the default credit gateway to test_gateway on:
admin/store/settings/payment/edit/methods

* enable the credit payment method for recurring fees on:
admin/store/settings/products/edit/features

* create a product with a recurring fee feature

* make sure members have the permission to "view own recurring fees" if you want them to have access their recurrring fees.

Start placing orders.

bearstar’s picture

bearstar commented

Getting a clean, unpatched ubercart makes sense. I can confirm that I did all the other items you mentioned, with the possible exception of creating a product after the fact. I have several products already set with recurring fee features, so I was just testing those.

Thanks!

bearstar’s picture

bearstar commented

I tested this with a clean ubercart install and test gateway and everything went smoothly. The only issue I noticed was that there was no link to /admin/store/orders/recurring from the Administration menu ("Recurring fees") (not a big deal)

The view recurring fees link from the user profile page worked great. This is all very clean and usable. Thanks.

I am keen to test the CIM module that is being discussed, so please let me know how I can help.

univate’s picture

univate commented

There is still a problem with the uc_credit gateway, its returning itself as the fee_handler, it needs to return the default credit card gateway:

maybe something like...

--- modules/uc_recurring.uc_credit.inc
+++ modules/uc_recurring.uc_credit.inc
@@ -10,14 +10,18 @@
  * Implementation of hook_recurring_info().
  */
 function uc_recurring_uc_credit_recurring_info() {
-  $items['credit'] = array(
-    'name' => t('Credit card'),
-    'payment method' => 'credit',
-    'fee handler' => 'credit',
-    'module' => 'UC recurring',
-    'process' => 'uc_recurring_uc_credit',
-    'renew' => 'uc_recurring_uc_credit',
-  );
+  $gateway = uc_credit_default_gateway();
+  $func = 'uc_recurring_'. $gateway .'_recurring_info';
+  if (function_exists($func)) {
+    $items['credit'] = array(
+      'name' => t('Credit card'),
+      'payment method' => 'credit',
+      'fee handler' => $gateway,
+      'module' => 'UC recurring',
+      'process' => 'uc_recurring_uc_credit',
+      'renew' => 'uc_recurring_uc_credit',
+    );
+  }
   return $items;
 }
bearstar’s picture

bearstar commented

The code above seems to be the same code that was posted as a patch in #2, above, right?

Also, I took a look at ubercart/payment/uc_authorizenet/uc_authorizenet.module as a potential model for creating uc_recurring/modules/uc_recurring.uc_authorizenet.inc based on the test gateway and I must say it is a bit beyond me to make heads or tails of it :-)
I am keen to see what you do so that I potentially help myself a bit better in the future!

univate’s picture

univate commented

There was one small change to the fee_handler line, but there is alternative solution to this problem and that is to just have uc_credit return the default credit gateway info instead.

function uc_recurring_uc_credit_recurring_info() {
  $gateway = uc_credit_default_gateway();
  $func = 'uc_recurring_'. $gateway .'_recurring_info';
  if (function_exists($func)) {
    return call_user_func($func);
  }
   return FALSE
}
univate’s picture

univate commented
Priority: Normal » Critical
StatusFileSize
new uc_recurring-567896-11.patch1.29 KB

Unless there are any objections I will be committing the following, which fixes:
* setting the fee_handler to the default credit gateway that will is currently processing credit payments
* only return recurring info for uc_credit if the default credit gateway actual support recurring billing - at the moment it doesn't give any warnings that recurring fees will not be able to be set up.

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented 
+  $gateway = uc_credit_default_gateway();
+  $func = 'uc_recurring_'. $gateway .'_recurring_info';
+    if (function_exists($func)) {

I think that if we already look for the function, we should use it, something like:

+  $gateway = uc_credit_default_gateway();
+  $func = 'uc_recurring_'. $gateway .'_recurring_info';
+    if (function_exists($func)) {
        $gateway_info = call_user_func($func);
        array_merge($items, $gateway_info);
univate’s picture

univate commented
Status: Needs review » Needs work

Actually this is going to probably need some further thinking because the default gateway doesn't necessary correspond to module name and there can be more then one item returned from:

'uc_recurring_'. $gateway .'_recurring_info';

Example being paypal WPP

The default credit gateway is $gateway = 'paypal_wps' but the info function will be 'uc_recurring_paypal_recurring_info'

univate’s picture

univate commented

For the moment I have committed this:

--- modules/uc_recurring.uc_credit.inc	3 Sep 2009 05:00:08 -0000	1.1.2.1
+++ modules/uc_recurring.uc_credit.inc	12 Sep 2009 06:17:56 -0000
@@ -10,10 +10,11 @@
  * Implementation of hook_recurring_info().
  */
 function uc_recurring_uc_credit_recurring_info() {
+  $gateway = uc_credit_default_gateway();
   $items['credit'] = array(
     'name' => t('Credit card'),
     'payment method' => 'credit',
-    'fee handler' => 'credit',
+    'fee handler' => $gateway,
     'module' => 'UC recurring',
     'process' => 'uc_recurring_uc_credit',
     'renew' => 'uc_recurring_uc_credit',

That way the fee handler for a credit payment will be the default gateway. Still need to deal with the actual issue to show a warning if the default credit card gateway doesn't support uc_recurring.

I think we should be able to do this somewhere in uc_recurring by checking that the fee handler exists in the list of recurring payment methods/gateways returned from:

uc_recurring_get_recurring_info()
univate’s picture

univate commented
Status: Needs work » Fixed

Ok I've fixed and commited this. I want to avoid anyone else trying to test with just any random gateway and not getting at least a warning that their gateway isn't support.

The fix is relatively simple, I've added a function that checks if the payment method is supported.

diff -u -p -r1.1.4.27 uc_recurring.module
--- uc_recurring.module	12 Sep 2009 03:30:37 -0000	1.1.4.27
+++ uc_recurring.module	12 Sep 2009 12:10:17 -0000
@@ -140,7 +140,7 @@ function uc_recurring_form_uc_cart_check
     // Remove invalid payment methods from the payment pane.
     $valid = variable_get('uc_recurring_payment_methods', array());
     foreach (array_keys($form['panes']['payment']['payment_method']['#options']) as $key) {
-      if (!isset($valid[$key]) || $valid[$key] === 0) {
+      if ($valid[$key] === 0 || !uc_recurring_payment_method_supported($key)) {
         unset($form['panes']['payment']['payment_method']['#options'][$key]);
       }
     }
@@ -148,7 +148,9 @@ function uc_recurring_form_uc_cart_check
     $count = count($form['panes']['payment']['payment_method']['#options']);
     if ($count == 0) {
       // Display an error message if no payment methods remain.
-      drupal_set_message(t('There are no payment methods configured for orders with recurring fees. Please contact an administrator to solve the issue.'), 'error');
+      if (user_access('administer recurring fees')) {
+        drupal_set_message(t('There are no payment methods configured for orders with recurring fees, enable one from <a href="@url">recurring fee admin settings</a>.', array('@url' => url('admin/store/settings/products/edit/features'))), 'error');
+      }
     }
     elseif ($count == 1) {
       // If only one payment method remains, make it the default.
@@ -517,6 +519,20 @@ function uc_recurring_default_handler() 
 }
 
 /**
+ * Checks that a payment method can process recurring fees. This is done by
+ * checking that a recurring fee handler exists for the payment method.
+ * 
+ * @param $payment method
+ *   The id of the payment method.
+ * @return
+ *   TRUE is a valid fee handler for this payment method is found.
+ */
+function uc_recurring_payment_method_supported($payment_method) {
+  $info = uc_recurring_get_recurring_info();
+  return !empty($info[$info[$payment_method]['fee handler']]);
+}
+
+/**
  * Include uc recurring own implementations.
  *
  * @return
bearstar’s picture

bearstar commented

Hi Chris,
I took your latest commit for a test drive and it went very well.
- Order was created
- Recurring order was created
- CIM profile was created
- I was able to edit, cancel and run charges.

Fantastic progress. Thank you. I will let you know if I run into any issues as I take this further.

Update:
Rolled it out with my production CIM account and all is well. One little note to anyone trying this: under /admin/store/settings/payment/edit/gateways CIM settings, be sure to put it in Production mode. If it is not in Production mode, you will get the old "Checkout cannot be completed without any payment methods enabled. Please contact an administrator to resolve the issue." error in checkout.

univate’s picture

univate commented

Thanks bearstar, thats great to hear, I can now tick this off my list as done.

bearstar’s picture

bearstar commented

Now that a day or two has passed and I have had time to see how recurring orders are treated, here are my observations:

- The original order created a new order at renewal time - Good

- The credit card transaction did not seem to work during the renewal process and it looks like it was trying to create a new CIM profile upon renewal. (I just set up a new order that will renew tomorrow so that I can verify that this is really a problem and not just a product of my various test transactions)
Log from renewal order:
Authorize.Net: Creating CIM profile failed.
E00003 - The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value '6' is invalid according to its datatype 'String' - The actual length is less than the MinLength value.

- When I deleted the original order and the new order that was created by the recurring transaction, there was no indication at /admin/store/orders/recurring that a particular order was no longer valid (had been cancelled) except for the zero in the "Left" column. Not a show stopper, but maybe it'd be better to have it say something like cancelled or completed. Also, the link to the order number that I had deleted remained so that it delivered a page not found error when clicked.

- When I, as the user, cancelled my own recurring order from My Account page, it was removed from my profile - Good

- I tried a fresh order to double check things and I noticed that something is being processed twice during the initial order. Here is a log of the transaction:

09/15/2009
1:58:28 AM - Authorize.Net: CIM profile created - XXXXXX
09/15/2009
1:58:28 AM 26 Authorization and capture
ACCEPTED: This transaction has been approved.
Amount: $13.60
AVS response: Y - Address (Street) and five digit ZIP match
CVV match: P - Not Processed
09/15/2009
1:58:29 AM - Authorize.Net: Creating CIM profile failed.
E00039 - A duplicate record with id XXXXXX already exists.
09/15/2009
1:58:29 AM - Authorize.Net: Creating CIM profile failed.
E00039 - A duplicate record with id XXXXXX already exists.
09/15/2009
1:58:29 AM 26 Recurring fee 6 added to order.
09/15/2009
1:58:29 AM 26 Recurring fee 6 added to order.
09/15/2009
1:58:31 AM - Order created through website.

univate’s picture

univate commented

I was just discussing this issue in irc earlier, there is a payment setting that allows you to create a CIM profile on every order. This is probably whats causing those "Authorize.Net: Creating CIM profile failed." errors.

I wonder if you unchecked that option if the errors would go away?

bearstar’s picture

bearstar commented

I have unchecked that setting and will report back later what happens upon renewal.

FYI, the setting is "Always create a CIM profile for securely storing CC info for later use"

Seems like we do want that for the initial order. I'll let you know how it goes...

bearstar’s picture

bearstar commented
StatusFileSize
new Picture 6.png31.47 KB
new Picture 5.png45.02 KB
new Picture 4.png58.07 KB
new Picture 3.png8.45 KB

My latest test order did the following (I had unchecked the create CIM profile setting before this sequence ran)

Order 59 created Order 60 (but there was no automatic attempt to run a charge (not sure if that is a feature or a bug))

When I opened Order 60, I saw the option to Process the Card in the Payment pane (and there was a balance)

When I clicked View Card Details in the Payment pane I got what you see in Picture 3, attached. The number 6 might be a result of my transaction occurring as under the affiliate cookie of user 6. The 6 could also refer to Recurring order #6. An earlier test transaction also had this 6, so I think its the former.

Anyway, when I clicked Process Card in the Payment pane, I got what you see in Picture 4, attached. At the bottom, the CIM information is good. When I checked that option the order processed just fine. Once again, should the transaction run automatically or is this manual processing the way it is meant to work?

Then, I went to look at the order again to see the log comments and noticed at the bottom the check box to process 2 recurring fees! This was a surprise as I just processed the one recurring fee and original one was processed at checkout. See Picture 5.

The other thing that surprised me was when I looked at /admin/store/orders/recurring the original order (59) line item showed no change. There was no indication in the "total" column that anything had been charged. See picture 6. In terms of proper workflow, should the administrator use this "Charge" link or the Process Card button on the new order?
I then Cancelled the recurring fee and lo and behold, a "1" appeared in the Total column, referring to the one recurring order that had been created, I presume.

BTW, the renewal did generate an email confirmation out of Authorize.net, but not out of Ubercart.

I'd appreciate your input on these observations.
Thanks!

bearstar’s picture

bearstar commented

I ran another new oder with the CIM option unchecked to make sure that a CIM profile would still be created and I noticed the same thing as I noted in comment #18: Some things are happening twice: it seems to create the CIM profile and then it tries again. Also, it adds the order twice.

09/16/2009
4:37:08 PM - Authorization and capture
ACCEPTED: This transaction has been approved.
Amount: $13.60
AVS response: Z - Five digit ZIP matches, Address (Street) does not
CVV match: P - Not Processed
09/16/2009
4:37:09 PM - Authorize.Net: CIM profile created - XXXXXXX
09/16/2009
4:37:09 PM - Authorize.Net: Creating CIM profile failed.
E00039 - A duplicate record with id XXXXXXX already exists.
09/16/2009
4:37:09 PM - Recurring fee 7 added to order.
09/16/2009
4:37:09 PM - Recurring fee 7 added to order.
09/16/2009
4:37:11 PM - Order created through website.

Also, this time, the payment pane is correct. It is the newly generated order that loses the CC information under View Card Details in the payment pane. I'll check tomorrow if it comes up as a "6" again.

univate’s picture

univate commented

I have just committed some further changes to CIM, which may fix your problems:
http://drupal.org/node/454952#comment-2050812

univate’s picture

univate commented

Also its probably best to create separate issues for each issue/bug you come across, rather then just tacking them onto existing issue.

bearstar’s picture

bearstar commented

My issues around brand new orders are now cleared up. I will see what happens upon renewal of my latest test order tomorrow and will report back. Thank you for continuing the advances!

vitis’s picture

vitis commented

subscribing

bearstar’s picture

bearstar commented

The renewal did not trigger. No new order was created after the designated time period.
As requested, I opened a new issue at http://drupal.org/node/581570

UPDATE: This problem seems to been caused by a stuck CRON. After killing the cron, everything ran as expected.

BTW, everything seems to be working fine with this module now, with one minor item noted at http://drupal.org/node/582340

savmac’s picture

savmac commented

subscribing

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.