I know FIDO will be in charge of this, but please don't make web payment authentication or any other "next-gen" authentication APIs biometrics-only. At least make it so people can use 2 or even 3 factors at the same time to authenticate, such as say fingerprint, USB key and Bluetooth-enabled unlock from a close device. Or face + fingerprint + password. Or face + gestures + voice, and so on.
The goal of the Web Payements API, from what I understand, is not to create new mechanisms, but to enable websites to leverage existing payment instruments via a standard JS API, with the browser acting as an intermediary.
It’s up to the browser and/or OS to manage the user’s payment instruments and provide them to websites that use the API.
Is it supposed to help people which have a distinct set of payment instrument than the retailer?
Is it one the roadmap?
For me, one of most important problem is the inability for small payment processor to enter the field because now if amazon, eBay, steam, etc... don't include your payment scheme you're better be ready for a though (impossible?) battle.
That's one reason the payment industry stagnate so much.
Could you give an example of such a payment scheme? I’m only aware of two payment options: (1) credit card, (2) a payment service like PayPal, Amazon, Google, Apple, etc.
I'm not sure I've used the right terminology, so please forgive me if I misuse some terms.
As an example in Switzerland most online retailers allow you to pay with a Postcard. ( https://www.postfinance.ch/en/priv/prod/card/pfcard/direct/o... )
I would have hoped that PostFinance, the issuer of the card, would be able to implement some standard that would allow it's client to pay retailers that implement such standard.
Switzerland has only 8 millions inhabitant, It's certainly not enough to convince big tech companies to add it as a payment option.
This would probably require some standardization of payments settlement and funding, which is probably the harder part of this.
On top of that, all these different payment systems have different fee structures, so it's unclear how this could be completely in the user's control, since the merchant probably won't be happy to accept arbitrary fees, unless the fee was levied on the user, rather than the merchant, which would be a pretty big difference.
Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-04) is/was part of Web Payments, although that draft expired in July, and it's not mentioned on this roadmap. I wonder what's happening to it. It will be a useful standard; HTTP signing is currently fragmented into many vendor-specific schemes.
Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-04) is/was part of Web Payments, although that draft expired in July, and it's not mentioned on this roadmap. I wonder what's happening to it. It will be a useful standard; HTTP signing is currently fragmented into many vendor-specific schemes.
12 comments
[ 4.2 ms ] story [ 42.9 ms ] threadIt’s up to the browser and/or OS to manage the user’s payment instruments and provide them to websites that use the API.
For me, one of most important problem is the inability for small payment processor to enter the field because now if amazon, eBay, steam, etc... don't include your payment scheme you're better be ready for a though (impossible?) battle. That's one reason the payment industry stagnate so much.
As an example in Switzerland most online retailers allow you to pay with a Postcard. ( https://www.postfinance.ch/en/priv/prod/card/pfcard/direct/o... ) I would have hoped that PostFinance, the issuer of the card, would be able to implement some standard that would allow it's client to pay retailers that implement such standard.
Switzerland has only 8 millions inhabitant, It's certainly not enough to convince big tech companies to add it as a payment option.
On top of that, all these different payment systems have different fee structures, so it's unclear how this could be completely in the user's control, since the merchant probably won't be happy to accept arbitrary fees, unless the fee was levied on the user, rather than the merchant, which would be a pretty big difference.