Hacker News Reader

Comment by dlisboa | Hacker News Reader

Edit: looks like I made a fool of myself. I didn’t know about Apples other implementation of a similar feature.

It seems nice but I think Apple will never implement this for Safari, even if standardized. It’d bypass their AppStore and make the web even more “app-like”, which they already aren’t crazy about.

View on HN

Apple has supported the Payments Request API for five years

https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...

https://webkit.org/blog/8182/introducing-the-payment-request...

Correct. The article is about a new standard.

The conjecture was that Apple wouldn’t support the new standard because it would give an “app like experience”.

The closest similarity we have is that Apple supported the existing payment standard relatively early on.

Does the existing standard make the web more app-like?

The existing one, you click on a button on the web and it takes you through the same Apple Pay process flow that you go through when you pay in app with Apple Pay for something like Uber.

In app purchases - Apple takes 30% for electronic goods in the App Store

Apple Pay - Apple charges standard credit card fees on the web or via the App Store.

As mentioned above, you can use Apple Pay in app if you sell physical goods.

SPC does not handle payments, it handles authentication. SPC is designed to work in scenarios like Plaid and 3D Secure, not for what Apple Pay (or the app store) does.

I believe SPC comes out of the Authn working group.

> This specification defines an API that enables the use of strong authentication methods in payment flows on the web. It aims to provide the same authentication benefits and user privacy focus as [webauthn-3] with enhancements to meet the needs of payment processing.

https://www.w3.org/TR/secure-payment-confirmation/

I think you might be forgetting that Apple Pay exists and has worked on the web for years. This looks like a standardised version of Apple Pay.

Incorrect. The standardized version of Apple Pay is the Payments Request API, which has been in place for years.

And has been supported by Apple for 5 years.

ApplePay in-the-web has existed since the inception of the feature. I'm not sure how the App Store is relevant here?

This is a new web standard, it’s not Apple Pay.

No one is disputing that this is a new standard. The dispute is that Apple wouldn’t support it because it would take away from some hypothetical App Store revenue. Apple already supports the existing standard showing the argument doesn’t hold.

Article & spec mention privacy issues re: connecting users to payments, that seemingly would allow someone to pay for an app subscription without going through the store, since the payment receiver gets user details

This is possible already with Apple-supported Payment Request API (and even without those APIs, like just logging into a website). This is how Netflix on iOS works, which is explicitly supported (though with stupid cavets) by Apple.

I just signed up to a subscription via the web using Apple Pay. They automatically had my name and email address.

You’re absolutely correct, and there’s privacy concerns for Apple in the spec, e.g. the users info is now sent with transactions.

c.f. example of how merchants M1 and M2 could collide to identify payment method P1 and P2 are connected to the same user

EDIT: Throttled on new comments

I agree: I'd take up more detailed Qs with the article writer & spec/proposal, they seem sure its different.

I also agree if the new proposal is the same as the old proposal, it does seem likely Apple would implement it.

I don't understand why the W3C would make a new proposal that was the same as the old one, but...forget it Jake, it's ̶C̶h̶i̶n̶a̶t̶o̶w̶n̶ web specs.

The user’s info is sent with the existing Payments Request API. If you use Apple Pay on the web, it will send your name and address if requested for shipping physical goods.

Reply on news.ycombinator.com