How do we resolve Direct HTTP server-to-server request issues?

You may have encountered an error on your site where your orders are always marked as pending or canceled. In this case, you’ll have to enable the Direct HTTP server-to-server request in the Transaction feedback section following the steps in this article. However, following the steps in the article still did not resolve the pending/canceled order issue.

Likely, the Direct HTTP server feature does not work properly because of the settings that you have on your server.

How can you find out that there is an issue with the server?

Issue# 1: The server responds with a 403 error.

You can get in touch with the ePDQ support team and report about your current situation. The ePDQ team will send requests to your server, and if your server responds with a 403 error: Forbidden message, this means that your server is refusing the request.

The orders which are coming through with no issues are because the customer is staying put. Barclays shows the message saying that the payment is(like in the screenshot below).

As you can see, it says the customer will be redirected back to your website. Suppose they stay put and wait till they see your website again. Barclays pass over the data to them. Making the payment shown on the website.

If they close the window or move to another website when they see that attached image, then Barclays uses the Direct HTTP server-to-server request (this is their function) to send the data to the website without the customer seeing the website. This function is basically to mitigate against customers from not allowing the redirect to the website.

Your hosting provider may be blocking this request when Barclays try and make it. This is why the orders are staying pending.
Once they allow this

Note
http://yourwebsiteurl.com/wc-api/ag_epdq_webhook/?PARAMVAR=<PARAMVAR>

<PARAMVAR> is replaced by the ePDQ system with the order ID number, so this will change.
The function will work as intended no matter what the customer does after payment has been logged on the ePDQ system.

Issue# 2: The server responds with a timeout

Same as issue#1, you can ask the ePDQ support team to have them take a look at your current situation. To make a successful transaction, your website and ePDQ would need to “communicate” with one other by sending “requests.” If there are no responses from your website, a timeout may be registered on their end (i.e., no response from your site for 20 seconds). A timeout usually indicates a firewall blocking the request.

Also, the Request is being made by something that’s not a browser so that the User-agent won’t be the same, and it won’t act the same depending on how the WAF (which is different from a traditional Firewall) is configured, such as automated requests might be blocked by your host. This could be for a range of reasons, from the endpoint to the user agent.

How can we resolve these issues?

Hosting providers may not be able to whitelist URLs, but you can ask them to whitelist Barclaycard’s IP addresses below for the request not to be blocked.

185.8.52.254
185.8.53.254185.8.54.254
212.23.45.97
212.35.124.164
91.208.214.40
91.208.214.41

Note: As per the article’s posting date, the above is what the ePDQ team has sent. You can ask the ePDQ team for any updates on their IP addresses that you could whitelist.

You can also send this firewall guide from the ePDQ team to your hosting provider – https://support.epdq.co.uk/en/integration/firewall-configuration/guide