I'm getting an error ('Payment failed: User authentication failed') when sending a transaction to Verisign. The only answer I've gotten so far is that our login information must be wrong, but it's been confirmed to be correct. We've now gone to Verisign and had them watch their systems while we try a transaction and it's not even getting to them. I have a test script that uses the pfpro binary (via the php exec function) that connects fine and gets a valid result in test mode. Does aMember use that function as well, or does it require that the pfpro extensions be compiled into php? Since we're currently in the evaluation phase, our entire installation is encrypted so I can't dig into the code to check it out. I'm going nuts here and wasting way too much time trying to get this thing up and kicking. Thanks, Loren
No dollar signs or ampersands. We do have exclamation points, though. Alex, what about the original question? Is it implemented through using the binary and the exec function or does it need to be compiled into php?
Sorry, did not mention your question. Of course, it uses binary via exec. Compiliing into PHP is not an option on 99% webhostings.
Yeah - I guess that's true. We run our own servers so I don't usually think in terms of externally hosted solutions. Then I'm still confused as to why this doesn't work. Using a test script from Verisign, I can successfully execute a transaction to both their test & live systems. I can change the card number & login information and generate the expected error messages. I've also used 2 different test numbers (4111111111111111 & 4222222222222). Using aMember with the same login & credit card information (copied & pasted from a working script) and pointed at the same SDK, I get the authentication error. Any ideas? Thanks, Loren
Loren, it is not a problem we could solve here in the public forum. Here is our helpdesk: https://www.amember.com/support/
Thanks, Alex, but we got it to work. I was so frustrated by not being able to get into the code to debug in the demo version that we bought a license. (Don't think of that as a new business model, we were planning to buy it anyway ) The problem turned out to be that our password was being messed up in the run_transaction function in payflow_pro.inc.php when the command string gets urlencoded. It was changing the exclamation points to "%21". I had to add a special function after that point to get our password back to the right thing. Once that was in place, it went through fine. Thanks, Loren
I am now having this EXACT same problem when trying transactions through Pay Flow Pro, can someone please clear up what the solution is and what I ahve to do? Thanks!
My quick and dirty fix As I said, our verisign password has exclamation points in it and they were getting changed into %21 in the string that was being sent to verisign. This shouldn't be an issue if your password has no special characters in it. Here's what I did: In the amember/plugins/payment/payflow_pro/payflow_pro.inc.php file, find the run_transaction function. Immediately after the function run_transaction($vars){ line, add the following: Code: function fix_password($var){ return str_replace("%21", "!", $var); } Obviously, your values in that line may vary based on which characters in you password are getting munged. Then, farther down in that function where it builds the $exec variable, find the line that says $exec .= '" 2>&1';. Immediately after that add: Code: $exec = fix_password($exec); That's it. It's not really the best way of doing it. I would have preferred to write a more generic function which would work for any (or at least most) character possibilities, but I just needed a quick fix. I'll probably lose sleep over it and redo it eventually but I need this thing up and running pretty soon, so I went the easy route. Hope this helps, Loren
We will fix that in next version of aMember of course. jbubb, you may contact us via helpdesk to get immediate solution. Do you have any characters in password except numbers and letters?