To be fair, the complication and failure of this plugin is it’s history, not the quality of the code.
First, there was a premium plugin, with paid support, installed on many client websites. (In my case, I inherited maintenance.) One day, that plugin had an update, which I’m sure many devs thought was to fix a Paypal API update.
The first frustration was that many of us renewed our paid support subscriptions in order to get the update which notified us of the plugin’s demise AFTER the update. The update actually deleted its own functionality (which admittedly wasn’t working anyway) and was replaced by a very aggressive and invasive nag alert (which caused warnings and errors with other plugins).
The second was that the new plugin (this one) wasn’t a continuation of the other one, the code, the API, the UI, everything was different, and had to be configured differently, Paypal configured differently…which many of us still haven’t figured out (because we went with another plugin).
This caused a lot of anger, both with the devs, and the clients calling every hour wondering why their store wasn’t working. Sure, you can dump on the developers for not being up on their subscriptions to the paid support that disappeared and left them hanging. But that doesn’t do anything for the anger, which isn’t always rational.
I don’t have any real idea if this plugin, in it’s current form, works. “Dumpster Fire” was a little strong. Perhaps this free plugin has no relation to the old one, and was unaware that the paid version sent all the blame here. After all, both are listed as being developed by “WooCommerce.”
If so, after 5 months I’m calmed enough to say I’m sorry, if you aren’t responsible for WooCommerce’s epic failure. The experience of being Woo ninja’d from a paid plugin to an unrelated one was really the problem.