- From: richardPAG <notifications@github.com>
- Date: Tue, 30 Apr 2019 19:37:10 -0700
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-handler/issues/335/488181396@github.com>
@ianbjacobs Thanks for the update! > One person answered that they did not think it was appropriate for Payment Request to > manage disbursement details. I would be very curious to know how they can describe as inappropriate functionality they already surface this via Payment Requests from their bespoke proprietary API solutions? You don't necessarily need to identify them here as I have provided links to their existing and fully supported developer offerings. What is required is a standard way of solving already accepted business requirements. @square have provided [multi-party transactions](https://docs.connect.squareup.com/payments/transactions/overview#mpt-overview) @stripe supports a[ Web App fee](https://stripe.com/docs/connect/direct-charges#collecting-fees) structure @paypal [payouts](https://developer.paypal.com/docs/api/payments.payouts-batch/v1/) are the most flexible of the lot > The other person acknowledged the use case and made some observations. However, > the comments did not address directly the value of standardization of proportion and > beneficiary information. If "standard" Web Payments are not an issue then why are we all here? What I propose will permit (relative) freedom of movement/choice of Payment Provider to all PWA manufactures by not locking them into proprietary bespoke solutions: - 1) Super Mini Cabs supports PayPal, Square, and Stripe 2) Driver Fred can choose one that he has an account with 3) Everyone gets paid in the one txn I must not be articulating the brilliance of this feature because it *will* revolutionize web payments and most **importantly** provide a way for PWA vendors to monetize the App! > I followed up and asked for clarification but have not yet heard back. Thanks again. Can we please try to tackle this another way briefly? You show me how you as Super Minicabs would take the money from the end-user and pay your driver without getting slapped with a severe PCI DSS burden? No one else see the potential here? -- 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-488181396
Received on Wednesday, 1 May 2019 02:37:32 UTC