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

@richardPAG, thank you for the code. That helps me understand that you would like the merchant to specify how the payment should be divided up and to which parties. 

This is definitely a new use case, and so I would like to ask others (here on GitHub and in other conversations) to help flesh it out. 

It is not yet clear to me that the very generic approach you sketched would work across payment methods. (I realize you are using it to help communicate; it's not a fleshed out proposal.) But what comes to mind is this:

 * Today Payment Request makes possible for a single party to collect credentials for payment (which may be used however that party chooses to use them) OR for a payment handler to cause payment(s) to happen (however that payment handler chooses to do so). 

 * For the case where the merchant does the disbursement with credentials it receives, 
   Payment Request would work as-is.

 * For the case where the payment handler does the disbursement, the payment handler
   today would need to receive all the account information necessary from the merchant (or
   other party calling PR API). This account information would need to be part of the request
   data sent by the merchant.

 * Discussions we've had up to now have assumed that the request data is (potentially)
   about a single account: the merchant's. Your use case involves request data that may
   relate to multiple accounts, and how funds are disbursed to those accounts.

 * One way to imagine changing Payment Request API is to move away from the implicit model
   ("this is about the origin that called the API") to an explicit model (where the merchant identifies N payees and the M payment methods accepted by each payee). I would not recommend that we do anything that sophisticated until we have a much better understanding of the use case and how widespread it is or is likely to be. In short: I would not recommend that we think about changing Payment Request until we have more experience with this.

 * To get experience, I suggest definition of a new payment method. The payment method
    could make some assumptions, like "all the parties accept credit card payments and ACH
    payments." Then you could define the request data so that, FOR EACH PAYEE, the merchant
    specifies:

     - Payee identity
     - Payee account
     - Disbursement amount

 * You can, of course, make additional assumptions, such as "For each payee, the payment handler
    will know how to pay that payee." However, that would result in a lot of 1-to-1 relationship establishments that would increase friction.

All of this to say: I suggest experimenting with your own payment method first!

I hope that helps,
Ian

Ian


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