Authorize.Net Webform Module Does Not Support Webform 3.x Yet

Unfortunately, I have not had time to deal with webform's changes yet. If the module and site are mission critical, my advice is to downgrade back to 2.9 webform until I can make a fix for 2.10. I'm trying but I have limited time for free support of this module; paid gigs take precedence. I don't have a timeline yet for 3.x either but that will be a major undertaking.

Bryan

The steps I would follow to uninstall:
1. Disable webform module
2. Un-install module modules
3. Download desired version (webforms can be found at http://drupal.org/node/7404/release )
4. Re install according to instructions.

I am not certain what version of webforms is deemed the 'most compatible', any comment on that?

If you uninstall, yes, all data is lost. If you properly backed up your modules and database before upgrading webform, you could just revert to that by uploading the files and restoring the db table backup. Without those things I don't think uninstalling is a good idea. What version of webform were you using before and what version are you using now?

Giving the issue a new title that's more descriptive.

@reybryand: By going all the way up to 3.17, I'm not sure what I can offer right now, there are major changes to webform in 3.x and I haven't even determined what it will take to get this module up to Webform 3.x. If you want to sponsor development of 3.x compatibility, that would help speed up the process.

Bryan

Sorry, I haven't had time to work on this module this month. The first hurdle is how Webform has the data structured in 3.x. Additionally, there's a new add-on module that allows Additional Processing code to be PHP - could you install that, copy the text from INSTALL.txt over to the now-replaced Additional Processing boxes, and see if there's any improvement or messages?

Attached is a patch that makes authorizenetwebform work with webform 3.

It makes some fairly substantial changes so should be used with caution.

Also - it changes the way mappings are done - and there is no upgrade function written. To use this patch with an existing installation you will need to re-map your fields with the authorizenet fields.

I hope it's useful to others!

jamie

@jmcclelland - thank you so much for this. I'm in the midst of a couple projects right now and can't do much with it yet, but will try to review as time permits. If anyone can test it out & report back their findings, that will help jmcclelland & I move things along.

This patch worked great. There was only one bug I found. If you use fieldsets to organize the fields a bit, Webform 3.x seems to return them in trees. I added some code that at least looks down one level of fieldsets. So here's my updated function:

function authorizenetwebform_translate_keys($submitted,$map) {
  $ret = array();
  reset($submitted);
  
  while(list($k,$v) = each($submitted)) {
    if (is_array($v)) {
      foreach ($v as $key => $value) {
        if (array_key_exists($key, $map)) {
          $ret[$map[$key]] = $value;
        }
      }
    } else {
      if(array_key_exists($k,$map)) {
        $k = $map[$k];
      }
      $ret[$k] = $v;
    }
  }
  return $ret;
}

Otherwise, I guess we'd need some sort of recursive helper function to traverse more levels. That may be best, I guess.

Patch in #13 seems to work OK with one exception.

It returns a drupal error (see attached) in both live and test mode.
HOWEVER, Authorize.net processes it and sends the receipt email.

(Extra code in #15 seems to work OK for fieldsets).

Please help identify source of this error.

Error message for #16

It seems as if it sends the form data to ANet, but then Drupal thinks that the card number was not filled in so throws this error.
However, ANet definitely receives and processes the card info.

Thanks in advance for any help.

stevestaso, That error looks like it's coming from Authorize.net and that the Authorize.net system isn't getting the card information correctly. I was not getting this error in my tests; if I get some time I'll try to take another look at it.

Dandaman,
Looking at my watchdog log, here is a partial from the A.Net response:

Array ( [0] => 3 [1] => 2 [2] => 33 [3] => Credit card number is required. 

This is why I get the error in #17.

However - A.net account shows a valid transaction (Authorization only, not captured). Even sends a receipt out. Hmm...

A.net support said their backend logs show a 1,1,1 response with no errors. Hmm...

Not sure how to troubleshoot this any further, so I downgraded Webform to 6.x-2.10.

I'll keep at it on a dev install.

Suggestions welcome.
Thanks.

stevestaso,

It sounds like there's some sort of issue with your site getting and sending the A.net transaction ID, possibly. In the code, upon validation it sends the full credit card information and only authorizes it. It then returns the Transaction ID and puts that into the form somewhere. Then, upon actual submission pass, it sends back the Transaction ID to A.net with the request to now charge it. It seems like you're having a problem where it does the validate but then never gets to the submit or it tries to submit the whole thing over again or something. I guess those are my thoughts/hints just in case you want to take another crack at getting it working on Webform 3.x.

Yes - that makes sense.
I now suspect there is a problem with the 2nd time it sends it to A.net (submit).
I'll dig a little more.

I think the patch in the second comment of #1159506: Upgrade to D7 should solve this recursion issues noted in comment #15.

Patch #13 works for me. Re-mapping the fields went as expected, transaction processes without errors. I didn't test the function from #15.

What can we do to get this committed and supported? I have a couple sites using this on both D6 and D7 and would love to have the community help share my code and squash bugs. Would it help if I rolled another patch? Did some more testing?

Edit: Also, if you'd like, I'm willing to come in and administrate these new branches if desired.

OK, this is basically some code that we've been using on one site with Webform 3.x for over a year. I haven't fully tested it after pulling out a couple client-specific customizations, but feel free to give it a try.

Love that you have put this up. Do you have some instructions on how to apply the patch? I have an existing form that I need to apply payments thru Authorize.net. Im using Drupal 6 on this installation, will this patch work on Drupal 6?

dtrevino13, for details on how to work with patches, feel free to search around the Internet. If you have checked out the repository via Git, the commend is on the main module's page under the "Version Control" tab. Otherwise, any standard patch application tool should work. I usually use the "patch" command-line tool or the patching option included in my code editor of choice, Eclipse.

Yes, this patch is for Drupal 6. After we get this working, I have another version I have running on Drupal 7, but we'd probably need that later and also get a branch created for D7 as well.

This is fixed thanks to dandaman's patch in #25. I've tested it on the developer a.net site and it worked great. A release will be rolled shortly by authorize.net.

Bryan O'Shea
Obsidian Design