The first time I saw this flow I thought I was getting phished. It really is ridiculous how you get sent to a strange domain name which may or may not have the name of your card issuer in it.
For the average Web user, if you don't see a name you trust with an EV cert in friendly green in your address bar, you shouldn't be giving up the keys to your bank account. Plaid and (soon formerly?) Stripe embedding their widgets into the parent page are just training users to get scammed. I'm still beating this drum because it's still a serious problem and nobody seems to care.
In Plaid's case, the issue is twofold: (a) the chilling effect of "training to get scammed," as you mention; (b) the fact that Plaid's servers log into your bank account on your behalf without clearly disclosing that to the user (unless you have 2FA enabled, in which case they will helpfully instruct you to "disable extra security settings at sign-on"). In fact, it's worse than no disclosure, because Plaid imitates the branding of the login page of your bank.
The solution is obvious, although maybe less than palatable to the Plaid marketing department. Plaid needs to be extremely clear that it is logging into your bank account on your behalf (including detailed statements about security architecture and data retention). They should also stop appropriating the logos and login branding of banks.
In the case that Plaid is not doing this (maybe a few years from now every bank finally has an API, or maybe you use a bank that has one now), then they should use proper third party authorization flow with the bank, where the user explicitly grants privileges from their bank account to Plaid.
Regarding the topic at hand -- Stripe Checkout -- it's a bit disingenuous to equate its flow with Plaid's. The major difference is that Stripe is not logging into your bank account on your behalf without informing you.
The quoted language in my comment is some I have seen in a plaid powered app, where you need to press a button at your bank that says "disable extra security at sign-on" in order to disable 2FA.
The fact is, if you have 2FA enabled, plaid cannot login on your behalf. That said, it does seem technically possible for plaid scrapers to login, tell you to expect 2FA from your bank, and then echo your response back to the bank. But from what I've seen, they did not do this. Perhaps because they need to login at a later time, so they want to save your password and be able to login then.
EV is not a solution to any problem, much less this. This is a bigger problem with how the web communicates identity, I wouldn't really blame Plaid/Stripe/etc, their alternatives suck.
I think Stripe is a great example for this because in many cases, it's not actually clear where your credit card/etc is going, webpages just silently pass the form fields to Stripe.js.
Really the key is to have a TLS-secured connection to a domain that you trust. The EV cert is just icing on the top that anyone doing payments or bank integration should have. It's slightly harder for a scammer to get and keep an EV cert than a standard cert.
And you're right- the issue is with communicating identity to the user. The best way we have for doing this is to have the entire tab be served from the trusted domain, with the browser checking for mixed content to make sure your data is safe. But the problem is that Plaid and Stripe.js don't even support this basic mechanism for communicating to users that they're safe. Someone decided that a slightly slicker UX was worth totally giving up on this identity issue. I think it is fair to blame them for that.
