PayPal payment cannot be seen?

Hi,

It's possible this comes from the same thing as you reported before:
www.hikashop.com/forum/payment-methods/9...h-paypal/370600.html
If you PayPal account already has payments with order ids matching with futur order ids on your website, all the payments for matching ids will fail while payments for ids not already in PayPal will work fine.
So, as I said 4 months ago, make sure the "No, allow multiple payments per invoice ID" setting is selected in your PayPal account.
This could be the same with Worldpay. I don't know if they have a similar mechanism.

Hi,

You're right that intermittent rules out the invoice ID collision: that one is deterministic, so every matching order would fail, not the occasional one. And since Worldpay does it too, and it has no PayPal invoice ID, we can set that track aside. What PayPal and Worldpay share is that both send the buyer off your site to the gateway after checkout, so the issue is most likely at that hand-off rather than PayPal itself.

On the confirmation page HikaShop auto-submits a form that forwards the buyer to the gateway. If that submit does not fire, the customer is left on your site with no way to pay, which matches what you describe. The most common device-related reason is the buyer being inside an app's built-in browser (Facebook, Instagram, Gmail...) instead of a normal browser: there the forward can open in a blocked popup and simply do nothing, which would be intermittent and look device-related since it depends on how each buyer reached your site.

To pin it down, next time it happens could you check:
- Does the customer stay on your site, or do they reach paypal.com and it is blank there?
- On the page they are stuck on, is there a "Pay now" button with a "click here if you are not redirected" message, or is it blank?
- Do the affected orders tend to come from an app's in-built browser rather than Chrome/Safari?

That will tell us whether it is the redirect being blocked, the page not loading fully, or something on the gateway side.

Hi,

Think would indicate a CSP issue.
Try disabling the HTTP header plugin and see if that helps.

Hi,

If you're able to reproduce the issue, open the console of your browser on the page with the issue. There, you should see a lot of information from PayPal about what is going on. That should allow us to tell you what to do.

Hi,

Ok. I've made changes to the PayPal Checkout plugin to be able to log that.
Download the install package of HikaShop on our website and install it on yours. Make sure the debug setting of the PayPal Checkout payment method in enabled.
Then, next time someone has the issue on your website, you'll get the debug data from the console in the "Payment log file" in the HikaShop configuration. So we'll be able to debug the issue even if it only happens in some rare cases.

Yes, please send it via email to the our contact email address.

Hi,

Thank you for the log file.

Your pages are currently sent with this header:

content-security-policy: default-src 'self' 'unsafe-inline'

That header tells the browser of your visitors to only load things coming from your own domain. It contains no script-src, no frame-src and no connect-src, so all three fall back on that default-src, and everything coming from PayPal is refused by the browser: the script www.paypal.com/sdk/js which draws the payment buttons, the frames the buttons are drawn inside, and the calls that script makes to PayPal. Your customer is then left with an empty payment area and no way to log into PayPal, which is exactly what they describe.


Where it comes from :

Not from the Joomla plugin this time, which is why disabling that plugin, as you did in February, does not fix it anymore. The header comes from your server, from the .htaccess file at the root of your website:

- your static files carry a Content-Security-Policy too ( www.mohairbearmakingsupplies.co.uk/media...hop/css/hikashop.css answers with "default-src 'self'; script-src 'none';"), and those files are served by Apache without Joomla ever running, so the header can only come from the server configuration
- your pages also carry the same policy a second time under the old name x-content-security-policy, which the Joomla plugin never sends

If you use a security extension which writes your .htaccess file for you, Admin Tools and its .htaccess Maker being the usual one, change the setting there and let it write the file again. If you edit the .htaccess file directly, your change will be lost the next time that extension regenerates it.

How to configure it :

Keep the header, but allow PayPal in it. The value to use in place of the current one:

default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://*.paypal.com https://*.paypalobjects.com; frame-src 'self' https://*.paypal.com; connect-src 'self' https://*.paypal.com; img-src 'self' data: https://*.paypal.com https://*.paypalobjects.com

Leave the rule for your static files alone, it is fine as it is and it does not concern PayPal.

If you ever go back to the "System - HTTP Headers" plugin of Joomla instead, the same thing is done in its "Content-Security-Policy (CSP)" tab, where you add one line per directive in the table at the bottom: script-src with the value 'self' 'unsafe-inline' https://*.paypal.com https://*.paypalobjects.com, then frame-src with 'self' https://*.paypal.com, then connect-src with 'self' https://*.paypal.com, and img-src with 'self' data: https://*.paypal.com https://*.paypalobjects.com.

One last thing, unrelated to the buttons :

Your log shows 62 payments refused by PayPal at the very last moment, against about 20 which went through. In each case the customer logged into PayPal and approved the payment, and when your website asked PayPal to take the money, PayPal answered:

DUPLICATE_INVOICE_ID: Duplicate Invoice ID detected. To avoid a potential duplicate transaction your account setting requires that Invoice Id be unique for each transaction.

The money is never taken and the order stays unpaid, while your customer believes they paid. The orders 92784, 92786, 92798, 92802, 92807, 92812, 92872, 92877, 92879 and 92884 are examples, and the most recent one is from the 4th of June. This is the setting I mentioned at the beginning of this thread: in your PayPal account, under Account Settings then Payment preferences, "Block accidental payments" has to be set to "No, allow multiple payments per invoice ID". PayPal names that setting itself in its answer, so it is still set the other way today.

Hi,

The 500 error is expected: that box takes Apache directives, not the value of the header. A raw "default-src 'self' ..." line is not a directive, so Apache refuses to serve the site. To set it there, it has to be:

<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://*.paypal.com https://*.paypalobjects.com; frame-src 'self' https://*.paypal.com; connect-src 'self' https://*.paypal.com; img-src 'self' data: https://*.paypal.com https://*.paypalobjects.com"
</IfModule>

content-security-policy: default-src 'self' 'unsafe-inline'
x-content-security-policy: default-src 'self' 'unsafe-inline'
content-security-policy-report-only: script-src 'self' 'unsafe-inline' https://*.paypal.com https://*.paypalobjects.com; frame-src 'self' https://*.paypal.com, then connect-src with 'self' https://*.paypal.com; img-src 'self' data: https://*.paypal.com https://*.paypalobjects.com; default-src 'self' 'unsafe-inline'; frame-ancestors 'self'