Yeah. It’s really a UI issue at this point. Just a simple frontend to facilitate SEPA transactions to contacts (which could just be a simple Name -> IBAN map stored locally)
I could imagine something like an IBAN protocol - open an IBAN link as in iban://AB26374838388 directly with your banking app and auto fill the bank transfer menu. Only add the amount of money you want to transfer.
No idea what other implications that would have e.g. for security though
I thought about that, but I think it’s actually more error prone, because people might just be setting ?amount=32 and leaving out currency which might lead to unexpected behaviour. Implementors tend to interpret this differently and one app might take the default currency and the other might fail to accept it, and that kind of different behaviour is a common source of security issues. Having a single unified parameter that must always contain the value and currency “solves” that issue.
Makes it a bit more annoying to parse, though I definitely see your point.
However, you’re still proposing a standard: “has to include both the currency and the amount in the parameter”, so why not split them up at that point?
There’s still plenty of steps that your bank app can (and will) take to verify this is as intended. Requiring the user to “parse” the URI is not scalable anyway, the app needs to present the information clearly (i.e. "Do you really want to transfer 123.45€ to IBAN abcd, you have not transferred money to this IBAN before, the IBAN indicates a bank in " where the money amount is clearly highlighted).
I agree, still having to input the money manually is the best failsafe, how many people are used to just automatically hitting whatever button to make a message go away for example (even more with the cookies), best failsafe is inputting the money manually, you’d never mistakenly/automatically do that.
Main problem I see is that as it stands it’s insanely easy to forge a SEPA mandate. Ever had to fill one out? It’s literally just a piece of paper saying “I, John Doe, allow XXX to take money for services rendered from my acount AB1234. [signature]”. The wonder of legacy processes built for companies with fax-based workflows…
I believe only some “trusted” commercial customers are authorized to turn in SEPA mandates (I know my ISP went into some bankruptcy proceedings and lost their ability to use their SEPA mandates for instance), but still, that makes me somewhat wary about who I give my IBAN to. I’d certainly not put it up online for anyone to see.
Alternatively, let’s kill contact lists completely and do this some other way. Contact lists are already a privacy disaster, allowing users to compromise all their friends’ personal information without a hint of consent.
Speak for yourself. Speaking for myself, I don’t even use my contacts app for this reason. When the “current best solution” involves telling Big Tech the identity particulars of all your friends, it is not a solution to anything. If this had not been normalized by Google and Apple 15 years ago, it would surely be illegal.
Well pardon me but “Jesus Christ” perhaps some of your friends never asked you to share their names and phone numbers with Google or anyone else just because it makes life convenient for you.
Yeah. It’s really a UI issue at this point. Just a simple frontend to facilitate SEPA transactions to contacts (which could just be a simple Name -> IBAN map stored locally)
I could imagine something like an IBAN protocol - open an IBAN link as in iban://AB26374838388 directly with your banking app and auto fill the bank transfer menu. Only add the amount of money you want to transfer.
No idea what other implications that would have e.g. for security though
Oh, add an
?amount=32€as well as atext=Pizzaparameter and you’re almost there …Separate
?amount=32andcurrency=Euroto add currency support.I thought about that, but I think it’s actually more error prone, because people might just be setting
?amount=32and leaving outcurrencywhich might lead to unexpected behaviour. Implementors tend to interpret this differently and one app might take the default currency and the other might fail to accept it, and that kind of different behaviour is a common source of security issues. Having a single unified parameter that must always contain the value and currency “solves” that issue.Makes it a bit more annoying to parse, though I definitely see your point.
However, you’re still proposing a standard: “has to include both the currency and the amount in the parameter”, so why not split them up at that point?
Dammit we’ve just made UPI
Idont’t think that’s a good idea, too many peoplr quickly pressing pay and then they tealizef only afyer paying thay there’s an extra 0
There’s still plenty of steps that your bank app can (and will) take to verify this is as intended. Requiring the user to “parse” the URI is not scalable anyway, the app needs to present the information clearly (i.e. "Do you really want to transfer 123.45€ to IBAN abcd, you have not transferred money to this IBAN before, the IBAN indicates a bank in " where the money amount is clearly highlighted).
I agree, still having to input the money manually is the best failsafe, how many people are used to just automatically hitting whatever button to make a message go away for example (even more with the cookies), best failsafe is inputting the money manually, you’d never mistakenly/automatically do that.
You know, it’s good to put failsafes and all, but at some point it’s just PEBKAC.
Ah yes, PEBKAC, the most common error after ID-10T.
There’s a standard that does this in form of a QR code: https://en.wikipedia.org/wiki/EPC_QR_code
True, my bank also supports this. I already saw QR-Codes on some invoices but never used it… will try it out next time.
Main problem I see is that as it stands it’s insanely easy to forge a SEPA mandate. Ever had to fill one out? It’s literally just a piece of paper saying “I, John Doe, allow XXX to take money for services rendered from my acount AB1234. [signature]”. The wonder of legacy processes built for companies with fax-based workflows…
I believe only some “trusted” commercial customers are authorized to turn in SEPA mandates (I know my ISP went into some bankruptcy proceedings and lost their ability to use their SEPA mandates for instance), but still, that makes me somewhat wary about who I give my IBAN to. I’d certainly not put it up online for anyone to see.
Didn’t know it was this simple, that’s stupid.
I believe though that in today’s day and and of banking apps this should be very easily solvable with inapp confirmations
Let’s hope the old way dies
Alternatively, let’s kill contact lists completely and do this some other way. Contact lists are already a privacy disaster, allowing users to compromise all their friends’ personal information without a hint of consent.
I’d suggest providing alternatives before killing the current best solution
Speak for yourself. Speaking for myself, I don’t even use my contacts app for this reason. When the “current best solution” involves telling Big Tech the identity particulars of all your friends, it is not a solution to anything. If this had not been normalized by Google and Apple 15 years ago, it would surely be illegal.
Jesus Christ then don’t use it if you mind, but overall, it’s the best solution for keeping track of people’s phone numbers.
You’re saying kill it but not offering a better choice, you’ll never accomplish anything like this.
Well pardon me but “Jesus Christ” perhaps some of your friends never asked you to share their names and phone numbers with Google or anyone else just because it makes life convenient for you.
Maybe I’m missing something here, don’t we already have this UI from our banking apps?
deleted by creator