[tqwhite]

I would use my debit card even if it behaved exactly like cash, ie, when the recipient got the money, my only way of getting it back is to sue them or call the police.

Obviously any electronic payment system needs to be secure internally but society lasted a long time and made fine progress when having your wallet stolen meant losing your money.

It would be fine to require a person to charge their debit card with a finite amount rather than have it be funded up to the limit of the supporting account and that would solve the last problem compared to cash.

[margalabargala]

I understand that Europe is more secure with chip+pin, but in the US, debit cards do exactly what you describe. If fraud happens, you are out money until it is resolved.

The key difference from cash, in the US, is the ability to abuse cards at a later date without the physical card. For someone to steal your wallet, they have to be colocated with you and can only steal as much as you're walking around with.

As long as debit cards have a magnetic stripe and have their full number printed on them, and that information is useful, this problem remains.

[Deathmax]

> As long as debit cards have a magnetic stripe and have their full number printed on them, and that information is useful, this problem remains.

Which the EEA/UK has also (partially) solved by enforcing Strong Customer Authentication (SCA) that mandates that (most) transactions require MFA.

[Nextgrid]

I don’t believe SCA is enforced by the bank. It’s voluntary by the merchant. It acts as a liability shift but won’t save you from someone not caring about it and emptying your account (temporarily until the chargeback goes though). I don’t think any bank offers an option of “allow SCA-only transactions” and I don’t think it would be even possible (I’m not sure there is any token/session identifier to tie the SCA request and the actual subsequent transaction even).

When adding a card to a taxi app for example I get SCA prompt for a zero amount, but then they can charge me for any amount without subsequent SCA flows.

Presumably those subsequent transactions wouldn’t have a liability shift to the issuer but it still means that they can at least temporarily steal all your money until your chargeback claim goes through.

The whole concept of “card number” is rotten. What’s needed is an oAuth2-type system where every payment needs to redirect to the bank (actual redirect, no stupid hacky iframe like SCA/3DSecure is) and where you can see the merchant and set the max amount (and whether one-off or recurring) and the bank records that and keeps a list of authorized merchants so you can revoke them at any time. The merchant then must use this token to pull money, and can't pull more than what the token allows - just like your usual oAuth2 scopes.

[zinekeller]

This is not right at all (it's mandatory fo all banks and merchants in the EEA), although you're correct that SCA still has loopholes (like a US merchant... just trying, although a bank could just mandate 3DS to solve that).

[Nextgrid]

How do you explain the example I gave where the taxi app only has to SCA me once and not upon every transaction? This is in the EU.

What I suspect is that the "mandatory" bit is by law (and the law has flexibility, which covers this taxi app scenario) but there is no technical solution to make it mandatory, thus a non-compliant merchant can still drain your account until your chargeback claim goes through.

[zinekeller]

You're right that it's not fully enforced technically. It's complicated, and I don't think that's really solvable by technology (being that this scenario is roughly equivalent to direct debiting). Banks can validate if a particular merchant has already been used by a customer and blocking them from debiting your account, but since that SCA has exceptions for recurring debiting, this is not really enforcable once the customer has authorized the merchant for any debiting.

[margalabargala]

Yeah, Europe is ahead on this; I hedged my earlier statements heavily.

It's not a difficult technological problem to solve. A card's chip should be able to guarantee that the card is physically present for any transaction.

Obviously online payments would pose a problem, people would need to either own USB card chip readers or banks would need to do something new and special.

[felurx]

In Germany (/ the EU?) we have electronic ID cards that can be used for a few online services.

The physical card can communicate via NFC, and there's a smartphone app you can use with it. For PCs, you can buy some fancy NFC interface if you want, but you can also have your phone act as a reader, the PC connects to it over the local network.

Maybe something similiar could work for banking cards. They all have NFC anyways.

On the other hand, you might as well just have an app that is registered with the bank on your computer/phone (like how it works for smartphone NFC payments) and skip the card.

[oneplane]

Online payments are done using pretty much the same system. Instead of the chip, you get either a 2nd authentication mechanism, or start out with a strong token (be it the strength of the token itself, or the stability of it).

An older example was getting transaction authorisation numbers. You would either get a long indexed list on paper, or you could receive then over the phone (voice or text). This was then mostly replaced (about 10 years ago) with hardware (H/T)OTP type tokens that required your card to be inserted in the token and PIN authenticated. Later on that too was replaced by a cardless version, and that one then was replaced (for consumers) with mobile apps.

The combination of minimum software versions, online authentication, transaction limits, daily limits, and time-locked temporary limit increases (so you can buy a car with your phone, but you have to up the limit a couple of hours ahead of time for it to take effect) make it pretty safe with acceptable risk for the bank. And then there's of course the standard fraud detection and prevention departments, so if you do something unusual that also involves a lot of money, you're likely going to get a call.

For business use, there are other systems, generally two types like EU-wide smartcards or bank-specific smartcards that can be used to authenticate and authorise. You'd use an USB or NFC connected method for that. Sometimes that involves entering a PIN on the device itself before the computer can talk to it, but that does make the OTP exchange very fast. You'd still have limits or multiparty authorisation setup in your organisation so you don't end up with one person just moving a couple of 100K around on their own.

And then there's some overlapping systems, apparently this one is going EU-wide: hhttps://en.wikipedia.org/wiki/EIDAS and apparently some implementations include useful things: https://www.idin.nl/en/businesses/ like age confirmation where the business doesn't need to know who, what or where you are just if you're of age (and not even a specific age). Granted, nothing is perfect, but it's a whole lot better than finding some S3 bucket somewhere with JPEGs of ID cards. As long as they don't do dumb stuff like trying to MITM TLS, it's progress. The overlap is in the concept where you can use some electronic means to prove who you are to get something done.