Westpac Qvalent TLS Changes
On this page
- 1 Important Change Information for Westpac Qvalent TLS Changes
- 2 What is happening?
- 3 Why is this happening?
- 4 What do I need to do?
- 5 What TLSv1.2 and TLSv1.3 ciphers will we support after the cutover date?
- 6 How do I know if we are ready for this change?
- 7 When will Qvalent/Westpac disable insecure ciphers and enable TLSv1.3?
- 8 Frequently Asked Questions
- 9 Contact Us
Important Change Information for Westpac Qvalent TLS Changes
As part of our initiative to conform to the new requirements issued by the Payment Card Industry Security Standard Council and cyber security best practice, we will be making changes to our web services that use TLS.
What is happening?
Since 2024, we have been working to enable TLSv1.3 and disable ciphers which are now considered insecure:
TLSv1.3 has been enabled in all environments since 2024.
Insecure ciphers have been disabled in test environments since 2024 and will be progressively disabled in Production in 2025. The schedule for disablement is dependent on customers migrating from the insecure ciphers and so we are working with affected customers to assist them in this process.
Why is this happening?
At Qvalent we treat the protection of our customers' data very seriously. Sometimes we need to make security improvements and retire older encryption protocols. This allows us to maintain the highest security standards and promote the safety of your data.
To maintain alignment with these best practices and to maintain industry standards such as PCI-DSS and Gateway Network Governance Body, Qvalent will disable the use of insecure ciphers across TLSv1.2 and TLSv1.3 for connections to Qvalent/Westpac services.
What do I need to do?
API integrations to Qvalent/Westpac services connect via TLS to make API requests and receive responses. TLS connections can only be established when both your system and our system can ‘agree’ on a cipher to use. After the change, your system will only be able to connect if it is configured to support one of the secure ciphers we support. We are working through connection logs to identify customers that are using insecure ciphers in Production. If contacted, you will need to:
Review your system configuration. Most systems will use HTTP client software to establish a TLS connection and all modern HTTP clients will support secure ciphers. It is possible that your system is capable of supporting secure ciphers but is configured to preference a cipher which is no longer considered secure. In this case, the change is likely to be a simple configuration change. Otherwise, if your HTTP client is very old, you may need to upgrade it. If possible, we recommend that you disable support on your side for insecure ciphers in line with industry best practice.
Test in non-production. Our non-production environment has already been changed to only support secure ciphers. This means that if your test system can establish a connection in non-production, the same configuration will be able to establish a connection in Production once support for insecure ciphers is removed.
Implement in Production. If any configuration changes are required, you must implement them in Production prior to us making our change. We can review our connection logs to verify if your changes are now establishing connections using a secure cipher.
What TLSv1.2 and TLSv1.3 ciphers will we support after the cutover date?
Your system must support at least one of these secure ciphers to establish a connection. If possible, we recommend that you preference one of the supported TLSv1.3-based ciphers.
TLSv1.3
Cipher | Name (OpenSSL) | Cipher Suite Name (IANA) |
|---|---|---|
| TLS-AES-256-GCM-SHA384 | TLS_AES_256_GCM_SHA384 |
| TLS-CHACHA20-POLY1305-SHA256 | TLS_CHACHA20_POLY1305_SHA256 |
| TLS-AES-128-GCM-SHA256 | TLS_AES_128_GCM_SHA256 |
TLSv1.2
Cipher | Name (OpenSSL) | Cipher Suite Name (IANA) |
|---|---|---|
| ECDHE-RSA-AES256-GCM-SHA384 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
| ECDHE-RSA-AES128-GCM-SHA256 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
| ECDHE-RSA-CHACHA20-POLY1305 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |
Note: TLSv1.2 ECDSA ciphers are not included in the accepted list as they are not compatible with RSA-based certificates held on our servers.
How do I know if we are ready for this change?
After we disable the insecure ciphers, any TLS connection to Qvalent/Westpac services must support at least one of the above ciphers. There two are different channels that need encryption to access Qvalent/Westpac services. These channels are:
Internet Browser
API integrations
An overview of each are below:
Internet Browsers
All modern browsers support secure ciphers and all Production sites exclusively accessed by web browsers have already been changed to support secure ciphers only. Therefore, if you can access our websites now, you will continue to be able to access them. In the unlikely event that you do receive an error, please speak to your IT department.
API Integrations
Examples of API integrations are:
Secure token request for QuickWeb, QuickConnect, QuickVault, and PayWay Net.
API requests for QuickGateway, QuickVault, PayWay API, REST API or iLink HTTPS/SOAP
We recommend that affected customers test any changes in our non-production environment before implementing in Production.
PayWay
Point your test environment to connect to the PayWay non-production environment. You may have implemented:
PayWay Net with a secure token request; or
PayWay API
Perform a secure token request or API request using the TEST merchant.
If you do not receive a TLS handshake error message then the underlying TLS connection was successful using the updated ciphers.
Quickstream
Point your test environment to connect to the QuickStream non-production environment. You may have implemented:
QuickWeb/QuickConnect/QuickVault with a secure token request;
QuickGateway; or
REST API
Perform a secure token request or API request to the non-production environment.
If you do not receive a TLS handshake error message then the underlying TLS connection was successful using the updated ciphers.
iLink HTTP File Transfers Messages
Point your test environment to connect to the iLink non-production environment. You may have implemented an HTTPS file transfer.
Perform a HTTPS post to the non-production environment.
If you do not receive a TLS handshake error message then the underlying TLS connection was successful using the updated ciphers.
When will Qvalent/Westpac disable insecure ciphers and enable TLSv1.3?
We plan to disable insecure ciphers and enable TLSv1.3 encryption according to the following schedule:
Services | Insecure cipher disablement and TLSv1.3 enablement schedule |
|---|---|
Test environments (all)
| COMPLETE *.staging.qvalent.com and *.support.qvalent.com TLS v1.3 Enabled: 20th of May 2024 Insecure Ciphers Disabled: September 2024 |
Production environments (web browser access only)
| COMPLETE TLS v1.3 Enabled: September 2024 Insecure Ciphers Disabled: July 2025 |
Production environments - Phase 1: | COMPLETE TLS v1.3 Enabled: September 2024 Insecure Ciphers Disabled: 03 September 2025 |
Production environments - Phase 2:
| COMPLETE TLS v1.3 Enabled: September 2024 Insecure Ciphers Disabled: 10 September 2025 |
Production environments - Phase 3:
| COMPLETE TLS v1.3 Enabled: September 2024 Insecure Ciphers Disabled: 17 September 2025 |
Dates are subject to change.
Frequently Asked Questions
How do I evaluate whether my HTTPS connectivity contains cryptography which is compatible with the changes Westpac is making?
Westpac advises customers to perform a full UAT test against our Test/Support environment to confirm this change will not cause any issues for your integrations.
Can I be granted an extension for this change?
Given this is a PCI-DSS requirement, extensions are unlikely to be granted for this change. As this change affects the cryptography offered to all customers via our web services, all customers must be ready for the change to occur. We will help affected customers to review your existing connection and resolve any issues in advance of the change.
Will there be a way to continue using the old cryptographic standards
No, the above-mentioned cryptographic functions will be disabled.
My implementation solution does not involve credit card data and therefore is not subject to PCI-DSS. Does this change still apply to me?
Yes, this change will apply to all HTTP customers that connect to the Westpac web services supported by Qvalent. This is not only a PCI-DSS requirement, but also best industry practice.
Do I need to move to TLSv1.3 as part of this change?
No, you may continue to use TLSv1.2 with a secure, supported cipher. However, if your system is capable of supporting TLSv1.3 then we would encourage moving to this now for enhanced security and future-proofing. That is, although TLSv1.3 is not currently a minimum requirement of PCI-DSS, this is likely to change in the future.
Contact Us
Product | Phone | Hours (AEST) | |
|---|---|---|---|
PayWay | payway@qvalent.com | 1300 727 111 | 8:30am - 5:30pm, Mon - Fri |
PaymentsPlus | paymentsplus@qvalent.com | 1300 325 402 | 8:30am - 5:30pm, Mon - Fri |
QuickStream | quickstream@qvalent.com | 1300 726 370 | 7:00am - 7:00pm, Mon - Fri |
iLink | ilink_support@qvalent.com | 1300 726 370 | 7:00am - 7:00pm, Mon - Fri |
Disclaimer
These guidelines are general in nature and have been prepared without knowledge of the specific environment in which your systems operate. These guidelines are current at the time of writing, but may require update over time. Except where contrary to law, Westpac intends by this notice, to exclude liability for these guidelines and the information contained in them. While Westpac has made every effort to ensure these guidelines are free from error, Westpac does not warrant their accuracy, adequacy or completeness.