Cloudflare is block callback from LiaPay
Disable all security - not working.
Disable DNS to direct connection with my server is working correct.
Requests from LiqPay are not displayed in Events.
This problem occurs on several sites.
Can you please share some crystal clear evidence for your allegation, that will prove that it is actually Cloudflare, who is blocking the callback from LiaPay / LiqPay?
Disable DNS to direct connection with my server is working correct.
This is not the first time. Last time it worked by itself. Here is the previous topic Problems with API callback from LiqPay to website
That isn’t evidence that Cloudflare is behind these alleged issues…
As was also said so nicely over there, by @Laudian:
You’re saying that it doesn’t show up there, also, it isn’t Cloudflare.
Problems like this would typically be that the traffic was intercepted before it ended up on Cloudflare.
In such situations, there will be absolutely nothing that Cloudflare can do.
It could for example be LiqPay’s ISP, that have (or have had) temporary issues at the time.
Stuff like this is continuing to send the problem towards something on LiqPay’s end.
That said, - if you expect anyone here, to be able to dig further in to it, together with you, …
→
You will need to get much more detailed information, such as e.g. error codes and messages, as they are seen from LiqPay’s end.
Does LiqPay see a HTTP status code 123, or HTTP status code 456?
Does LiqPay see any errors, leading to no specific HTTP staus code being returned, - and if so, what exact error codes and messages do they see?
… Further logging information?
Without such detailed logging information, about what they see from their end, the only thing anyone can do, will be to advice you to talk to LiqPay, regarding the issues you believe you’re having, with their service.
You reason very well.
I turn off cloudflare and everything starts working fine. But for you this is “not proof”.
So do you? But I guess perhaps some things could be lost in translation.
→
If you want any further digging in to the issues from this side, please gather and share the detailed error information from LiqPay, as requested above.
I contacted LiqPay. They can’t help. They say that everything works for them and the problem is on the website’s side. They don’t give more detailed information.
Since the 10th, I’ve encountered the same issue — most likely, LiqPay has changed something on their callback server. It now refuses to work with Cloudflare certificates, as the requests simply don’t reach the Cloudflare server.
I opted for a somewhat workaround solution, but it effectively resolves the problem. Configure proxying of your requests through a subdomain without Cloudflare protection, using a Let’s Encrypt certificate. This subdomain should proxy all requests while preserving all the data sent by LiqPay.
As a result, LiqPay will send requests to gateway-proxy.your-domain.com/gateway_path, and you’ll forward them to the actual gateway.
Are there instructions on how to do this?
Interesting theory, regarding the certificates.
Do you mind sharing the domain name(s) you had issues with?
I’m just wondering if we can eventually find a more specific connection between the certificate (authorities), and the defective LiqPay connections.
→
It is also possible that the ISP, that provides Internet connectivity to LiqPay, that they are blocking access to (some, or all) Cloudflare IP addresses from time to time.
Such things have been seen before, and lately, a Spanish payment processor have seen issues due to such silly ISP decisions, because “LaLiga” ordered the blocking of Cloudflare IP addresses, during football matches.
Previously, I also heard “rumours” regarding the Ukraine and Russia conflict, that both countries were allegedly playing around with such silly ISP / government decisions, in order to block the other party out.
In a such situation, it isn’t impossible a such silly decision will give collateral damage, such as for example like what can be seen in this thread.
But without any more useful debugging / logging information, from LiqPay, it unfortunately won’t be possible to say for sure, where the actual issue with LiqPay is.
That sucks, - and actually sounds very odd, from their side, that they won’t provide such.
My personal advice, would be to look at another, and possibly better payment provider.
How to do the LiqPay thing (e.g. which files to change, or where), may depend on how LiqPay has been implemented on your website.
However, - the basics are:
Add a duplicate DNS record of your existing one, that isn’t Proxied (
), so it looks like this:
Where you previously had your LiqPay configured, so it was sending the payment callbacks to “https://www.example.com”
You’re now changing your LiqPay configuration, so that it is sending the payment callbacks to “https://www-liqpay.example.com” instead.
Regarding “www-liqpay”, you can use any name, as long as it matches all the way along your configurations.
With a such kind of (re-)configuration, your payment callbacks wouldn’t go over Cloudflare any more, but go directly to your own sever.
I can only share part of the information due to its sensitive nature, but I managed to retrieve the following key callback result provided by LiqPay:
[HTTP_SERVICE_RES <<>> 200 5129ms] {“error”:“{error,{failed_connect,[{to_address,{"*",443}},\n {inet,[inet],timeout}]}}”,“code”:0}"**
From this, it’s clear that their server is unable to send requests to my site over port 443 (SSL). What’s odd is the error code 0, which I’ve never encountered before. After running various diagnostics and checking logs, I confirmed that Cloudflare doesn’t log any such request — meaning it never even reaches their edge servers.
Despite this, their support kept insisting that I should allowlist their IP addresses. But this was already done from the very beginning of the integration — they simply responded with generic copy-paste replies.
Here’s a bit more technical detail about how they send requests:
TLS 1.2 with cipher suites:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
I also tested incoming requests from another remote server: they work fine if I add the IP to the allowlist. Otherwise, I at least see a log entry showing the request was blocked. However, in LiqPay’s case — there’s no log at all.
After multiple back-and-forth messages where they blamed Cloudflare or claimed my config was wrong, I finally gave up and set up a reverse proxy through another server I control. I can’t risk exposing my primary IP due to compliance and security concerns, and unfortunately, the payment provider refuses to take responsibility or escalate the issue. They also did not allow me to send a detailed technical report to their engineering team, which could have helped identify the root cause.
Regarding potential ISP-level blocking — I understand your concern, and in my region, due to the ongoing war, strong network-level protections are a necessity. Cyberattacks of various kinds remain a serious issue and occur frequently, even with strict firewall rules and filters in place. However, this does not affect LiqPay’s callback servers, as they are hosted on Amazon infrastructure in countries where there are no such restrictions or blocks in place. Therefore, local ISP or country-level blocking is clearly not the cause of the callback delivery failure.
As for why LiqPay seems uninterested in fixing the issue — I believe one possible reason is their organizational structure. Since PrivatBank was nationalized, and LiqPay is its subsidiary, this may have further impacted their responsiveness. However, it’s worth noting that even before nationalization, LiqPay was known for poor customer orientation and lack of initiative in solving user-side issues. Unfortunately, arguments about the importance of resolving compatibility problems with the world’s most popular website protection service seem to fall on deaf ears.
And switching to another payment provider is not always an option. For example, on gaming-related projects (not gambling), no one except LiqPay is willing to work with us, even though this is a completely legal and “white” industry.
To provide detailed instructions on setting up proxying, I’ll need some information about your environment — for example, are you using shared web hosting, a VPS/VDS, or a dedicated server? Do you have a control panel installed? What operating system are you running?
If you’re on shared web hosting, it’s best to contact your hosting provider’s support, as available tools and control panel options can vary greatly.
In short, here’s what worked for me:
I created an A record pointing to a server where I could safely expose the real IP address for use as a proxy, e.g., gateway.domain.com.
On that server, I configured Certbot to automatically issue and renew SSL certificates.
I then set up an NGINX rule to proxy all incoming requests from this subdomain to the actual gateway server.
Finally, I added the proxy server’s IP address to Cloudflare’s allowlist to bypass their protection.
After that, I performed a test payment (make sure it’s a new one — old payments may trigger callbacks to the previous callback URL), and everything worked fine.
It failed to connect, to the IP address I believe you redacted with an asterisk, due to a timeout after a little over 5 seconds (5.129 seconds, to be exact).
Error code 0 appears quite common, when things aren’t reaching the destination, and that there for some reason won’t be any (more) specific success or failure codes available.
I will be happy to admit, that I don’t know (for sure) where LiqPay’s infrastructure is, and as such, won’t comment on that specific part.
However, -
Both the timeout you see, as well as the “error code 0”, or even the error code with multiple 0’s, is very consistent with other payment providers, when they are using an ISP / carrier, that is blocking access to one or more Cloudflare IP addresses.
Everything seems to point in that direction.