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

> I don't mean to express reticence. I'm still working on my understanding of the use 
> case and role of a standard. Please bear with me.

Cool. My bad. Sorry.

> Is the role you imagine for the standard to create a common request payload across those 
> payment methods that support disbursement?
> 

Yes. `each one would have its own internal approach to managing disbursements` **_BUT_** it is you and the Web Payments API that provide the Rosetta Stone or Payment Prism allowing Payment Handlers to standardize on disbursement instruction from the merchant. 

I know I have way over-simplified what needs to be done on the Payment handler end. (Some will want a flat commission, others charge plus commission, others commission free on the merchant account, volume discounts/penalties may cut in at X txns or Y $s, and so on . . .) but all of that down stream processing is ancillary to fundamental transaction processing of Joe Customer is paying $10.00 for goods and services.

We **_really_** need payment handlers to be driving the loop but it shouldn't take long. Please just ask everybody/anybody what business requirements and/or functionality is not supported by: -

```
total: {
       label: "Total due",
       amount: { currency: "USD", value: "65.00" },
       disbursement: [
           {
            payeeId: "XYZ",
            value: "5.00"
           },
           {
            payeeId: "ABC",
            value: "60.00"
           }
   }

```

No separate currencies.
Sum of the parts must equal the whole. (PH vetted not API)
Accounts must exist.
PaymentId is opaque and meaningful only to the handler.
*Maybe*: - If present and I don't support multi-accounts reject the promise.

Are you able to run that up the flag-pole with some Payment Handlers? Are there any here?

-- 
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-483932368

Received on Wednesday, 17 April 2019 04:28:27 UTC