https://drive.google.com/file/d/10NLHlrvPtoLCnGRh8n-h_cy4sTibGuSx/view?usp=sharing

Then I disabled all plugins except for WooCommerce and WooCommerce Eway Payment Gateway, still the same endless loading png.

We don’t have any server-side caching.

I checked WooCommerce -> status -> logs but nothing relevant appears there.

Looking at the HTML, using our original theme, the HTML for the labels is there but there is no <input> tag anywhere, except for some hidden fields.
Using the storefront theme, there are a lot of JS errors (dozens):

eway-secure-fields.js?ver=c478ae3db56065b75468:1 Uncaught Error: V6143
at secureFieldCallback (eway-secure-fields.js?ver=c478ae3db56065b75468:1:1200)
at Object.f as setupSecureField
at Object.setupAllSecureFields (eway-secure-fields.js?ver=c478ae3db56065b75468:1:835)
at HTMLBodyElement. (eway-secure-fields.js?ver=c478ae3db56065b75468:2:5347)
at HTMLBodyElement.dispatch (jquery.min.js?ver=3.7.1:2:40035)
at v.handle (jquery.min.js?ver=3.7.1:2:38006)
at Object.trigger (jquery.min.js?ver=3.7.1:2:70124)
at HTMLBodyElement. (jquery.min.js?ver=3.7.1:2:70726)
at Function.each (jquery.min.js?ver=3.7.1:2:3129)
at e..each (jquery.min.js?ver=3.7.1:2:1594)

The above JS errors also appear with our original theme, but only 2 times, i.e. once for each field, then we see:


Uncaught TypeError: Cannot set properties of null (setting 'disabled')
at HTMLInputElement. (eway-secure-fields.js?ver=c478ae3db56065b75468:2:5983)
at HTMLBodyElement.dispatch (jquery.min.js?ver=3.7.1:2:40035)
at v.handle (jquery.min.js?ver=3.7.1:2:38006)
at Object.trigger (jquery.min.js?ver=3.7.1:2:70124)
at HTMLInputElement. (jquery.min.js?ver=3.7.1:2:70726)
at Function.each (jquery.min.js?ver=3.7.1:2:3129)
at e..each (jquery.min.js?ver=3.7.1:2:1594)
at e..trigger (jquery.min.js?ver=3.7.1:2:70701)
at HTMLInputElement. (checkout.min.js?ver=8.6.1:1:8805)
at Function.each (jquery.min.js?ver=3.7.1:2:3129)
(anonymous) @ eway-secure-fields.js?ver=c478ae3db56065b75468:2
dispatch @ jquery.min.js?ver=3.7.1:2
v.handle @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
(anonymous) @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
(anonymous) @ checkout.min.js?ver=8.6.1:1
each @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
success @ checkout.min.js?ver=8.6.1:1
c @ jquery.min.js?ver=3.7.1:2
fireWith @ jquery.min.js?ver=3.7.1:2
l @ jquery.min.js?ver=3.7.1:2
(anonymous) @ jquery.min.js?ver=3.7.1:2
load (async)
send @ jquery.min.js?ver=3.7.1:2
ajax @ jquery.min.js?ver=3.7.1:2
(anonymous) @ jquery-migrate.min.js?ver=3.4.1:2
e. @ jquery-migrate.min.js?ver=3.4.1:2
update_checkout_action @ checkout.min.js?ver=8.6.1:1
setTimeout (async)
update_checkout @ checkout.min.js?ver=8.6.1:1
dispatch @ jquery.min.js?ver=3.7.1:2
v.handle @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
(anonymous) @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
init_checkout @ checkout.min.js?ver=8.6.1:1
dispatch @ jquery.min.js?ver=3.7.1:2
v.handle @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
(anonymous) @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
each @ jquery.min.js?ver=3.7.1:2
trigger @ jquery.min.js?ver=3.7.1:2
init @ checkout.min.js?ver=8.6.1:1
(anonymous) @ checkout.min.js?ver=8.6.1:1
e @ jquery.min.js?ver=3.7.1:2
t @ jquery.min.js?ver=3.7.1:2
setTimeout (async)
(anonymous) @ jquery.min.js?ver=3.7.1:2
c @ jquery.min.js?ver=3.7.1:2
fireWith @ jquery.min.js?ver=3.7.1:2
fire @ jquery.min.js?ver=3.7.1:2
c @ jquery.min.js?ver=3.7.1:2
fireWith @ jquery.min.js?ver=3.7.1:2
ready @ jquery.min.js?ver=3.7.1:2
P @ jquery.min.js?ver=3.7.1:2
eway-secure-fields.js?ver=c478ae3db56065b75468:2 Uncaught TypeError: Cannot set properties of null (setting 'disabled')
at HTMLInputElement. (eway-secure-fields.js?ver=c478ae3db56065b75468:2:6044)
at HTMLBodyElement.dispatch (jquery.min.js?ver=3.7.1:2:40035)
at v.handle (jquery.min.js?ver=3.7.1:2:38006)

This all started a couple of days ago.

woo order details: https://prnt.sc/apJClE1ZoVGZ
eway customer details: https://prnt.sc/ulJ3rWbB023l

I’ve recently been back and forth with E-way regarding security around bin attack prevention and Woocommerce EWAY Gateway and I have some general concerns relating to security that both E-Way and I seem to agree on. I’m posting this thread to start a conversation around security, recommend some of my own ideas on how I think security can be improved, and request some more info that can help us all craft some better solutions to improving security as a whole.

Firstly some context. We were recently contacted by EWay because they detected a range of bin attacks coming from one of the websites we manage. We already had Recaptcha v3 installed on our checkout and had some other server-level software in place to help mitigate these kinds of attacks but somehow they still got through. We decided to switch to a manual captcha and add 2 additional honeypot implementations yet somehow, bin attacks still seem to get through.

What I can tell is that I believe the checkout form itself is secure from bots but once a checkout session is created, the URL for the credit card form can be passed freely between different sessions and IP’s. You can reproduce this behavior by going to an EWAY Gateway Enabled Woocommerce site. Entering particulars to get to the credit card form and copying the URL. This URL can be passed to different browsers, different IP’s, even different countries, and the user can still complete the credit card purchase on behalf of someone else.

This means that a secure checkout could be completed by a real user and the credit card form could be passed to a bot to conduct the bin attack on a user’s behalf.

Now I understand that this plugin isn’t designed with checkout security in mind and that Recaptcha and Honey Pots aren’t really part of the package so you can’t guarantee compatibility. BUT I do know that EWay is telling the customers who are victims of these attacks to install Recaptcha and Honeypots on their checkout forms so I feel that adding some additional security checks here could serve a huge benefit to the plugin and it’s users.

Another idea is implementing Recaptcha or Honey Pots on the credit card form itself. I tried to investigate whether this idea is possible but I’m not sure. Correct me if I’m wrong but the credit card form connects directly to Eway using their “Eway Rapid” implementation so if the server is not handling these requests, I assume there’s no way to add additional validation to this form.

In summary I’m looking for
– Tighter security on the credit card form so that it can’t be transferred between different IP’s or sessions.
– An answer to the question “Can Recaptcha or honeypots be installed on the credit card form via validation hooks”.

Cheers and keep up the good work!

I have been directed here by the woocomerece team.
After the woocomerce update customers are not able to pay using creadit card, when they click the pay button it’s not doing anything.

My customers are focused on New Zealand area.

Woocomerce version: 5.4.0
Wordpress version: 5.7.2
Eway plugin version: 3.2.2

Please let me know how I can resolve this.

I rolled back to the previous version and the site was back online and working fine.

Has anyone else had this issue? Maybe found a solution?

The transactions are coming through on the backend marked as ‘pending payment’

Not sure what to do here

Thank you

Basically there is a field in eway called invoice description, just want to know if there is a hook which we can use to add the product name to this field.