Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Having issues now after updating Webform. Transactions process on my site however when I check authorize.net it doesn't see them anymore or do a settlement, as if the transaction never took place with authorize.net. On top of this when I export the results report all transactions since the update show full CC numbers, CCV codes, etc. Please help as this module is needed and used daily and I have a backlog of transactions that haven't processed.
Comment | File | Size | Author |
---|---|---|---|
#25 | 897090-24-authorizenetwebform-webform-3.x.patch | 17.9 KB | dandaman |
#17 | Drupal-error.png | 6.51 KB | stevestaso |
#13 | authorizenetwebform.webform.3.patch | 12.36 KB | jmcclelland |
Comments
Comment #1
reybryand CreditAttribution: reybryand commentedBump..
Anyone? Anyone?
Comment #2
obsidiandesign CreditAttribution: obsidiandesign commentedUnfortunately, 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
Comment #3
reybryand CreditAttribution: reybryand commentedI have never had to complete a downgrade. Are there any particular steps I need to take to do so?
Comment #4
eyenology CreditAttribution: eyenology commentedThe 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?
Comment #5
reybryand CreditAttribution: reybryand commentedIf I disable it and uninstall will I lose the forms that I created and have to recreate them?
Comment #6
obsidiandesign CreditAttribution: obsidiandesign commentedIf 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?
Comment #7
reybryand CreditAttribution: reybryand commentedFrom what I am looking at I was on 2.05 and upgraded straight to 3.01 and now upto 3.17
I don't know what to do, lol I am freaking out...
Comment #8
obsidiandesign CreditAttribution: obsidiandesign commentedGiving 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
Comment #9
reybryand CreditAttribution: reybryand commentedWhat is required to be a sponsor? I am more then willing to pay/donate. :)
Comment #10
reybryand CreditAttribution: reybryand commentedbump...
Comment #11
reybryand CreditAttribution: reybryand commentedSo nothing? Ziltch? No reply?
Comment #12
obsidiandesign CreditAttribution: obsidiandesign commentedSorry, 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?
Comment #13
jmcclelland CreditAttribution: jmcclelland commentedAttached 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
Comment #14
obsidiandesign CreditAttribution: obsidiandesign commented@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.
Comment #15
dandaman CreditAttribution: dandaman commentedThis 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:
Otherwise, I guess we'd need some sort of recursive helper function to traverse more levels. That may be best, I guess.
Comment #16
stevestaso CreditAttribution: stevestaso commentedPatch 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.
Comment #17
stevestaso CreditAttribution: stevestaso commentedError 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.
Comment #18
dandaman CreditAttribution: dandaman commentedstevestaso, 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.
Comment #19
stevestaso CreditAttribution: stevestaso commentedDandaman,
Looking at my watchdog log, here is a partial from the A.Net response:
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.
Comment #20
dandaman CreditAttribution: dandaman commentedstevestaso,
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.
Comment #21
stevestaso CreditAttribution: stevestaso commentedYes - 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.
Comment #22
theunraveler CreditAttribution: theunraveler commentedI think the patch in the second comment of #1159506: Upgrade to D7 should solve this recursion issues noted in comment #15.
Comment #23
dzepol CreditAttribution: dzepol commentedPatch #13 works for me. Re-mapping the fields went as expected, transaction processes without errors. I didn't test the function from #15.
Comment #24
dandaman CreditAttribution: dandaman commentedWhat 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.
Comment #25
dandaman CreditAttribution: dandaman commentedOK, 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.
Comment #26
dtrevino15 CreditAttribution: dtrevino15 commentedLove 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?
Comment #27
dandaman CreditAttribution: dandaman commenteddtrevino13, 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.
Comment #28
obsidiandesign CreditAttribution: obsidiandesign commentedThis 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
Comment #29
obsidiandesign CreditAttribution: obsidiandesign commented