- From: richardPAG <notifications@github.com>
- Date: Tue, 12 Mar 2019 18:16:09 -0700
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-handler/issues/335/472241614@github.com>
@rsolomakhin to be honest I haven't thought through implementation details thoroughly enough. I only discovered there was such a thing as a Payment Handler API last week and I'm having to look at this in my spare time. (Please let me say how exciting the Web Payments stuff is at the moment! IIUC, from I/O 2017 (I think?) PayPal is working with Chrome so that a user *does not* have to install *any* additional software to make payments! No Native App, no Google Pay library, no Stripe trying to take over the UI, just register with PMO then make payments. Too easy!) @ianbjacobs I think I am confusing people too much. The most important take away from this topic, that I hope everyone agrees on, is that Web Transactions in the Gig Economy more and more need disbursement functionality. And the Payment Manager/Request APIs is the natural home of the industry standard implementation. But to discuss further . . . While I like the terms Agent or Franchiser the PWA owner/vendor *is* and remains the "Merchant" in the transaction as per your spec definition. Dickie's PWA has a relationship with the PMO, is authorized by the User to deduct funds, and is the source of instruction/truth on txn outcomes. I've back-flipped on specifying and AgentID to the API :-( As the API is being driven by Dicky the additional parameter could be FranchiseeID or SubAccount or JointVenture which is also registered with the PMO. Furthermore, your API quite rightly does no maths so the PWA will just instruct the PMO to send $10 (minus PMO fees if any) to Dickies PWA and $90 to the "real" merchant minus PMO fees. (How the PMO fees are broken up between User, PWA, and Merchant is left as an exercise for the PMO but let's all agree it's doable. TODO: 1) How is PWA approval to act as Agent for the Merchant discerned by PMO apart from just having the MerchantID? Only depositing? Heuristics? Don't want it done downstream at PMO. 2) What stops the PWA charging too much? What stops the PMO? 3) What stops a PWA spoofing a Merchant and taking money and providing no fees and services? I don't see any big/unsolvable problems. The Use Case is valid and needs to be addressed right? -- 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-472241614
Received on Wednesday, 13 March 2019 01:16:32 UTC