Re: [w3ctag/design-reviews] Payment link type in HTML (Issue #1015)

Adding my own perspective to sharpen one of the points above...

The thing that most concerns me about this API is that it depends on browsers performing some fairly heroic integration work. That would create a significant skew in the browser market, where bigger players with large, existing payments teams are able to provide this integration for payment providers. Conversely, smaller browser makers are simply unable to bring resources to bear on that scale (I've heard that this whole payments business is hard, even for large actors). On that basis alone, I think that this approach is potentially very damaging.

The purpose of standardization in an area like this should be to help eliminate these factors, not exacerbate them, as this appears to do. Developing standardized interfaces could simplify implementation, but it seems that this industry is resistant to that sort of effort. In this regard the Payment Request API appears to be stronger, yet even that API appears to have failed to ensure that payments are more widely accessible, as evidenced by the fact that the Apple ecosystem and Google ecosystem are the only ones who have successfully done that work.

I was not going to post this, relying on the fact that @csarven's comments already mentioned this concern ... partly because I work for one of the browser makers for whom resourcing all this work would be completely infeasible. However, other TAG members encouraged me to do that because they similarly see this as an important architectural issue.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1015#issuecomment-2655029053
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1015/2655029053@github.com>