Banks handle everyone's money and are high-profile targets for compromise over the network. As such, they should be obliged to keep current with best security practices as the technology evolves, not lag far behind these.
But that's the inherent problem; these companies are still setup for a bureaucracy that works fine in a particular area of business, but completely crumbles under the new rules of the technological age. We shouldn't be apologetic for their resisting of change, but rather pushing them to take a long hard look at what needs to be reorganized to fit into the new paradigm.
Banks, of all businesses, should be concerned about online security, for real protection and for appearance of caring for their customers' peace of mind. Mozilla telegraphs these browser changes months in advance.
After the CVE score for BEAST and RC4 got adjusted and the RFC 7465 was introduced I've seen some payment systems update their system quite quickly (in a matter of days),
and if they didn't they'd probably fail their next PCI audit:
https://news.ycombinator.com/item?id=9198889
Perhaps it helps if you write your payment site operator/bank private emails asking them to allow other ciphers beside RC4, mine looked like this (actual site name removed):
According to Qualys SSL Labs the site **** [2] only supports the RC4 cipher,
and thus is not RFC 7465 compliant [3], and Google Chrome qualifies the site as
"Your connection to **** is encrypted with obsolete cryptography."
The site **** is even worse [4], it uses only 768-bit DH key exchange in some
situations (instead of 2048).
There is an online tool [5] that you can use to generate/compare
configuration for popular web-servers, using the intermediate level is
recommended [6].
For your information I sent a similar email last year to **** and they have
fixed their problems, and get a nice 'A' grade from SSLLabs now.
Apparently this use of RC4 all comes down due to a mistake in NIST's
classification of the severity of the BEAST vulnerability [7], but both Google
Chrome[7] and Mozilla Firefox[8] are trying to avoid the use of RC4 completely,
and mitigating the BEAST vulnerability is no excuse for not providing good
ciphers (in addition to RC4 if you must) when my browser supports TLS 1.2 with
AES-GCM which is NOT vulnerable to the BEAST attack.
I suggest you to include the Qualys SSL Labs test when testing sites for
PCI-DSS compliance, they are usually quite good at reporting the latest TLS
vulnerabilities for a server.
[1] http://www.visaeurope.com/media/images/pci%20dss%20validated%20web%20listing%20march%202015-73-18412.pdf
[2] https://www.ssllabs.com/ssltest/analyze.html?d=****
This server accepts the RC4 cipher, which is weak. Grade capped to B.
Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
[3] https://tools.ietf.org/html/rfc7465
[4] https://www.ssllabs.com/ssltest/analyze.html?d=****
This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F.
Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
This server accepts the RC4 cipher, which is weak. Grade capped to B.
[5] https://mozilla.github.io/server-side-tls/ssl-config-generator/
[6] https://wiki.mozilla.org/Security/Server_Side_TLS
[7] https://code.google.com/p/chromium/issues/detail?id=375342#c30
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
[9] https://www.ssllabs.com/ssltest/analyze.html?d=****
Sadly the 768-bit DHE is hardcoded into older versions of Java, which is why I suggested to them that they raise the limit to that instead of 1024-bit for now.
One day they'll catch up.