Re: Proposal for a "Web Payments Digital Product Management API"

Why is the account owner not the authority on the amount to be withdrawn
from their account?

thx ..Tom (mobile)

On Sun, May 10, 2020, 5:42 PM Matt Giuca <mgiuca@chromium.org> wrote:

>
>
> On Sat, 9 May 2020 at 21:31, Nick Telford-Reed <nick@stormglass.consulting>
> wrote:
>
>> Doesn't removing amount as a mandatory field make doing the dynamic
>> linking element of PSD2 SCA super hard? +Adrian@coil.com - how would
>> your proposal work if the amount wasn't available from the requesting
>> merchant?
>>
>
> I'm unfamiliar with the details of PSD2 SCA. It appears to be a legal
> framework, not a technical spec, so it shouldn't be affected by the
> proposed change.
>
> We are not proposing making "total" generally optional (for all payment
> methods). Rather, it would become at the discretion of the user agent or
> payment handler when it is required (i.e., it would no longer be "required"
> in the WebIDL type, but the handler is allowed to throw an exception if
> it's not given).
>
> For traditional payment methods, this would still be required (otherwise
> there is no way to communicate to the payment provider how much money is
> actually being spent). But for some new payment modes such as the proposed
> Digital Product Management API
> <https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350>,
> the server is the source of truth on what the price of the item is, and
> requiring the payment amount to be given by the client is redundant.
>
>
>>
>> N
>>
>> On Wed, 6 May 2020, 6:10 am Chitalia, Jalpesh, <jchitali@visa.com> wrote:
>>
>>> That's a long time coming:  making amount optional in a payment request
>>> is essential, imho.  While amount is necessary to provide better secure
>>> experience / comprehension, there is also a point to be made for use cases
>>> (like one mentioned below) where amount is not available prior to
>>> requesting payment credentials and / or profile information (e.g. contact,
>>> delivery address).  And ideally, payment request should be flexible enough
>>> to provide options for existing and future merchant checkout experiences.
>>>
>>>
>>>
>>> -jalpesh
>>>
>>>
>>>
>>> *From: *Matt Giuca <mgiuca@chromium.org>
>>> *Date: *Tuesday, May 5, 2020 at 9:22 PM
>>> *To: *Rouslan Solomakhin <rouslan@google.com>
>>> *Cc: *Ian Jacobs <ij@w3.org>, "Liquan (Max) Gu" <maxlg@google.com>, Web
>>> Payments Working Group <public-payments-wg@w3.org>
>>> *Subject: *Re: FYI: Proposal for a "Web Payments Digital Product
>>> Management API"
>>> *Resent-From: *<public-payments-wg@w3.org>
>>> *Resent-Date: *Tuesday, May 5, 2020 at 9:21 PM
>>>
>>>
>>>
>>> Hi Web Payments folks,
>>>
>>>
>>>
>>> Thanks, as Ian said, feedback on the proposal is appreciated. (The
>>> latter was proposed by Max, not me.)
>>>
>>>
>>>
>>> I am putting together a more concrete explainer on this proposal which
>>> should hopefully be ready this week, but general thoughts on this direction
>>> are appreciated any time.
>>>
>>>
>>>
>>> Matt
>>>
>>>
>>>
>>> On Tue, 5 May 2020 at 05:22, Rouslan Solomakhin <rouslan@google.com>
>>> wrote:
>>>
>>> +Liquan (Max) Gu <maxlg@google.com> is also involved in this work and
>>> would appreciate feedback.
>>>
>>>
>>>
>>> On Mon, May 4, 2020 at 3:20 PM Ian Jacobs <ij@w3.org> wrote:
>>>
>>> Dear Web Payments Working Group,
>>>
>>> I came upon a somewhat recent proposal within the Web Incubator
>>> Community Group for a "Web Payments Digital Product Management API” that
>>> would work in conjunction with Payment Request. Here’s the proposal from
>>> Matt Giuca (of the Chrome Team):
>>>
>>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.wicg.io%2Ft%2Fproposal-web-payments-digital-product-management-api%2F4350&data=02%7C01%7Cjchitali%40visa.com%7Cfb0f602f2c754489d60008d7f1751e15%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637243357657200037&sdata=5WpUJu%2FfYpuY6c92%2B8cXor7QS6Tzvvh%2Fubsa3XZG5Pk%3D&reserved=0>
>>>
>>> Problem statement:
>>>
>>>    "The problem we are trying to solve is that Payment Request by itself
>>> is inadequate for making in-app purchases in existing digital stores,
>>> because that API simply asks the user to make a payment of a certain amount
>>> (e.g., “Please authorize a transaction of US$3.00”), which is sufficient
>>> for websites selling their own products, but established digital
>>> distribution services require apps to make purchases by product IDs, not
>>> monetary amounts (e.g., “Please authorize the purchase of SHINY_SWORD”);
>>> the price being configured per-region on the backend.”
>>>
>>> Matt Giuca raised an issue on the Payment Request API that would make
>>> the proposal easier to integrate:
>>>
>>>  Make "total" and "details" optional
>>>  https://github.com/w3c/payment-request/issues/912
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpayment-request%2Fissues%2F912&data=02%7C01%7Cjchitali%40visa.com%7Cfb0f602f2c754489d60008d7f1751e15%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637243357657210031&sdata=rnt%2FAwY7i4Y0a1zu8Gjdu9OEXccT9visFKbghU7AFvY%3D&reserved=0>
>>>
>>> I’m sure Matt would appreciate feedback on either or both of the
>>> proposal and the pull request. Thanks!
>>>
>>> Ian
>>>
>>> --
>>> Ian Jacobs <ij@w3.org>
>>> https://www.w3.org/People/Jacobs/
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FPeople%2FJacobs%2F&data=02%7C01%7Cjchitali%40visa.com%7Cfb0f602f2c754489d60008d7f1751e15%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637243357657210031&sdata=H7jKJfcD0tCZEby5Lh4ZqVqp21vEhb7q78WzEnX12Fg%3D&reserved=0>
>>> Tel: +1 718 260 9447 <(718)%20260-9447>
>>>
>>>
>>>
>>>
>>>