webaware

They had degradation problems on the 4th, transaction errors on the 14th, and currently still showing degradation. Seems problems ongoing. Check with Eway support for more information, I’m not plugged into what’s going on there operationally.

cheers,
Ross

G’day,

Eway’s status page is showing degraded performance for gateways and the Rapid API.

https://status.eway.com.au/

Scroll down to the table beginning with ‘Eway Gateways’.

cheers,
Ross

G’day Krzysztof,

You probably don’t need this plugin unless you are having an issue with expired transients, perhaps with cleaning up some old ones including old sessions from WooCommerce 2.4 or earlier, and some NextGEN Gallery pseudo-transients.

cheers,
Ross

G’day webdesinz,

I just took a quick look, you might get another payment failure from Mr Test Only (me).

Typically, a 401, Unauthorized means that the Eway API key/password pair is not valid for your account. Check by copying your API password from MyEway and pasting into the Eway settings in WordPress

WooCommerce > Settings > Payments > Eway

If your API key and password are correct in your settings, then you’d best speak to Eway for support. They may have locked down your account due to the spamming attack.

If you’ve been attacked once, it can happen again. I recommend that you configure and install something like Cloudflare Turnstile to try to block these attacks. If the attacks continue and appear to be actual humans, not just automation, then you might need to consider something like an Anti-Fraud plugin.

cheers,
Ross

G’day modernwoe,

Thanks for letting me know. It should be listing xmlwriter as a missing PHP extension, but the plugin is missing the admin template that would have that list so the list itself has gone missing (it should be where that bullet point is, in your screenshot). I’ve added the missing admin template in my development environment so it will be resolved in the next release, possibly very soon.

cheers,
Ross

This happens with both old and new API keys. I’ve seen this across different websites now. Something has changed, for sure. I don’t really have more details to provide than those above.

cheers,
Ross

G’day BWU,

Today I tried every version going back to v3.6.9 (which I know worked, see my old report) but none of them work now. Could it be a change in the error message returned from S3? i.e. could you still have code in place to deal with this, but it isn’t being called because the S3 error message/code has changed?

I’m pretty sure it all worked back in July, possibly even late August, when I set up new sites. That means it would have been working in v4.1.3 or v4.1.4 quite likely. Just no longer.

Incidentally, this is only an issue when creating backup jobs and entering (selecting) the bucket. Once that’s been done, s3:ListAllMyBuckets isn’t required and the jobs run successfully without it.

cheers,
Ross

Yes, it is compatible up to PHP 8.3 at present. I use it in my development environments, all 8.3

cheers,
Ross

Yes, it is compatible up to PHP 8.3 at present.

cheers,
Ross

G’day ikiterder,

Thanks for the bug report. I’ve had this fixed in my development environment for, well, “quite some time”… so I guess I’d better get a release out soon!

cheers,
Ross

G’day baursnes,

First things first, your websites doesn’t have a valid TLS certificate. That’s might be why the unknown error, as well. Mozilla says it’s a self-signed certificate.

Beyond that, I recommend checking the website error log. You can find your website error log through your hosting control panel, usually under a button called Logs. If you’re not sure where to find it, you can tell WordPress to write errors to the file wp-content/debug.log by editing your wp-config.php file. Find the line that says:

define('WP_DEBUG', false);

And replace it with this:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

NB: you should change it back when you’re finished, because debug mode slows your website down a bit!

cheers,
Ross

Duplicate, answered in other ticket.

cheers,
Ross

G’day ytian03,

Simply because it wasn’t available in WooCommerce when I initially wrote the integration in 2013. I’ve added the WooCommerce transaction ID now in version 5.3.0, so please update.

cheers,
Ross

The problem is that this plugin doesn’t currently support the new WooCommerce checkout block, only the old shortcode. I was hoping to add that support this week but every day brings more tasks that are urgent, so the earliest I’ll be able to do that is sometime next week. I’ll update this ticket once that has been done.

cheers,
Ross

G’day @jasonm530,

Have you enabled the payment method? You can do that either in the list of payment methods, or on the settings page for Eway payments.

If you have, have you enabled Sandbox mode? It won’t be available for payments if you haven’t set the live API details and Sandbox mode is not enabled.

cheers,
Ross