> CSP should eliminate if not greatly reduce this attack surface.
Sure. Or just don't load untrusted 3rd party javascript in your payment form. No banner ads. No dodgy trackers. The page where a user enters their card information is a high security context.
No, you're missing a very important vector described in the post. It's not just about making the payment page secure. Indeed, many (most?) e-commerce websites already link off to a secure 3rd party payments page. The problem is that if the originating page gets compromised, it can replace the link off to the secure payment page with a link to a malicious page.
This is not theoretical. Many websites include a primary "marketing" site built in something like WordPress that links off to a more hardened "app" site for authenticated users with stronger security policies. If your marketing site gets compromised, malicious scripts can usually pretty easily replace links to your app site to a spoofed page.
Before HSTS & key pinning was a thing, most people who visited gmail still browsed to gmail via http which redirected to https. Because the original query wasn't secure, someone at defcon did a silent MITM of gmail by catching the insecure http requests and not redirecting them to https. Then they caught people's credentials that way and proxied the real gmail, with all the images flipped all the images upside down so people knew something was up.
Its interesting to think about web redirects as a kind of chain of trust. The earlier insecure request destroyed the security of the secure context established later.
Sure. Or just don't load untrusted 3rd party javascript in your payment form. No banner ads. No dodgy trackers. The page where a user enters their card information is a high security context.