|
Zachary Hoffman
|
November 28, 2012 at 7:20 pm
I have set up Authorize.net AIM payment gateway. I go through the registration process and get a confirmation message that says Payment Completed. The registration shows up in the attendees list. But when I go to Auth.net the transaction does not show up.
Account Uses Authorize.net development Server
All these payment settings are UNCHECKED.
Submit a Test Transaction
Force HTTPS on Return URL
Display a Form Header
In General Settings > Optional event Settings
Default Payment Status (this value will be automatically filled in for each person’s payment status, until payment is made, for each event): is set to COMPLETED.
Authorize.net API and Transaction key appear to be correct.
Any advice on how to make sure payments go through?
|
|
Josh
|
November 28, 2012 at 8:24 pm
Hi Zachary,
There are two settings that I would recommend changing:
1) Default payment status should be set to Incomplete.
2) Since the account is using the Authnet development server, it should be set to send a test transaction. When you’re using the live Authnet server, then you can uncheck the Submit a test transaction box in the Payment settings.
|
|
Zachary Hoffman
|
November 28, 2012 at 8:45 pm
Hi Josh.
1) Default payment status should be set to Incomplete.
I had this set to incomplete before and had the same problem.
2) Since the account is using the Authnet development server, it should be set to send a test transaction. When you’re using the live Authnet server, then you can uncheck the Submit a test transaction box in the Payment settings.
The account is NOT using the development server. That option is unchecked. I set up an event with a $1 price and want to run a live transaction. None of the transactions I sent showed up in authorize.net
|
|
Josh
|
November 28, 2012 at 9:23 pm
I’m sorry. I misunderstood what you meant when you wrote this in the original post:
Account Uses Authorize.net development Server
Either way, are there any error messages that appear when you hit the submit payment button below the credit card form?
|
|
Zachary Hoffman
|
November 28, 2012 at 9:45 pm
Yeah, sorry. I pasted it in the wrong place, but the dev server is off. I get no error messages when I complete the process and get a confirmation page with the following. Anything you can do to help would be greatly appreciated. We are launching a site tonight and this is one of the final sticking points. None of the documentation I’ve seen has much info on activating the Auth.net gateway. It just says to fill out the payment settings with no detail.
Payment Overview
Class/Event: test event
Primary Registrant: Zachary Hoffman
Payment Date:
Amount Paid/Owed: $1.00
Payment Status: Completed
Registration ID: 12-50b6e71f70d60
|
|
Zachary Hoffman
|
November 28, 2012 at 10:29 pm
Don’t know if this helps or not,but when I look at the Attendee records of the transactions I tried to run it says
Transaction ID: N/A
Date Paid: N/A
Ticket Prices
Payment Status: Completed [ View/Edit Payment ]
Transaction ID: N/A
Date Paid: N/A
Total Amount Owing: $1.00
Total Amount Paid to Date: $0.00
|
|
Josh
|
November 29, 2012 at 12:44 am
Hi Zachary,
I kind of snooped around and it looks like there’s some JavaScript shenanigans going on in the custom.js of the theme. The JavaScript errors on the payment page could possibly mess something up, and it would be worth your while to fix them. It looked mostly like the common $ in place of jQuery error, which is a simple fix. I’ll usually apply one of the ideas discussed here in situations like this one.
Besides that, there really isn’t any documentation for how to integrate Authnet AIM with Event Espresso, since the integration was already done, it’s usually plug your credentials in and go.
You might try deactivating some other plugins to rule out any conflicts. You could also run a test with the AuthSIM method, since that will take the payment on Authnet’s servers, which may help narrow down the issue.
One final recommendation: You could try updating to the latest version of Event Espresso, there are a few little bug fixes in the 3.1.28.5 version.
|
|
Seth Shoultes
|
November 29, 2012 at 10:13 am
In addition to what Josh stated above, you may want to check the server error logs to see if there are any underlying issues. It might also be helpful to turn on debugging in the wp-config.php and “Use full logging?” in the WP Admin > Event Espresso > General Settings > Optional Event Settings.
|
|
Zachary Hoffman
|
November 29, 2012 at 10:33 am
This error did show up before. But no errors are coming through now.
“[28-Nov-2012 17:27:02] PHP Fatal error: Cannot redeclare class AuthorizeNetException in /home/web11/public_html/wp-content/plugins/event-espresso/gateways/aim/AuthorizeNet.php on line 24”
|
|
Josh
|
November 29, 2012 at 11:02 am
Hi Zachary,
That would indicate that there is another plugin that had declared that same class. Have you tried deactivating any other plugins that have an Authnet option?
We’re working on a update to the authnet gateway that will have all the classes prefixed in order to prevent errors like this from happening.
|
|
Zachary Hoffman
|
November 29, 2012 at 11:49 am
OK we were finally able to get a transaction to go through successfully. We’re pretty sure it’s a PHP class conflict with the Gravity Forms Auth.net plugin. We are using Gravity Forms + the Auth.net add on to process donations on another part of the site and after we resolved those class conflicts it seems to work.
So, yes it sounds like updating the auth.net gateway and having separate classes should prevent this from happening.
Thanks for taking the time to help get this resolved!
|
|
Zachary Hoffman
|
November 29, 2012 at 11:53 am
I think this also means we should not update the EE plugin until you prefix all of their auth.net classes to avoid conflicts like this. So, please let us know if you do make that update.
|
|
Seth Shoultes
|
November 29, 2012 at 12:38 pm
Thanks for the update. It is very common for developers to use the same gateway files or SDKs for their projects. Event Espresso and Gravity Forms should both know better not to leave the default class names 🙂
I will try to make sure this is fixed in the next update.
Thanks for your patience!
|
