NoScript intervention in online transaction verification

[grahamt]

I'm having problems with NoScript intervening in the online credit card transaction verification process. I need to know how I get around the problem.

When I carry out an online credit card transaction the vendor accepts my credit card details but then passes me to another website to carry out transaction verification. I will not be likely to know in advance the domain name of the website to which I am going to be passed and so cannot pre-authorise it but in most cases it requires Javascript to be activated. However, it is already too late because NoScript has already intervened in the display of the new website and in consequence has killed the transaction because I have not been able to enter the verification information required.

What I need is some way of NoScript asking for permission to continue with the display of the security verification webpage rather than blocking it outright.

[Giorgio Maone]

Do you get a XSS warning?
If so, did you try to use the "Unsafe reload" command from the Options menu on it?

[grahamt]

It's the reload that's the problem. Because of the order in which the transaction takes place, reloading the page is inadvisable as it may result in the transaction being processed twice rather than not at all. One is as bad as a the other!

What would be best is that if you are on a website where you know in advance that you are going to process a financial transaction online but you don't initially know which website URLs are going to be involved, because the company passes you across their own and external service provider websites, to be able to have an option which effectively says, "If the domain name changes from this point onwards, I won't block the new webpage but I will ask you if you want to proceed before displaying it and if you do will assume you are authorising the new domain."

[Giorgio Maone]

It's the reload that's the problem. Because of the order in which the transaction takes place, reloading the page is inadvisable as it may result in the transaction being processed twice rather than not at all. One is as bad as a the other!

Nope, the "Unsafe reload" doesn't produce this side effect, because the POST payload had previously discarded turning the request into an idempotent GET request, and therefore no transaction took place yet.

to be able to have an option which effectively says, "If the domain name changes from this point onwards, I won't block the new webpage but I will ask you if you want to proceed before displaying it and if you do will assume you are authorising the new domain."

That's something which deserves to be considered, in one form or another. Thanks for the suggestion.

[Alan Baxter]

It's the reload that's the problem. Because of the order in which the transaction takes place, reloading the page is inadvisable as it may result in the transaction being processed twice rather than not at all. One is as bad as a the other!

Nope, the "Unsafe reload" doesn't produce this side effect, because the POST payload had previously discarded turning the request into an idempotent GET request, and therefore no transaction took place yet.

An issue here is that a normal user doesn't know that when the problematic transaction happens. A cautious user won't do an "Unsafe reload" without checking here first, which makes for quite a usability issue. Sorry I can't suggest a solution.