Card payment no longer works with PM

[LuftWafflePilot]

It's been maybe a week or two max. since randomly I noticed that any card payment I try to make in PM fails (as in the pay gate simply saying the transaction failed). It doesn't seem to matter what eshop I use or what pay gate they use, it simply fails.
Is this something anyone else noticed?
It wasn't until yesterday when I tried to pay for stuff from Firefox, and it simply worked.
It feels like all these Cloudflare problems that happen every once in a while, but it's weird I have never experienced it before.

[moonbat]

You've been here long enough to know the drill when reporting any problems, so why haven't you provided even the URL of the gateway on question, let alone any other troubleshooting info? I have zero problems making payments with my bank, Paypal, Amazon and a few other places.

[Moonchild]

Might also want to do a malware check on your system.

[BenFenner]

My first guess was malware as well, or a borked PM profile/install.

All my credit card transactions have also been fine.

[LuftWafflePilot]

You've been here long enough to know the drill when reporting any problems, so why haven't you provided even the URL of the gateway on question, let alone any other troubleshooting info? I have zero problems making payments with my bank, Paypal, Amazon and a few other places.

I am not trying to troubleshoot anything yet (hence why it's in general discussion section), I'm trying to figure out whether anyone else has been seeing that very recently, which would indicate something changing over at those companies or the higher up payment systems out there.
For the record, I am NOT talking about internet banking, Paypal or Amazon (which is an eshop).
I am talking about any random eshop that lets you pay with a credit card. The interface between them and the card companies is what seems to be failing for reasons I do not understand.

But to name something, one such provider or interface or whatever it is is Gopay. I really don't feel like buying random stuff at random eshops just to see how many payment interface systems are out there and what is failing where.

Re: malware, that's a negative.

P.S. I am from Europe. I know (or up until now believed) online payment is completely different in the U.S.

P.P.S. Borked profile, I don't think so, I created a new one after the webcomponents update to PM landed and haven't touched anything about it since. I don't even use any extensions besides Ublock origin.

[moonbat]

I don't even use any extensions besides Ublock origin.

Check if you're blocking anything from the gateway in question. These can require third party scripts to work. uBO's log should show you what's been blocked.

[LuftWafflePilot]

But that makes no sense, I made literally zero changes to anything browser related since I created the new profile. Ublock is always updated too.

Anyway I have just had the chance to order something.
This is what error console showed after clicking pay in the eshop:

Code: Select all

Timestamp: 28.07.2023 9:10:17
Warning: Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.
Timestamp: 28.07.2023 9:10:18
Warning: Strict-Transport-Security: The site specified a header that could not be parsed successfully.
Source File: https://secure.checkout.visa.com/checkout-widget/resources/js/src-i-adapter/visaSdk.js
Line: 0
Timestamp: 28.07.2023 9:10:18
Warning: unreachable code after return statement
Source File: https://src.mastercard.com/QUN4/bJen/wkVYx/SKvlA/N77Qzb2rmcJa/FwcsSHIcHw0/QH/ZqKBcQaAI
Line: 1, Column: 211116
Source Code:
L9,VS,KB,vg,F5,k9,DK;var tUM;var QUM;var Er;var lKM;var CKM;Q8M;}());
Timestamp: 28.07.2023 9:10:18
Warning: Content Security Policy: Couldn’t process unknown directive ‘script-src-elem’
Timestamp: 28.07.2023 9:10:18
Warning: Content Security Policy: Couldn’t process unknown directive ‘report-to’
Timestamp: 28.07.2023 9:10:19
Error: SecurityError: The operation is insecure.
Source File: https://secure.checkout.visa.com/checkout-widget/resources/vba/js/vba-3.1.4.min.js
Line: 2
Timestamp: 28.07.2023 9:10:19
Warning: Strict-Transport-Security: The site specified a header that could not be parsed successfully.
Source File: https://secure.checkout.visa.com/logging/logEvent
Line: 0
Timestamp: 28.07.2023 9:10:32
Warning: Content Security Policy: Ignoring ‘report-uri’ since it does not contain any parameters.

But then the payment went through. I will have to try the first eshop again when I have the chance. Or maybe the card company fixed it meanwhile.


P.S. Why do I have to copy line by line in the console instead of being able to select all?

[Moonchild]

But that makes no sense, I made literally zero changes to anything browser related since I created the new profile.

Just because you didn't change anything, doesn't mean it'll remain working if they change stuff on their side.

Seems it's actually your card processor's payment gateway that is the problem which would explain why you've seen issues over multiple sites when trying to pay.

The code you quoted from the console indicated they have several issues with their CSP, most likely trying to strictly lock down and control how resources are being loaded in their checkout.
Also "code after return statement" is at the very least sloppy scripting, and could actually be a bug in their code, too. Of course being minimized and obfuscated, we can't really do anything with it. But, you could possibly report this to visa.com if the problem persists. Yes they will probably just tell you to use spyware (Chrome) instead, but if enough people point this out it may just get solved.

[Lucio Chiappetti]

I continue in a different sectio with a similar case viewtopic.php?f=70&t=30127

[Fil453]

and everyone has cloudflare ?

[LuftWafflePilot]

And it happened again...
No errors in console at all, so it must be incompatibility with PM on their end.

Screenshot 2023-08-13 125348.png

[LuftWafflePilot]

comgate.cz seems to persistently refuse to work with PM.
https://pay2.comgate.cz/status/5HAM-TUOL-T4GR

Code: Select all

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://payments.comgate.cz/client/journal?id=5HAM-TUOL-T4GR. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).  
(unknown)
Content Security Policy: Couldn’t process unknown directive ‘style-src-elem’  
(unknown)
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.  
(unknown)
Content Security Policy: Couldn’t process unknown directive ‘report-to’  
(unknown)
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://payments.comgate.cz/client/instructions/outages?id=5HAM-TUOL-T4GR. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).  
(unknown)
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://payments.comgate.cz/client/instructions/load?id=5HAM-TUOL-T4GR&restart=false&needStyle=true&iframe=false. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).  
(unknown)

[Moonchild]

Code: Select all

Reason: CORS header ‘Access-Control-Allow-Origin’ missing

We're doing exactly what we should, which is to not allow same-origin violations without the required CORS header being sent by the web server.

[Kris_88]

We're doing exactly what we should, which is to not allow same-origin violations without the required CORS header being sent by the web server.

The server doesn't seem to know how to properly respond to an OPTIONS request. MS Edge asks for GET immediately, while Pale Moon asks for OPTIONS first. Of course, if I interpret the protocol correctly and the browsers do not hide anything.
Based on the logs, the response to the OPTIONS request is missing the "Access-Control-Allow-Origin" header. But this header is in the response to the GET request.

EDIT:
I can confirm the same (as in MS Edge) behavior in FireFox 105 - the OPTIONS request is not sent for this URL:

Code: Select all

https://payments.comgate.cz/client/instructions/outages?id=5HAM-TUOL-T4GR

[Moonchild]

Well, that URL returns a 500 error with a "not found" message from their Zend framework, so I can't really do much more about this to find out what's going on with that.

[Kris_88]

Well, that URL returns a 500 error with a "not found" message from their Zend framework, so I can't really do much more about this to find out what's going on with that.

Are you trying to open that URL directly? Indeed, we get "Not found" in this case.

In fact, this URL is requested by a script from the page
https://pay2.comgate.cz/status/5HAM-TUOL-T4GR
And in this case we get 204 in response to the OPTIONS request.

UPDATE:

Great, I think I've caught the reason.
In fact, a preflight request is also generated in FF the first time the page is accessed, but then the cache prevents it from being sent.
The difference is that the preflight request does not contain a referer and then the response does not contain access-control-allow-origin and the page does not work. PM32.5 also does not send a referer in a preflight request.


FF63: No referer, no access-control-allow-origin response, page does not work.

63.png

PM320502: No referer, no access-control-allow-origin response, page does not work.

PM320502.png

FF65: +referer, +access-control-allow-origin response, page works.

65.png

[Kris_88]

No Referer header in CORS request from IE or Firefox
https://stackoverflow.com/questions/321 ... or-firefox

"In Chrome, this works as expected - OPTIONS preflight request is sent to server, server responds with access control headers, POST request is sent. When I try to do this in IE or Firefox, no referer is sent with the OPTIONS request ... "

[Moonchild]

Sorry, but I think Chrome does not follow the standard then (and neither does Firefox since they became more Chrome like in this respect...)

The request is sent from pay2.comgate.cz and the OPTIONS request is made to payments.comgate.cz -- that is a cross-origin request.
The standard does not have any special behaviour for OPTIONS, so the default rules apply:

A user agent SHOULD NOT send a Referer header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent.

A preflight request will not have explicit CORS permissions (since it happens before CORS headers are known) and are inherently insecure, so a referer should not be sent.

Please let me know if I somehow misunderstand this...

[Kris_88]

A user agent SHOULD NOT send a Referer header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent.

Yes, it seems logical...
But there is such an interesting thing:

65b.png

Either the site indicated this or FF used some kind of default...

[Moonchild]

Looks like FF just started wholesale ignoring that and always allowing it, contrary to the spec. bug #1720294