3 ms·

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice.

by pnt12 6y ago

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd. The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app. This is already possible in Portugal with an app where you can give a seller your phone number and it prompts you for payment. (might be something of a privacy issue, but it beats a possible fraud issue)

Xelbair 6y ago
Poland has a neat system - you input one time code into the sellers payment processor, and then you get to confirm the payment in your app. Code is one time use, valid for 2 minutes - and you can see all the details in the confirmation that comes from your banking app. you can also use the same system to tie your phone number to your bank acc, letting other people in this system send you money instantly without extra fees between different banks - and you only need to share your phone number.
Nextgrid 6y ago
Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid. We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).
- filleduchaos 6y ago
  3-D Secure was introduced in 2001. Additionally, I don't quite think making a payment is within the problem domain of OAuth. Most often I'm explicitly not trying to give the site access to my account - I'm trying to fulfil one request.
  - Nextgrid 6y ago
    > I don't quite think making a payment is within the problem domain of OAuth OAuth is merely a way to authorize access. Depending on which scopes are requested, it could be a one-off request. Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. Furthermore OAuth would improve recurring payments - the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed.
    - filleduchaos 6y ago
      > Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. No - access is assumed to last for a session. It is explicitly not one-off. "Offline access" allows the grantee to request new tokens without further input from the granter (via refresh tokens); it does not mean that access tokens can only be used once. 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token. > the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed. I fail to see how this is a feature of OAuth specifically.
      - Nextgrid 6y ago
        > access is assumed to last for a session Through proper scoping the "session" can be boiled down to "this single payment request, for X merchant and Y amount", so not a problem in practice? > 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token. 3D-Secure is terrible implementation, requiring the user to input potentially sensitive data into (what looks like) an iframe on a potentially untrusted webpage. There's no guarantee the 3D-Secure frame you see is real. OAuth in contrast relies on redirecting to your bank's website, so provided you check the domain and HTTPS is not compromised you can be guaranteed you're talking to your bank and not an impostor. 3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input. It's impossible to use on certain devices (TVs, etc) while OAuth supports alternative flows for exactly this purpose. > I fail to see how this is a feature of OAuth specifically. OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server, where as 3D-Secure authenticates the current transaction but otherwise you're still just handing over a card number and given the number is typically the same everywhere, the bank has no easy & reliable way to enforce per-merchant limits.
- pnt12 6y ago
  I don't like integrations such as oauth on mobile apps, where the URL is often hidden. Validating in some other application) website seems reasonable to me.
  - Nextgrid 6y ago
    That is an implementation detail - OAuth itself works on the basis of web URLs so it's absolutely possible to open the login URLs in the default browser instead of in a web view.
filleduchaos 6y ago
> users need to give free access to their credit card for payment, at the promise that the other party will play nice This is something I only encounter with American companies/sites/processors. When I shop or pay online locally, 3-D Secure is always required. It's kinda appalling how much of the web/online experience is negatively impacted by US norms.

by pnt12 6y ago

Xelbair 6y ago

Poland has a neat system - you input one time code into the sellers payment processor, and then you get to confirm the payment in your app. Code is one time use, valid for 2 minutes - and you can see all the details in the confirmation that comes from your banking app. you can also use the same system to tie your phone number to your bank acc, letting other people in this system send you money instantly without extra fees between different banks - and you only need to share your phone number.

Nextgrid 6y ago

Some countries have their own variations of this but they all feel half-assed to me and often rely on phone numbers or something equally stupid. We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).

filleduchaos 6y ago
3-D Secure was introduced in 2001. Additionally, I don't quite think making a payment is within the problem domain of OAuth. Most often I'm explicitly not trying to give the site access to my account - I'm trying to fulfil one request.
- Nextgrid 6y ago
  > I don't quite think making a payment is within the problem domain of OAuth OAuth is merely a way to authorize access. Depending on which scopes are requested, it could be a one-off request. Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. Furthermore OAuth would improve recurring payments - the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed.
  - filleduchaos 6y ago
    > Typically in webapps, access is assumed to be a one-off unless the "offline_access" scope is requested for example. No - access is assumed to last for a session. It is explicitly not one-off. "Offline access" allows the grantee to request new tokens without further input from the granter (via refresh tokens); it does not mean that access tokens can only be used once. 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token. > the website can request a max payment amount or frequency and the user (on their bank's authentication page) can further constrain those settings if needed. I fail to see how this is a feature of OAuth specifically.
    - Nextgrid 6y ago
      > access is assumed to last for a session Through proper scoping the "session" can be boiled down to "this single payment request, for X merchant and Y amount", so not a problem in practice? > 3-D Secure already allows users to grant one-time requests, without the song and dance of a useless access token. 3D-Secure is terrible implementation, requiring the user to input potentially sensitive data into (what looks like) an iframe on a potentially untrusted webpage. There's no guarantee the 3D-Secure frame you see is real. OAuth in contrast relies on redirecting to your bank's website, so provided you check the domain and HTTPS is not compromised you can be guaranteed you're talking to your bank and not an impostor. 3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input. It's impossible to use on certain devices (TVs, etc) while OAuth supports alternative flows for exactly this purpose. > I fail to see how this is a feature of OAuth specifically. OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server, where as 3D-Secure authenticates the current transaction but otherwise you're still just handing over a card number and given the number is typically the same everywhere, the bank has no easy & reliable way to enforce per-merchant limits.
pnt12 6y ago
I don't like integrations such as oauth on mobile apps, where the URL is often hidden. Validating in some other application) website seems reasonable to me.
- Nextgrid 6y ago
  That is an implementation detail - OAuth itself works on the basis of web URLs so it's absolutely possible to open the login URLs in the default browser instead of in a web view.

filleduchaos 6y ago

> users need to give free access to their credit card for payment, at the promise that the other party will play nice This is something I only encounter with American companies/sites/processors. When I shop or pay online locally, 3-D Secure is always required. It's kinda appalling how much of the web/online experience is negatively impacted by US norms.