|
Rafe Martin
|
August 28, 2013 at 4:25 pm
I’ve got Authorize.net AIM method configured but don’t have an SSL installed yet. Just doing some testing first. I’m completing registrations on the front end, but don’t get any email confirmations and the credit card is not being charged either. Payments show as incomplete, but I’m using a valid card and auth.net is live.
Is this happening because my SSL isn’t installed yet? Is the component trying to detect an SSL connection before transmitting info to authorize.net?
-
This topic was modified 11 years, 3 months ago by
 Rafe Martin.
|
|
Josh
|
August 28, 2013 at 9:01 pm
Hi Rafe,
I don’t believe Authnet checks for SSL. The first thing I would advise checking is to see if the payment was posted in the Authnet account. Then it may help to verify that a payment response is getting sent back from Authorize.net to your server by checking the log file in /wp-content/uploads/espresso/logs.
|
|
Rafe Martin
|
August 30, 2013 at 8:45 am
In viewing the log file, I see a test transaction that received a response from authorize.net and one other successful transaction from several days ago – but I have tried several others since those and they don’t appear at all in the log. It’s as if the request is not getting sent to authorize.net. Would this have anything to so with moving from a temporary url to the production url?
|
|
Josh
|
August 30, 2013 at 9:12 am
Yes it would. When you moved from the temporary URL to the production URL were the URL’s and file path settings stored in the database (specifically the WP options table) updated?
|
|
Rafe Martin
|
August 30, 2013 at 10:08 am
They were updated after moving. I deactivated the payment method and then activated it again and now it looks like we’re transmitting info to authorize.net but the payments were declined. I called their tech support and they told me that the card code verification was failing with the card I am using. The conclusion that we come to is that the app is not sending the card code (3-digit security code), or it’s sending incorrect information in the card code field. To narrow it down further, we disabled card code verification on the authorize.net end and the transaction was approved. So, the bug as far as we can tell is in the card code data that is transmitted to authorize.net
|
|
Josh
|
August 30, 2013 at 10:49 am
Not likely. If there was a bug that was changing the card data sent, how would the gateway work for the thousands of other users of Authorize.net?
|
|
Rafe Martin
|
August 30, 2013 at 10:53 am
I was suggesting a bug resulting from moving to production, or a configuration issue if you know of any.
|
|
Josh
|
August 30, 2013 at 3:54 pm
If you look in the aim gateway’s aim_ipn.php file just below where it says:
//start transaction
you’ll note that the ccv_code is passed to Authorize.net:
$transaction->card_code = $_POST['ccv_code'];
While I do not know why this would cause a failed transaction by enabling the card code validation feature on the Authnet account side, this comment on a related thread in the authorize.net developer community forums seems to indicate that it’s not a good idea to enable the validation feature:
http://community.developer.authorize.net/t5/Integration-and-Testing/CVV-Not-working/m-p/2811#M2529
|
