W3C home > Mailing lists > Public > public-payments-wg@w3.org > February 2019

Status of "Payment Tokens"

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 15 Feb 2019 10:33:19 +0100
To: Web Payments Working Group <public-payments-wg@w3.org>
Message-ID: <537052de-d8a7-d3a6-09c1-a8e11684c3b3@gmail.com>
https://www.w3.org/blog/wpwg/2018/11/02/tpac-2018-recap/

/*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.

/From what I can deduct there is currently no activity in W3C around this topic which is a pity since it has interesting qualities, although it requires quite elaborate security solutions to function since "redeeming" by an arbitrary Merchant to the Payer's Bank /without an intermediary/ certainly is anything but standard.

Anyway, if there is some interest in this matter you may take a peek in
https://github.com/w3c/payment-method-credit-transfer/issues/42#issuecomment-289415093
which is a working incarnation of a Payment Token scheme (if I understood it right...).  Although this solution uses a native "Wallet" it could without doubt use a Payment Handler to cater for step #3.  For Merchants this choice should be completely transparent.

Anders


/

/
Received on Friday, 15 February 2019 09:33:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 15 February 2019 09:33:46 UTC