Directly accesses redirect.php when it's not advisable for WordPress plugins to call PHP scripts directly

[KZeni]

Security Note: Consider blocking direct access to your plugin PHP files by adding the following line at the top of each of them. Also be sure to refrain from executing sensitive standalone PHP code before calling any WordPress functions.

Per https://codex.wordpress.org/Writing_a_Plugin. The documentation page then shows example code which would prevent direct PHP file access. Meanwhile, this plugin is allowing direct PHP file access (it actually requires it) and not using WordPress functions. So this is currently failing two security practices that are detailed in the official documentation.

In addition to being a potential security issue, this becomes more troublesome on sites with hardened security (via https://wordpress.org/plugins/sucuri-scanner/ and other methods) where the wp-content & other folders are made to automatically block direct PHP file access (breaking this plugin in the process per the site following fairly common & recommendable security practices.)

I don't see why this couldn't be implemented as a function in the main plugin file which is hooked into / called after the checkout form's submission (instead of it being output via a direct PHP script call.)

I'd highly recommend this be revisited & re-implemented using the recommended WordPress plugin practices & available functions/hooks/etc.

[KZeni]

As an aside, I came across this with my site not allowing direct PHP access per Sucuri's recommendable site security hardening and testing the NiahoPay checkout process to see it went to a web server error page (certainly not ideal for those unfamiliar with this potential issue).

I've added a manual exception of this redirect.php file in the meantime, but I'd love to not need to manage that exception moving forward.