search

activemerchant / active_merchant

Active Merchant is a simple payment abstraction library extracted from Shopify. The aim of the project is to feel natural to Ruby users and to abstract as many parts as possible away from the user to offer a consistent interface across all supported gateways.
http://activemerchant.org
MIT License
4.55k stars 2.5k forks source link

Upgraded to 1.46.0, now have connection issues #1570

Closed sjf-control closed 9 years ago

sjf-control commented 9 years ago

Because my cc processor has now forced TLSv1 or higher protocols, I've updated my configuration. My current configuration is:

Rails: 3.2.21 ruby: 2.1.5p273 ActiveMerchant: 1.46.0 Running in development mode on OS X 10.10.2 (updated) Gateway: AuthorizeNet CC processor: eProcessingNetwork gateway URL (both test and live): https://www.eProcessingNetwork.com/cgi-bin/an/order.pl

My problem is that when processing a transaction (either test or live), other than success=false, I am getting no indication of what the problem is. The results returned from the gateway.authorize call is:

params: action: AUTH_ONLY response_code: response_reason_code: response_reason_text: '' avs_result_code: transaction_id: card_code: authorization_code: cardholder_authentication_code: account_number: message: '' success: false test: true authorization: "#" fraud_review: false error_code: avs_result: code: message: street_match: postal_match: cvv_result: code: message:

Now if I change the URL to the actual Authorize.net address, it returns an error indicating invalid user information. That makes sense since I don't have an account there. But that indicates that it is getting out to the internet to the URL defined.

I'm using the same credentials and URLs as the original software (ActiveMerchant v1.28.0). Note that the old software processes transactions and returns a SSLv3 error message, so the accounts are still there.

Working with the eProcesisngNetwork tech support is not much help, as they don't see anything connecting on their end.

Since NO error information is returned, I'm at a bit of a loss as to how to proceed. What would make ActiveMerchant return a failed transaction without error info? How can I troubleshoot this? Is there a way to enable or access additional info on what went wrong?

I'm stuck. Thanks for any help

ntalbott commented 9 years ago

@sjf-control do you have a sandbox account at the gateway? If so, I'd try running the AM remote tests for it. If those fail, you can set the DEBUG_ACTIVE_MERCHANT environment variable to 1 and re-run to see a full on-wire dump of the conversation.

sjf-control commented 9 years ago

I have access to a test account (login and password) that processes dummy transactions, if that's what you mean.

I've never run tests on a gem before. Is there somewhere that describes how to do that?

Are you referring to active_merchant/test/remote/gateways/remote_authorize_net_test.rb?

Thanks.

ntalbott commented 9 years ago

@sjf-control your best bet to run the tests is to clone the repo vs. trying to do it out of the gem.

And yes, that's the test I'd recommend trying, via ruby -Itest test/remote/gateways/remote_authorize_net_test.rb.

ntalbott commented 9 years ago

Also, FWIW, that Authorize.Net adapter runs a lot of live transactions at both Shopify and Spreedly (http://gatewayindex.spreedly.com/gateways/authorize_net), so I'm pretty confident this isn't an ActiveMerchant bug.

j-mutter commented 9 years ago

Agreed. Authorize.Net gets a ton of volume from Shopify stores. It sounds like this Authorize.Net emulator might be the culprit, so I'm curious to see what the remote tests say when they're pointed at it.

sjf-control commented 9 years ago

Yes, I never thought it was an issue with Authorize.net. It is indeed a problem with the simulator. (Or my talking to it.)

ntalbott, thanks VERY much for your suggestion. I am now able to see exactly what is being sent, and what is received. I've updated the server to disable insecure protocols and the site now has an A+ security rating from SSLLabs.com.

As a sanity check, it appears that the AIM protocol is being used to communicate with the provider's server. I downloaded "Merchant Web Services API Advanced Integration Method (AIM)" from the Authorize.net site, and what I am sending looks pristine with one exception. The transaction key (called a restrict key by eProcessingNetwork) is only 15 characters instead of 16. I tried generating new values for the key on the ePN site, but they are all 15 characters long, and don't appear to be manually editable.

I notified ePN of this discrepancy on Sunday, but haven't heard anything back.

The response I am getting back from the transaction is ... "Invalid Account" ePN claims there must be something wrong with my site, but I'm at a loss to figure out what it could be, since the SSL connection is successfully completed, And the transaction contents appears clean.

I can manually enter a transaction to my account on the ePN website, so the account is not blocked.

Anybody else ever have (or currently having) an issues with eProcessingNetwork should contact me.

Oh, by the way, when running the entire test routine against their server, each transaction failed with the same "Invalid Account" response.

ntalbott commented 9 years ago

@sjf-control this sounds like a credentialing issue on the gateway side. I'm going to close it out as I think AM is not part of the problem.