Is there a valid reason to ignore null/invalid SSL certs (when dealing with payment processing)?

Question

So I got this dll from UnionPay for an ecom project with China and was asked to review. After throwing this into ILSpy, I couldn't help but notice the following method:

private static bool RemoteCertificateCallback(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
     return true;
}

Now, as I understand it, the purpose of such a callback is to allow for invalid or null SSL certificates - I've added similar support myself for unit testing.

(This sort of thing makes me highly suspicious of CHR government intervention allowing for intentional man-in-the-middle monitoring of transactions.)

Is there any legitimate reason for a payment processor to support null/invalid certs?

Answer 1

Is there any legitimate reason for a payment processor to support null/invalid certs?

None whatsoever. You are holding a secret conversion in a darkened room with ... anybody. You may as well be using plaintext. See the comments on non-authenticated SSL in RFC 2246. I agree with @SLaks entirely.