- From: ianbjacobs <notifications@github.com>
- Date: Tue, 12 Mar 2019 17:00:45 +0000 (UTC)
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-handler/issues/335/472089804@github.com>
I am still working to understand the use case. Thanks for the continued discussion. My assumption is that a merchant would only agree to be paid less than the total (T) if the merchant had already agreed to that. This could be done when registering to accept the payment method (as is the case today). I am hearing the idea that the fees could also include money that is paid to PWAs. @rsolomakhin's comment is interesting, but I don't hear this to be about lowering user fees. The user always pays "T". What changes is how T is divided up among the other parties. This suggests that (fortunately), the browser shouldn't have any particular role to play here. So, assuming that there is some prior agreement that "fees will be paid," is the idea that the fees are determined on a per-transaction basis? If that's the case, then: * The merchant provides some fee information and any other information needed (e.g., merchant ID). * The payment handler can respond true() or false() to hasEnrolledInstrument() depending on whether the fee affects the payment handler's ability to fulfill the transaction requirements. * The PMO divides up T accordingly and makes payments to the merchant and PWA. Is this any closer to the use case? If it is, it continues to sound very payment method specific to me, rather than a general purpose PR API feature. -- 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-472089804
Received on Tuesday, 12 March 2019 17:01:13 UTC