Elavon - Converge CURL error 56 - TCP connection reset by peer

[DrByte]

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).

[jeking]

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/1...t-by-peer-mean

Is anyone using the payment module successfully?

[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.

[jeking]

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....9#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.

[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? 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.

[DrByte]

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....9#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

The 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.

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).

[jeking]

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.

[DrByte]

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.

[jeking]

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.

[DrByte]

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.