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

> The value comes from allowing SMC to provide support for a variety of providers. With a standard API. Is your contention that SMC should just really cater for native bespoke Javascript libraries from each payment provider?

I think so, if we are talking about the same thing. If you look at my example code, there are 3 payment methods that the merchant accepts and all have different ways of expressing split disbursement.

That example would work with the API as it is today. No changes needed.

However, I am contending in observation 1 that it's even simpler than that. Since the merchant (SMC) already knows the payment method that the affiliate (Fred) has chosen to receive their disbursement with they can make the API call with only the disbursement details for that payment method.

I.e. If Fred chose Square then why would SMC call PR API with options for the rider to pay via PayPal?

If you are talking about the rider paying via PayPal and Fred still getting paid via Square then we're in a whole new regulatory realm where someone is acting as an intermediary and receiving the funds via PayPal first before making the payout via Square.

That's not in scope for us.


Earlier in this thread you said:
> 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 don't agree with this. We are trying to standardise enough to support as many use cases as we can and then get out of the way. Each payment system will have different ways that they support split payouts, it's not up to us to standardize those (unless they all join the WG and ask to use it as a forum to do that).

**TL;DR:** I support the use case and think it could be very popular but I think it's doable today without needing to make any changes to the API.

If you disagree it would be useful if you proposed a concrete API change that would be required to enable what you have in mind. (Or point out where I am misunderstanding something, which is also very possible).

p.s. Regarding:
> This case only really applies when the payment handler invokes the payment which we see as an increasingly rare case.

There are two models of operation for the API that determines what is returned to the merchant via the PR API:
 1. The PH returns some credentials (e.g. card details) to the merchant who uses those to invoke the payment
 2. The PH invokes the payment (e.g. over Bitcoin) and returns a "proof of payment" to the merchant (or similar)

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