- From: Martin Thomson <notifications@github.com>
- Date: Mon, 10 Mar 2025 17:11:08 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1015/2712127763@github.com>
martinthomson left a comment (w3ctag/design-reviews#1015) No one was suggesting that you stop trying. On the contrary, I would like you to keep trying harder. The concern was that the proposal didn't address the biggest problem in this space, which is the integration with payment handling infrastructure. The current shape of the API requires an essentially proprietary core. That remains true with PaymentRequest as much as it does here, though the extent of the system that is entirely proprietary does change slightly if you reframe this work as a PaymentRequest, as you suggest. Payments remains the least open part of the platform. The fact that Chrome only supports Google Pay and Safari only supports Apple Pay and basically no other combinations (it looks like [maybe there is a Microsoft wallet that integrates with Edge](https://blogs.windows.com/msedgedev/2016/12/15/payment-request-api-edge/), but I'm not aware of anyone using that). If all we get is vertical integrations, that says that something is fundamentally broken. Personally, I'd be looking for evidence that this can be implemented more widely. Aneesh mentions the possibility of a plugin API. I'd very much like to see that, not just in terms of product demos, but with standards and some diversity of implementation of those standards. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1015#issuecomment-2712127763 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1015/2712127763@github.com>
Received on Tuesday, 11 March 2025 00:11:12 UTC