[paxys]

The problem with web payments isn't the lack of a standard API, it's everything that happens under the hood. As a developer it makes no difference to me whether the browser natively supports a payments interface or I add it in via one line of JavaScript. Now tell me how to deal with credit card fees, sales tax, direct debit, crypto transfer and a million other jurisdiction-dependent payment mechanisms and rules. Does the standard account for the fact that in India every online credit card payment requires a one-time code sent via SMS? Or that every bank has its own online payments interface? Or that UPI is now a thing? The folks publishing the Web Monetization spec sure aren't thinking about any of this.

[thrwwycbr]

The core issues with the Web Monetization API is that all the things you mentioned get dangerously close to SAP and Salesforce waters, and there's a reason these systems are the definition of bloated legacy accounting tech.

[djbusby]

It's not bloat when you "need" those features (read: BIG Company)

[troyvit]

Our problem as a < 200 person non-profit is that our teams are being convinced that we _do_ need these systems, and in that scenario it is bloat. We keep telling ourselves that we need to "grow into" SalesForce and all its ancillaries that we're paying outrageous sums for. And that growth looks so much like a balloon. We have more and more SaaS stuff to support but the same number of people to do it. And we think we're getting ahead.

[manquer]

What are you on about ?

The spec/interface for developer does not have the handle the complexity of implementation browsers have to . Do you as the app developer deal with any of that integrating Stripe ? of course not, you yourself say it is just one line of JS for the app developer.

If the API goes through, it will be a key stream of income for browser developers, They can then monetize their most important asset - brand and trust people have on their product without diluting it and not be dependent on advertisements or search engine placements from competitors or crypto to support the development.

It is no different from IAP APIs mobile platform provides, they are not complex(for the app developer). Complexities of geography and taxation is not the app(website) developer's problem it is the platform's nothing in the interface has to handle that. Browsers will charge 30% the Apple and Google do for variety of reasons, but just Stripe level rates is enormous income source for them to support development.

[akira2501]

The spec proposes to turn "browsers into wallets." They're not handling the complexity, they're just completely punting on it.

[jfoster]

One way to handle complexity is to punt on it.

I think that's the right call. You don't want the website itself to handle the complexity. It makes much more sense for the browser to handle it.

[manquer]

That is the goal ? The spec's goal should be to keep it simple on the developer side and hiding/"punting" complexity to the platform/browser developer, is that not the sensible (and secure) way of doing this ?

Users would rather trust the browser to handle my money than each app developer ? We already do this with Apple and Google and other platform hosts. Both of them also build browsers, so it will not even be that difficult for either of them to build payment into the browser as they already have the complexity handled.

Microsoft probably has the stack as well if not at same scale, certainly at reasonable level given their consumer businesses collecting money directly from users.

Mozilla is the only one who will need to build it bottom up, however they have the most incentive to do it, given the revenue potential.

[paulddraper]

Yes they are shifting it to the platform.