Hi,
We have a WordPress website using WooCommerce with Worldpay as the gateway. Orders are not completing Worldpay are giving this error handshake_failure which has something to do with the SSL certificate I think. When we pause Cloudflare it all works fine and the orders complete.
Is there anything we can do to fix this, a rule we can add or a setting we can disable?
Regards,
Jim Isles
I presume you mean when they send a callback request, right? Which TLS version do you have configured?
Yes the callback request which confirms payment has been made. The below shows the current configuration.
Below is the failure emails we are getting:
Our systems have detected that your callback has failed.
This callback failure means we were unable to pass information
to your server about the following transaction:
Transaction ID: 3108598768
Cart ID: 29642
Installation ID: 1066692
Error reported: Callback to: https://www.derougemontmanor.com/wc-api/woocommerce_worldpay: failed CAUSED BY Received fatal alert: handshake_failure
Server Reference: ukdc1-pz-cen09:callbackFailureEmail-1069:MerchReq-686-67
Also, if you usually return a response page for us to display to the Shopper
within the time allowed (1 minute), this will not have been displayed.
WorldPay will have displayed to the Shopper the response page file
(resultY.html or resultC.html) held for your installation on the WorldPay
server. This will be your own custom version, if you have supplied one, or,
if not, the WorldPay default version.
This is the attachment to the email:
POST /wc-api/woocommerce_worldpay?msgType=authResult&installation=1066692 HTTP/1.0
Content-Length: 1272
Host: www.derougemontmanor.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: WJHRO/1.0 (WorldPay Java HTTP Request Object)
country=GB&routeKey=VISA_CREDIT-SSL&transId=3108598768&countryMatch=S&compName=DE+ROUGEMONT+MANOR+LTD&amountString=%26%23163%3B33.90&MC_returnurl=https%3A%2F%2Fwww.derougemontmanor.com%2Fcheckout%2Forder-received%2F29642%2F%3Fkey%3Dwc_order_5b8678a8e777f&tel=%2B448452416279&fax=&transStatus=Y&_SP.charEnc=…
There is an SSL certificate up on our server for this domain using Auto SSL as part of Cpanel. I did try disabling the Universal SSL in Cloudflare but this caused the site to go down. Is that what you mean?
I guess you removed the server certificate, which is required for HTTPS to work at all. What I was referring to is client authentication, which could also be done via a certificate. How do you authenticate the callback from Worldpay, so that a customer is not faking it?
No the server certificate has always been in place.
The payment gateway uses a plugin no coding required https://codecanyon.net/item/worldpay-gateway-for-woocommerce/1621916. The plugin is set up with passwords etc. as show in the below config page. It all works fine when we pause Cloudflare.
Alright, so the authentication takes place via a password.
It most likely is an issue of the TLS version, though I am a bit surprised, as you set as minimum version TLS 1.0 (I dont expect they require SSL, do they?). Try playing a bit with the encryption settings on Cloudflare’s side and check if that makes any difference (e.g. not allowing TLS 1.3).
Alternatively, did you have to define any certificate on Worldpay’s side? Not that it is some certificate pinning issue and they “freak out” because they dont get your certificate but Cloudflare’s.
OK will tweak some of the settings and see if that works.
My client who is the account manager spoke with their support a day or so ago which pointed my in the direction of Cloudflare they said the below but this isn’t the case as it wouldn’t work with Cloudflare disabled either.
They believe fatal alert handshake failure could be caused by SNI being enabled on the hosts server. Worldpay won’t support SNI and it needs to be disabled for it to work.
Thats actually a good point. Cloudflare requires SNI, as they otherwise cant choose the right certificate to send back. If Worldpay does not support SNI I am afraid you wont get it to work together with Cloudflare.
Worldpay should really fix that, SNI is standard these days and particularly a necessity in any shared environment.
Just tried it with TLS 1.3 disabled and again with 1.3 enabled min TLS version set to 1.3.
I think from what you are saying SNI is the issue I will go back to Worldpay and see if there is anything we can do, failing that we may just have to disable Cloudflare.
Tanks for your help.
I worked around the worldpay restriction with the following steps:
Create new worldpay subdomain for the affected domain e.g. worldpay.example.com
Secure worldpay.example.com with a free certificate from https://letsencrypt.org/ (it’s just a tick box during subdomain creation in Plesk 17)
Move callback script for affected domain from its current location to the new worldpay subdomain. e.g. from example.com/cb.php to worldpay.example.com/cb.php
Create new worldpay CNAME entry in Cloudflare DNS page for the affected domain and turn the cloud off for the new CNAME
Login to Worldpay admin interface and update the Payment Response URL for the affected installation to match the new URL you set up at step 3
Test!
Now the worldpay system sends its callback POST to worldpay.example.com/cb.php which Cloudflare sends directly to the server (rather than processing it with its SNI cert) and as long as the server has a valid cert installed from e.g. Let’s Encrypt, it works. No more handshake_failure messages 
Hi,
That’s fantastic thank you will give that a try.
It’s really bad from Worldpay they should really get with the times.
Jim
