EU e-commerce credit card transactions currently often redirect to the bank providing your card to authenticate before accepting the payment. The UX is very poor. The beneficiary of the check is the bank, but they tell you it is done for your own security.
For some reason, financial institutions are well trusted in Europe, regardless of recent behaviour.
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.
Just to be sure, if your business is domiciled outside of the EU (e.g. Australia), there is nothing to be done regarding SCA, right?
In other words, there's no risk with sticking to Stripe Checkout Legacy, even for European cards?
I have read some contradicting documentation.
[1] states the business AND customer must be in EU ("if all of the following apply"), [2] says "payments to European businesses or from European customers". :\
> While SCA is not legally required for businesses outside of Europe, we expect a small minority of European banks to require SCA for all payments regardless of where a business is located
I can believe this since the debit card associated with one of my european banks will only allow online transactions with 3DSecure.
> The beneficiary of the check is the bank, but they tell you it is done for your own security.
To clarify, this is about a liability shift. By putting customers through payer authentication, liability for fraud shifts to either the merchant or the customer, depending on the flow, rather than the bank. This is why the bank is the beneficiary.
SCA: https://stripe.com/en-US/guides/strong-customer-authenticati...
EU e-commerce credit card transactions currently often redirect to the bank providing your card to authenticate before accepting the payment. The UX is very poor. The beneficiary of the check is the bank, but they tell you it is done for your own security.
For some reason, financial institutions are well trusted in Europe, regardless of recent behaviour.
https://www.reuters.com/article/us-europe-moneylaundering-fa...