After installing and testing this module it appears that it stores the cc information on my website. Am I incorrect in thinking it is better to not store this info, but to pass it to authorize.net and purge it? Again, this is new to me so I may be missing something obvious.

Comments

dzepol’s picture

Yes, I've installed the latest version and tested it. Everything seemed to work fine but when I went to check on the results it showed the full CC#, Expire Date, and 3 digit code.

obsidiandesign’s picture

Assigned: Unassigned » obsidiandesign

Just so I can investigate, what webform version are you using? And, does the transaction go through over at Authorize.net?

Bryan O'Shea
Obsidian Design

eyenology’s picture

I am using version 1.2. I am just doing some initial testing, so I haven't sent anything through to authorize.net (perhaps that is my problem) but when I submit the form it saves everything I have entered, including CC info, etc.

obsidiandesign’s picture

Not the version of this module, the version of Webform. I'm wondering if there was a change along the line that is rendering the code in 1.2 of this module useless.

eyenology’s picture

Ahh, that does make sense. I am using version 6.x-2.9 of webform. I see there have been some revisions. I am able to upgrade and test if that would be helpful, just let me know.

obsidiandesign’s picture

Thanks, that gives me a starting point. It will be at least a day or two before I can even begin to look into this, just FYI.

Bryan O'Shea
Obsidian Design

dzepol’s picture

I am also using version 6.x-2.9 of webform and my charges do go through on Authorize.net.

obsidiandesign’s picture

Thanks for the additional info - it means the problem is limited to the part that cancels out the card number in the submission. Thanks for getting back to me so quickly!

Bryan O'Shea
Obsidian Design

reybryand’s picture

Having similar issues now after updating Webform. Transactions process 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.

eyenology’s picture

Any ideas on this? Is there a version of webform that I can downgrade to that will fix this?

eyenology’s picture

I've done some more tinkering. I now have this running through a test account and have a little more to report. It verifies with authorize.net and appropriate emails are sent, however it reports an error:

"There was an error processing your credit card: (TESTMODE) A valid referenced transaction ID is required.. If the error persists, please try another card."

I have added the hidden transaction ID component, but it doesn't seem to communicate it correctly. FWIW in the confirmation email Trans ID is reported as "0"

eyenology’s picture

Ok, a little more updating. I am starting to think there may be a conflict with another module with this. I have tried versions 2.8, 2.9, 2.10 of webform and all still show the full CC number under 'submissions'. Also downgraded to version 1.1 of this module, and still not x'ing it out.

Am I correct in assuming that it should be X'd out in the 'submissions'?

Thanks

eyenology’s picture

Another thought: I wonder if both the Transaction ID error and this error are a result of running in test mode. It seems that in Test Mode the Transaction ID is always outputted as 0. Could the lack of X's be tied to that some how as well?

obsidiandesign’s picture

@eyenology - thanks for testing more. You cannot test this in Test Mode because the transaction ID is always 0. If you are only using test mode, then yes, there will not be a transaction ID. I'm not 100% sure that this would cause the display of the CC #, but it would make sense because it has not received confirmation from Authorize.net that it was processed.

eyenology’s picture

@obsidian - thanks for the response. Once I get the access to clients authorize.net account I will test again. If it works out I'd be happy to take a crack at adding this to the documentation for this module.

eyenology’s picture

Ok, the module works properly in clearing cc info, as long as you are not running in test mode. I currently have a test account with authorize.net that was running in test mode. Once I left test mode module worked as expected. The documentation is out there with authorize.net, but would be nice if it was here.

dzepol’s picture

Well, I'm still unclear. I'm not running in Test Mode on authorize.net. In the Authorize.net Payment Webform, I'm using the secure.authorize.net post URL and I have the transaction ID hidden field. When I submit an order it appears on Authorize.net under unsettled transactions with all the right information including transaction ID. But, the results still show the full CC# and it does not show the transaction ID in the results it is blank (even though on Authorize.net it is there), any ideas?

eyenology’s picture

are you using version 1.2 of this module? scratch that, you say in #1 that you have updated to newest version. I know I ran into issues with "scanning" the install and that got me into trouble at first. Did you add the add'l lines of code into the 'additional validation' and 'additional processing' portion of the webform? (Under Webform Advanced Settings)

obsidiandesign’s picture

One thing to try - the code for Additional Validation is very close (but has some differences) to the Additional Processing code. Copy both fields from INSTALL.txt again and see if there's an improvement.

dzepol’s picture

I'll try these out and let you know! Thanks

dzepol’s picture

After struggling with this for sometime... I finally figured out why this was happening! The cause of it showing the CC info for me was due to me having the payment information in a fieldset, probably related to this issue Not compatible with fieldsets.

Once I removed that, the CC info is properly xx out.

obsidiandesign’s picture

Category: support » bug
Status: Active » Fixed

This has been fixed both in the 6.x-2.x and 7.x-1.x branches. I have not created a release yet but the next -dev release made by Drupal will have these changes, with a full release to follow.

Bryan O'Shea
Obsidian Design

Status: Fixed » Closed (fixed)

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