Difference between revisions of "Web Payments"
From MgmtWiki
(→Full Title or Meme) |
(→Context) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
==Context== | ==Context== | ||
* Payment Request API was originally focused on streamlining checkout ie. extracting money from the user was fast as possible. Security of user assets was not a goal. | * Payment Request API was originally focused on streamlining checkout ie. extracting money from the user was fast as possible. Security of user assets was not a goal. | ||
| − | * in late 2020 the focus switched to methods that are of "High Value to the industry", namely low | + | * Payment Handler API designed to operate in the client. |
| + | * in late 2020 the focus switched to methods that are of "High Value to the industry", namely low [[Friction]] user authentication. Security of user assets is still not a goal. | ||
* [[Open Banking]] mean which has focused on [[Secure Customer Authentication]], again focusing on the needs of the Financial Sector not on the consumer. | * [[Open Banking]] mean which has focused on [[Secure Customer Authentication]], again focusing on the needs of the Financial Sector not on the consumer. | ||
| − | * Solving the "NASCAR Problem" of | + | * Solving the "NASCAR Problem" of too many options was rejected by brands that wanted to be in the consumers face and merchants that wanted to control the order of brands on their site. |
| + | * User experience and merchant demands also diverged on where to store "card on file" data. It's clear that W3C is on the side of the merchants. | ||
| + | * The challenges of improving privacy in the browsers to block user tracking, also blocks use of tracking to support authentication of 3rd Party sites. (Also called federated sites.) | ||
| + | * User privacy generally makes risk assessment more difficult, but the W3C seems to think it can provide both. We already know which side the W3C supports. | ||
==References== | ==References== | ||
* [https://www.w3.org/2020/Talks/ij_wpwg_202008/index.html Web payments S4 2020 from W3C WPWG] | * [https://www.w3.org/2020/Talks/ij_wpwg_202008/index.html Web payments S4 2020 from W3C WPWG] | ||
| + | * [https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography Google Web Payments] | ||
| − | [[Category: Finance] | + | [[Category: Finance]] |
| − | [[Category: Standard] | + | [[Category: Payment]] |
| + | [[Category: Browser]] | ||
| + | [[Category: Standard]] | ||
Latest revision as of 11:24, 10 July 2022
Full Title or Meme
Web Payments as implemented by the W3C and browser manufacturers as opposed to Open Banking as implemented by the banks.
Context
- Payment Request API was originally focused on streamlining checkout ie. extracting money from the user was fast as possible. Security of user assets was not a goal.
- Payment Handler API designed to operate in the client.
- in late 2020 the focus switched to methods that are of "High Value to the industry", namely low Friction user authentication. Security of user assets is still not a goal.
- Open Banking mean which has focused on Secure Customer Authentication, again focusing on the needs of the Financial Sector not on the consumer.
- Solving the "NASCAR Problem" of too many options was rejected by brands that wanted to be in the consumers face and merchants that wanted to control the order of brands on their site.
- User experience and merchant demands also diverged on where to store "card on file" data. It's clear that W3C is on the side of the merchants.
- The challenges of improving privacy in the browsers to block user tracking, also blocks use of tracking to support authentication of 3rd Party sites. (Also called federated sites.)
- User privacy generally makes risk assessment more difficult, but the W3C seems to think it can provide both. We already know which side the W3C supports.
