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

> "the existing Payments API has never catered for "arbitrary" payment handlers."

Basic Card is designed to allow arbitrary payment handlers. Whether or not the ecosystem decides to pursue that path is another question. The architecture allows (in multiple ways) for payment handlers to evolve and be used without the merchant having to adjust their code. Obviously for proprietary payment methods, we do not expect arbitrary payment methods.

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

I anticipate our current work on the SRC payment method will also go in this direction.

> What App/ServiceWorker is used for "basic-card"

I have seen demos (but not necessarily shipping code) from companies such as Klarna and Worldline. As I mentioned, the ecosystem may not choose to build payment handlers for basic card, but the architecture supports the openness.

> regardless of the end/chosen Payment Handler, the generic disbursement dictionary will cater for the handshake/instruction.

I believe I now understand what you would like (and your disbursement / payeeID / value code above reflects this). 

It is conceivable that merchants and payment method owners could benefit from a standardized "disbursement description." I suspect that would be just a piece of the payment request data for each payment method. 

I don't mind asking our colleagues at the companies you mentioned to see if there is interest. I imagine if there is interest from the largest players in this space, that would help to jump start the work.

I will ask around and report back.

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