Evergreen can fail to connect to authorize.net

[Galen Charlton]

Evergreen can fail to connect to an API endpoint from authorize.net, meaning that credit card payments through that service fail to be proceed.

The error message received by Evergreen is:

No x_response_code from server, (HTTPS response: 900 NET OR SSL ERROR ) (HTTPS headers: ) (Raw HTTPS content: )

Upon tracing this further, this appears to be an issue with newer versions of

* Net::SSLeay (which is what Business::OnlinePayment::AuthorizeNet ultimately uses to make the API call)
and/or
* OpenSSL (specifically, version 3)

What works:

Net::SSLeay <= 1.88
OpenSSL <= 1.1.1w

What doesn't work:

Net::SSLeay 1.92
OpenSSL 3

The following test script can exercise the problem:

```
mc@eg-dev1:/tmp$ cat /tmp/test.pl
#!/usr/bin/perl

use strict;
use warnings;

use Net::SSLeay qw(get_https);

warn $Net::SSLeay::VERSION;
my ($page, $response, $reply_headers);
($page, $response, $reply_headers) = get_https('apitest.authorize.net', 443, '/');

warn $response;
```

A failure gives the following output:

---
1.92 at /tmp/test.pl line 8.
HTTP/1.0 900 NET OR SSL ERROR

SSL_read 158267: 1 - error:0A000126:SSL routines::unexpected eof while reading
---

I also tried a development version of Net::SSLeay, 1.93_02; that didn't fix it.

Original report from Benjamin Murphy of NC Cardinal.

[Galen Charlton (gmc)]

This looks like this starts becoming a problem with Debian 12 Bookworm and Ubuntu 22.04 LTS Jammy.

[Galen Charlton (gmc)]

I've opened a bug with the maintainer of Net::SSLeay here: https://github.com/radiator-software/p5-net-ssleay/issues/447.

LWP::UserAgent works fine with apitest.authorize.net, but since swapping it in would require a change to Business::OnlinePayment or Net::HTTPS::Any, neither of which have had releases in years, hopefully this is something that can be fixed on the Net::SSLeay end of things.

Noting that unfortunately just downgrading to an earlier version of Net::SSLeay would likely be difficult, as it depends heavily on the version of OpenSSL that's present.

[Galen Charlton (gmc)]

On the other hand, it would be within the realm of possibility to vendor in Business::OnlinePayment::HTTPS (or Business::OnlinePayment::AuthorizeNet), but hopefully it won't come to that.

[Galen Charlton (gmc)]

Got a response [1] back from the maintainer of Net::SSLeay that suggests that no change to that module is forthcoming.

I've opened a bug [2] with the maintainer of Business::OnlinePayment, but note that there's been no update to that module in years.

Consequently, it seems likely we'll either need to vendor in parts of Business::OnlinePayment or consider writing a new client for AuthorizeNet's API.

[1] https://github.com/radiator-software/p5-net-ssleay/issues/447#issuecomment-1840400947
[2] https://rt.cpan.org/Ticket/Display.html?id=150674

[Diane Disbro (ddisbro)]

Maybe this should be a separate bug report, maybe not.

My library has used Authorize.net for years to accept credit card payment through the OPAC. Last week, we also started accepting payment at the service desk. Sometimes, we need to Refresh the page in order to be able to select "Process Payment Through Evergreen" from the "Process Where?" menu.
1. Select payment type credit card.
2. Enter payment amount.
3. Apply payment.
4. Process where? Record Externally Processed Payment is the default.
5. Process Payment Through Evergreen is grayed out and cannot be selected.
6. Use the browser Refresh function.
7. Now it is possible to select Process Payment Through Evergreen from the Process Where? menu.

[Galen Charlton (gmc)]

Thanks, Diane. That one should be moved to a separate bug, as the issue is in a different part of the stack.