Paymentech (aka VersaPay, aka Orbital)

Mike D:

1. I changed some setting somewhere a couple nights ago and now when I try to test the module in test mode I don't get any fields at checkout. I can insert billing address, but I don't get the CC# field, expiry, CVV code, any of that. Not in testing mode, anyway. In production mode or with other payment modules the fields still show up.It's the code in the selection() function that generates those fields to be displayed by your template.

Mike D:

2. Is anybody aware of what part of the code actually checks the response obtained from the processor?
   In before_process() these lines:```
   $authorize = curl_exec($ch);
   $commError = curl_error($ch);

The $authorize variable will contain the entire response, which appears to be in XML format with this gateway.
The $commError will contain any error messages related to making communications with the gateway, but not errors issued *by* the gateway.

Then just below that section is:```
    // use XML Parser on $authorize
    $xml_parser = xml_parser_create();
    xml_parser_set_option($xml_parser,XML_OPTION_CASE_FOLDING,0);
    xml_parser_set_option($xml_parser,XML_OPTION_SKIP_WHITE,1);
    xml_parse_into_struct($xml_parser, $authorize, $vals, $index);
    xml_parser_free($xml_parser);
```... which parses the XML into a more usable format, and stuffs it into the $vals object.
So, after this section you could add:```
die(var_dump($vals));
``` to have it completely halt and dump the response to the screen. (Not ideal for a live site where real orders are happening, but okay for debugging separately.)

Awesome, thanks Doc. I'll test those out.

DrByte:

Then just below that section is:```
// use XML Parser on $authorize
$xml_parser = xml_parser_create();
xml_parser_set_option($xml_parser,XML_OPTION_CASE_FOLDING,0);
xml_parser_set_option($xml_parser,XML_OPTION_SKIP_WHITE,1);
xml_parse_into_struct($xml_parser, $authorize, $vals, $index);
xml_parser_free($xml_parser);

> So, after this section you could add:```
die(var_dump($vals));
``` to have it completely halt and dump the response to the screen. (Not ideal for a live site where real orders are happening, but okay for debugging separately.)

When I add that line after xml_parser_free($xml_parser); I get :

array(0) { }

which means that $vals is empty?

Ya. Try doing the same for $authorize and $commError

DrByte:

Ya. Try doing the same for $authorize and $commError

When I run die(var_dump($authorize)); I get

bool(false)

and when I run die(var_dump($commError)); I get

string(21) "SSL read: errno -5961"

Mike D:

and when I run die(var_dump($commError)); I get

string(21) "SSL read: errno -5961"

You'll want to fix whatever is causing it to trigger SSL/TLS errors. Many payment gateways are modernizing their SSL/TLS infrastructure to improve security of transmissions, and these changes often require that the server you're transmitting from (ie: your store) also be modernized. Not sure if this is the cause of your error or not, but it's worth noting.

DrByte:

You'll want to fix whatever is causing it to trigger SSL/TLS errors. Many payment gateways are modernizing their SSL/TLS infrastructure to improve security of transmissions, and these changes often require that the server you're transmitting from (ie: your store) also be modernized. Not sure if this is the cause of your error or not, but it's worth noting.

The tech guy at GoDaddy suspects it might be my .htaccess file that's the culprit since I've got redirects and there's nothing about https in there. It does sound plausible to me - not that I really know anything about this - so I'm going to look into it, but the GoDaddy tech guy can't tell me what to look for exactly so I'm left to my own devices to figure that out.

I'm just posting in case anybody already knows what I should be looking for or definitely knows I'm barking up the wrong tree and am wasting my time and can give me a heads up.

Mike D:

The tech guy at GoDaddy suspects it might be my .htaccess file
Sheesh. GoDaddy techs don't know anything.

What you're encountering is a case where you've got a PHP script running CURL to make a secure external connection to a 3rd-party service. SSL/TLS is used to make it secure, but that has nothing to do with the SSL certificate on your domain, or anything in .htaccess. Both .htaccess and your site's SSL certificate are for INCOMING traffic.

SSL/TLS errors on outbound traffic are caused by the server's internal configuration being broken, or sometimes by invalid parameters in the outgoing request (by "invalid" I mean "incompatible with your server's limited capabilities vs the requirements of the 3rd party server you're trying to connect to").

I don't use Paymentech, but testing TLS/SSL using the tools Zen Cart provides in the /extras/ folder (esp in v155) (they are standalone and don't require Zen Cart in order to use them) would be the starting point I'd use to test general capability. Then if the problem is determined to be unique to your paymentech module, then look at simplifying the CURL parameters used to make a connection. You could even add the paymentech connection URL to the curltester.php or paypal_tls_test.php scripts to see if there's anything revealed in doing that.

Just posting my progress so far, if you can call it that.

I've run the curltester, ipncheck, and paypal_tlstest (adding the payment gateway url) and tests come back GOOD and OK with no errors or anything like that.

I followed the link in curltester to https://www.ssllabs.com/ssltest/index.html and ran my site through that and two possible problems popped up: RC4 and Forward Secrecy.

I've asked paymentech if they knew if either of these were problematic. They say they don't support RC4 anymore and don't even know what Forward Secrecy is.

I'll be looking into these two things very much hoping one of them is the culprit and is easy to fix. Otherwise, I'll be assuming the problem is unique to my payment module and see if I'm able to simplify the CURL parameters myself.

Don't suppose anyone has been using this with ZC 1.55e?

Thanks!