pronamic / wp-pay-core

Core components for the WordPress payment processing library. This library is used in the WordPress plugin Pronamic Pay: https://www.pronamicpay.com/, but also allows other plugin developers to set up a payment plugin.
https://www.wp-pay.org/
GNU General Public License v3.0
27 stars 3 forks source link

Issue while payment redirection in some hosting provider due to caching #56

Open knit-pay opened 2 years ago

knit-pay commented 2 years ago

Hello Team

I encountered another rare issue. This happens with websites on some hosting providers. Some hosting providers by default cache the homepage of the website. because of which filter_has_var( INPUT_GET, 'payment_redirect' ) always returns false even if payment_redirect and key are available in the URL. https://github.com/pronamic/wp-pay-core/blob/1d52978095404ead043a0bd24c67ecde8e3ece92/src/Plugin.php#L480

I suggested 2 of my clients contact the hosting providers and remove the caching on the homepage, and this solved the issue. But most of such clients think that this is the issue with the plugin instead of hosting. because they don't contact us.

Proposed Solution: If at the function below, we will change the URL format to an SEO-friendly URL for the hosting which supports SEO-friendly URL, this issue will get resolved. If hosting does not support SEO-friendly URL, we can continue to use this method. https://github.com/pronamic/wp-pay-core/blob/1d52978095404ead043a0bd24c67ecde8e3ece92/src/Payments/Payment.php#L294

The same issue is there with handle_returns and various other functions also.

What do you think? Can we fix this issue anyhow?

remcotolsma commented 2 years ago

Good catch, we should be able to fix that. In our PayPal gateway integration we (ab)use the REST API for this:

The advantage of the WordPress REST API is the ease of registering endpoints which automatically work with 'Plain Permalinks' (Ugly Permalink) and 'Pretty Permalinks':

We could use an endpoint like /wp-json/pronamic-pay/v1/payments/:payment_id/redirect?key=:key. Downside is that it's not common to output HTML via REST API endpoints (required for 'redirect' via HTML).

Maybe we should split this up too:

flowchart TD
    A[Start] --> B{HTTP or HTML?}
    B -->|HTTP| C[Redirect to gateway]
    B -->|HTML| D[Redirect to WordPress page]
    D --> E[Auto submit HTML form]

The question then is whether we make use of a regular WordPress page for the HTML 'redirect' or opt for custom rewrite rule. I think we should go for a custom rewrite rule so that we can use 'Pretty Permalinks', something like:

/:namespace/payments/:payment_id/redirect?key=:key