Re: [w3c/payment-handler] "Middleman Id/Commission %/Payeeer" provision (#335)

> In practice, each system is going to have its own internal identity system ("XYZ", "ABC", etc.).

Absolutely, as honoured and reflected in the existing spec eg: -

```
       supportedMethods: "https://example.com/bobpay",
       data: {
             merchantIdentifier: "XXXX",
```

> If we expected disbursements to be handled by "arbitrary" payment handlers, having a 
> standardized description of identity would make sense. 

Last time I retorted with the classic "*`IF`* your Aunt had balls she'd be your Uncle!" I got accused of being "transphobic" so let me instead just point out that the existing Payments API has never catered for "arbitrary" payment handlers.  The level of standardization required is simply a recognized slot for merchants to communicate with payment handlers.

My proposed "disbursement" dictionary is analogous to the Web App Manifest(s) identified by the PWA/merchant in the Payment Handler Manifest. That is, meaningful only to the target payment handler.

> Perhaps the piece I am missing is: what is the use case where the disbursement could be 
> carried out within a payment method not already known by the merchant? 

Forgive me if I bristle but currently, apart from basic-card, which payments can `be carried out within a payment method not already known by the merchant?` 

The use case is unchanged from that I outlined previously: -

The merchant has pre-approved a number of modern payment handler(s) knowing they support multi-party transactions. The necessary payment handler hooks have been identified and registered in the Payment Handler Manifest. The PWA/Super-Mini-Cabs/Me can rest/code safe in the knowledge that regardless of the end/chosen Payment Handler, the *generic* disbursement dictionary will cater for the handshake/instruction.

This simply must be standardized/made available!

Once again, let me stress the goals of your spec: -

> 1.1 Goals and scope
> 
> Standardize (**to the extent that it makes sense**) the communication flow between a merchant,
> user agent, and payment method provider.

Cheers Richard

BTW. What App/ServiceWorker is used for "basic-card"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/335#issuecomment-484325772