My client recently changes processors to Elavon. I found and installed the module, but orders cannot be placed. Error log (gotta love those!!) says:

PHP Notice: Converge communications failure. 56 - TCP connection reset by peer in /home/outsid19/public_html/includes/modules/payment/elavon_converge.php on line 656

Hmmm.

PHP Version?
CURL version? (see Server Info page in Admin Tools menu)
OpenSSL version? (see Server Info page in Admin Tools menu)

PHP: 5.6.25
CURL version: 7.29.0
OpenSSL version: 1.0.1e-fips 11 Feb 2013

I've tried to simulate all kinds of bad situations to trigger teh problem, but can't.

Most articles suggest firewall issues on your site. Or outdated PHP/CURL/OpenSSL.

While the curltester script doesn't "know" about Elavon, it does test a dozen other common destinations. Give it a try and report back: /extras/curltester.php

curltester.php results below.

I see there are newer versions of cURL but it wasn't clear if 7.29 was still supported or not.
OpenSSL looks to be current.

Are there firewall ports that I need to confirm are open?

Powered by Zen Cart :: The Art of E-Commerce
CURL Test Page

This page is intended for testing CURL behaviour. You should be accessing this page via CURLTESTER.PHP running on YOUR server.

You submitted the following fields and data:

Array
(
    [field1] => This is a test
    [statuskey] => ready
)
Data validation

Good
Other Info

Your server IP address is: 209.133.199.173. 
Your system identifies itself as: Zen Cart(tm) - CURL TEST
Copyright © 2003 - 2016 Zen Ventures, LLC - Authors of Zen Cart™
Array
(
    [url] => "http://www.zen-cart.com/testcurl.php"
    [content_type] => text/html; charset=iso-8859-1
    [http_code] => 200
    [header_size] => 177
    [request_size] => 212
    [filetime] => -1
    [ssl_verify_result] => 0
    [redirect_count] => 0
    [total_time] => 0.208437
    [namelookup_time] => 0.124758
    [connect_time] => 0.163516
    [pretransfer_time] => 0.163618
    [size_upload] => 37
    [size_download] => 6463
    [speed_download] => 31006
    [speed_upload] => 177
    [download_content_length] => 6463
    [upload_content_length] => 37
    [starttransfer_time] => 0.208376
    [redirect_time] => 0
    [redirect_url] => 
    [primary_ip] => 104.236.245.70
    [certinfo] => Array
        (
        )

    [primary_port] => 80
    [local_ip] => 209.133.199.173
    [local_port] => 46616
)

jim,
i think your output is not correct.

the output of yoursite.com/extras/curltester.php should look something like the attached screenshot.

best.

It's Zen Cart 1.5.3. I replaced with the curltest.php and now get something like yours.

Testing communications to various destinations. This is a simple diagnostic to determine whether your server can connect to common destinations.
For advanced "details" mode, add ?details=on to the URL.

(Another resource you may find useful for testing your server's overall customer-facing SSL configuration: https://www.ssllabs.com/ssltest/index.html )

Connecting to Zen Cart Version Server (http) ...
GOOD: CURL Connection successful.

Connecting to Zen Cart Version Server (https) ...
GOOD: CURL Connection successful.

Connecting to Zen Cart Support Server (https) ...
GOOD: CURL Connection successful.

Connecting to USPS (port 80)...
GOOD: CURL Connection successful.

Connecting to USPS Test/Staging/Sandbox Server (port 80)...
GOOD: CURL Connection successful.

Connecting to UPS (port 80)...
GOOD: CURL Connection successful.

GOOD: Socket established

Connecting to UPSXML (SSL) (wwwcie.ups.com) ...
GOOD: CURL Connection successful.

Connecting to UPSXML (SSL) (https://www.ups.com) ...
GOOD: CURL Connection successful.

Connecting to UPSXML (SSL) (onlinetools.ups.com) ...
GOOD: CURL Connection successful.

Connecting to FedEx (port 80)...
GOOD: Socket established

Connecting to Canada Post REST API (SSL) ...
GOOD: CURL Connection successful.

Connecting to PayPal IPN (port 443)...
GOOD: Socket established

GOOD: CURL Connection successful.

Connecting to PayPal IPN (port 443) Sandbox ...
GOOD: Socket established

GOOD: CURL Connection successful.

Connecting to PayPal Express/Pro Server ...
GOOD: CURL Connection successful.

Connecting to PayPal Express/Pro Sandbox ...
GOOD: CURL Connection successful.

Connecting to PayPal Payflowpro Server ...
GOOD: CURL Connection successful.

Connecting to Cardinal Commerce 3D-Secure Server ...
GOOD: CURL Connection successful.

Connecting to AuthorizeNet Production Server ...
GOOD: CURL Connection successful.

Connecting to AuthorizeNet Developer/Sandbox Server ...
GOOD: CURL Connection successful.

Connecting to First Data GGe4 server (SSL)...
GOOD: CURL Connection successful.

Connecting to Payeezy Processing Server...
GOOD: CURL Connection successful.

Connecting to Payeezy Sandbox Server...
GOOD: CURL Connection successful.

Testing completed. See results above.

It uses port 443, just like every other HTTPS secure communication. No special ports required.

I suppose you might be passing invalid or incorrect parameters for user/key credentials, and so it's finding a malformed request, and rejecting it outright ("bye") instead of giving a proper "hi, sorry: error, bye".

Or perhaps your Elavon account is configured to limit transactions from only a certain IP, and your server is not in that list.

The Elavon logging shows what looks to be a full array out.

Sent to Converge Elavon VirtualMerchant gateway: Array
(
[ssl_card_number] => *******6897
[ssl_exp_date] => ***8
[ssl_cvv2cvc2] => ***5
[ssl_cvv2cvc2_indicator] => 1
[ssl_amount] => 15.15
[ssl_transaction_type] => ccsale
[ssl_invoice_number] => 234-uYzOcW
[ssl_show_form] => false
[ssl_result_format] => ascii
[ssl_get_token] => N
[ssl_add_token] => N
[ssl_company] =>
[ssl_first_name] => James
further details not posted here......

The response back is somewhat lacking.

Response Code: .
Response Text:

Results Received back from Elavon Converge: Array
(
[] =>
)

I'm confirming details with the client and Elavon.

deleted

jeking:

The response back is somewhat lacking.

Response Code: .
Response Text:

Results Received back from Elavon Converge: Array
(
[] =>
)
Ya, when the connection fails or no response is received, the above is all you'll get.

Under normal circumstances, if communications is working fine, then you'll get a meaningful response (success/error, with details about why).

I'm still struggling with this one. Spoke to Evalon support who suggested two other urls but both result in the same error.

It seems to be an issue on their end:
http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean

Is anyone using the payment module successfully?

Around line 115 of curltester.php you could add these:```
echo 'Connecting to Elavon Server...<br>';
doCurlTest('https://www.myvirtualmerchant.com/VirtualMerchant/process.do');

echo 'Connecting to Elavon Sandbox Server...<br>';
doCurlTest('https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process.do');

It'd be interesting to see whether the basic connection attempt gets a different result from the authenticated transaction payment request attempt does.

DrByte:

Around line 115 of curltester.php you could add these:```
echo 'Connecting to Elavon Server...<br>';
doCurlTest('https://www.myvirtualmerchant.com/VirtualMerchant/process.do');

echo 'Connecting to Elavon Sandbox Server...<br>';
doCurlTest('https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process.do');

> 
> It'd be interesting to see whether the basic connection attempt gets a different result from the authenticated transaction payment request attempt does.

Interesting suggestion.  I won't post the full response, but:

Connecting to Elavon Server...
GOOD: CURL Connection successful.

Connecting to Elavon Sandbox Server...
GOOD: CURL Connection successful.

The last reply I got from Evalon support was:
Thank you for your email  Is the code you are using to generate the post to Converge? Looking at the values [I sent the logs as shown <https://www.zen-cart.com/showthread.php?220991-Elavon-Converge-CURL-error-56-TCP-connection-reset-by-peer&p=1318269#post1318269]>, everything appears to be correct, so it would seem like there is an error with you site posting this data. We would really have to see the actual value pairs your posting to be able to advise much more, but generally that reset message means Converge is unable to interpret what it’s receiving. 

I don't know how to capture the full post data, as they are asking.

Evalon believes something about the server is blocking. I've asked them, waiting for a reply, but asking here to.

What port or Apache settings or functions could be blocked? There are several other Zen Cart sites on this server and no payment issues. None are using Evalon though, so I'm wondering if there is something about this module that might be different.

jeking:

The last reply I got from Evalon support was:
Thank you for your email Is the code you are using to generate the post to Converge? Looking at the values [I sent the logs as shown https://www.zen-cart.com/showthread.php?220991-Elavon-Converge-CURL-error-56-TCP-connection-reset-by-peer&p=1318269#post1318269], everything appears to be correct, so it would seem like there is an error with you site posting this data. We would really have to see the actual value pairs your posting to be able to advise much moreThe logs are reporting exactly the pairs that are being sent, less some obfuscation for sensitive data that should never be recorded in logs ... and which shouldn't be required for their tech teams to understand.

jeking:

Evalon believes something about the server is blocking. I've asked them, waiting for a reply, but asking here to.

What port or Apache settings or functions could be blocked?
It's such a basic call that there's little that could get in the way.
It relies on your server making a CURL call to an HTTPS URL. That's it.

And, since the basic connection attempt (without a transaction behind it) is fine, that suggests to me that maybe your auth credentials aren't transmitting properly (or they're not saved properly, so it's pulling bad data from your config settings and transmitting that).

DrByte:

It's such a basic call that there's little that could get in the way.
It relies on your server making a CURL call to an HTTPS URL. That's it.

And, since the basic connection attempt (without a transaction behind it) is fine, that suggests to me that maybe your auth credentials aren't transmitting properly (or they're not saved properly, so it's pulling bad data from your config settings and transmitting that).

I've confirmed the credentials twice. It seems like a simple process, which is why I have a hard time understanding what could possible be blocked. Thank you for the explanation.

I don't expect I'll hear from them again until Monday.

I'm a bit uncomfortable with suggesting this, but it's worth exploring, if only to find out what happens when trying it.

In the elavon module file, at line 638 you have this:```
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $endpoint . '?' . http_build_query($payload));
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

Change it to this, and see what happens:```
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $endpoint);
    curl_setopt($ch, CURLOPT_POST, true);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $payload);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

I ran into several problems using that approach with Elavon, but it'd be interesting to see what it does for your situation.

Interesting. Same array data is in the outgoing log, but I now do get a response.

Sep-17-2016 01:09:50

Response Code: .
Response Text:

Results Received back from Elavon Converge: Array
(
[] =>
[<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">] =>
[<html>] =>
[<head>] =>
[<style type] => "text/css">
[ BODY, TD, INPUT, SELECT, TEXTAREA, BUTTON, .normal {font-family:arial,helvetica,sans-serif; font-size:10pt; font-weight:normal; }] =>
[ .small {font-size: 10pt}] =>
[ .medium {font-size: 14pt}] =>
[ .large {font-size: 18pt}] =>
[</style>] =>
[<!--4.2 Back / Cancel Button - S -->] =>
[<script language] => "javascript" type
[function backToProcess(){ ] =>
[document.processForm.action] => "process.do";
[document.processForm.method] => "post";
[document.processForm.dispatchMethod.value ] => 'processBackTransaction';
[document.processForm.submit(); ] =>
[ }] =>
[</script>] =>
[<!--4.2 Back / Cancel Button - E -->] =>
[</head>] =>
[ ] =>
[<body bgcolor] => "#FFFFFF" text
[<br/>] =>
[<p align] => "center">
[</p>] =>
[<form name] => "frmMenu" action
[ <table width] => "80%" cellspacing
[ <tr bgcolor] => '#294984'>
[ <td height] => "25" colspan
[ </tr>] =>
[ <tr>] =>
[ <td>] =>
[ ] =>
[ <table>] =>
[ <tr><td nowrap>Error Code : </td>] =>
[ <td><span id] => "errorCode">4000</span></td>
[ <tr><td>Error Name : </td>] =>
[ <td>VID Not Supplied</td>] =>
[ <tr><td>Error Message : </td>] =>
[ <td>The VirtualMerchant ID was not supplied in the authorization request.</td>] =>
[ ] =>
[ </table>] =>
[ </td>] =>
[ </table>] =>
[<!-- ] => [ Error Code : 4000<br>] => [ Error Message : The VirtualMerchant ID was not supplied in the authorization request.] => [-->] =>
[ ] =>
[<input type] => "hidden" name
[</form>] =>
[</body>] =>
[</html>] =>
)

The obvious conclusion is the Merchant ID is wrong, but is says 'not supplied'. It's clearly in the settings of the module. I've verified it with my customer twice and used it when I called Elavon support. Gotta be the right value.

Ya, I think that's the sort of thing I was getting too.
It's not parsing the received POST data properly when sent that way, which is why I wrote it the way it was originally.

It'd be better to hear what their tech support are saying for attempted transactions using that account. They should be able to inspect all incoming requests, particularly when they result in an error, and tell you exactly why their system is either complaining or failing to respond. Or whether they're seeing you connect at all.