[Openid-specs-fapi] W3C consider a PaymentToken concept
anders.rundgren.net at gmail.com
Wed Dec 26 07:18:03 UTC 2018
"For the second topic, Generic Payment Tokens, Adrian described the pitfalls of push payment flows: where the user’s bank initiates a payment (e.g., credit transfer) outside of the control of the merchant. Adrian offered an alternative flow where the party that initiates a pull payments returns a (“redeemable”) generic token through Payment Request API. The merchant can subsequently use the token to initiate the payment from the user’s bank. (I believe this is how direct debits work; please comment below if I am mistaken.) Adrian described a vision where merchants would declare through Payment Request API “I accept the generic token payload from the following networks,” and this would enable payment handlers to innovate and support different payment networks"
This appears to be quite similar to the Saturn[1,2] concept. That is, redeeming can (in this particular payment scenario NB), be performed by a Merchant directly to the User's Bank.
However, creating yet another API for Payment Tokens that banks would have to implement severely limit the possibilities launching such a scheme.
Voila! Although not in any way tested, Open Banking APIs used entirely locally may provide the necessary functionality:
1] General information: https://cyberphone.github.io/doc/saturn/
2] Authorization state diagram: https://cyberphone.github.io/doc/saturn/saturn-authorization.pdf
More information about the Openid-specs-fapi