wizard69 said: It isn't that tiny of a minority. Besides I can see Apple bringing back Safari for Windows, maybe even a Linux version just to capture as much of the user base as possible.
I would not care. In recent years, Safari is running behind in terms of new HTML5/CSS3/Javascript features and in speed. I only use Safari on Mac is to check if the websites I develop, run fine on Safari and while debugging apps on iPhones.
Why would anybody want to install Safari on Windows or Linux? The
old Safari on Windows was not exactly a great success, and it was not
without reason.
I too have had bad experiences with PayPal and now refuse to use it. Irrationally l now think that any company which accepts PayPal is not one l wish to do business with. When ApplePay becomes an alternative l am sure there will be lots of switches from PayPal very quickly.
I agree. Almost, like what legitimate business would want you to use PayPal over a real credit card. I see PayPal, I generally think scam.
That could be a smart move, but only if they were committed to making it a superior product. Safari on Windows was pretty crappy for a long time - buggy, outdated, abandoned. The competition is Chrome, not IE.
I doubt we'll be seeing ApplePay as an option on eBay, the only place I use PayPal.
Why? It would be in E-Bays best interest to support Apple Pay.
I'm not sure they would see it that way. Apple Pay transactions would probably cost them more money and limit their access and control over their users and their data. Same reason why retailers like CVS and Walmart have blocked it.
But the other 76% of online shopping is still done on desktops, where Safari accounts for a minuscule segment of the browser market. This story is focused on the desktop Apple Pay feature, which only works on Safari.
I haven't look at this in detail yet. Will Apple Pay on the web also work with mobile Safari on iOS? I know it is supported through Apps today, but opening to mobile shopping on Safari would greatly broaden the use of Apple Pay (for iPads specifically).
I'm sure it will, and that's where most people will use it. But desktop still accounts for at least half of e-commerce, and some of the more complex transactions can be daunting on a smartphone. Again, this product announcement seems focused primarily on the desktop, where Safari has minuscule marketshare.
And again, the disclaimer that I happen to be an avid Safari user.
wizard69 said: It isn't that tiny of a minority. Besides I can see Apple bringing back Safari for Windows, maybe even a Linux version just to capture as much of the user base as possible.
I would not care. In recent years, Safari is running behind in terms of new HTML5/CSS3/Javascript features and in speed. I only use Safari on Mac is to check if the websites I develop, run fine on Safari and while debugging apps on iPhones.
Why would anybody want to install Safari on Windows or Linux? The
old Safari on Windows was not exactly a great success, and it was not
without reason.
Safari is not running behind anything, other than some dubious standards promoted by Google in an attempt to turn the web into an application development environment to rival native apps. That's counter to Apple's business model and to its users' interests, so it's not going to happen for good reason.
Safari is faster, more reliable, more secure, and more energy efficient by far than Chrome.
Safari for Windows was pretty much abandoned for many years, which is why it sucked.
Safari works just fine. No need for a different browser. Looking forward to using ApplePay on our Mac's.
I'm with you, but we make up the tiny minority that I mentioned. I'm struggling to understand how ApplePay will take the web by storm with such a tiny desktop footprint.
freediverx said: I'm with you, but we make up the tiny minority that I mentioned. I'm struggling to understand how ApplePay will take the web by storm with such a tiny desktop footprint.
It is even more niche than just the small Mac market share because it will supposedly only work for Macs running Sierra which will abandon compatibility for another bunch of Macs that one would have expected to support it since they run El Capitan just fine.
I watched most of the developer video for Apple Pay on the Web.
The client-side API is written in JavaScript along with a little HTML and CSS (mainly to include ApplePay images and buttons).
I'd estimate about 30 lines of HTML and CSS (more if the ApplePay button is displayed on each product page (obviating the need for a Checkout button).
There were about 100 lines (or less) of JavaScript code.
The JavaScript calls both Apple Servers and the Merchant's Servers and are designed to provide fast response.
The Merchant's servers call Apple's servers and Payment Processor servers to process the ApplePay transaction.
Additionally, there is a client-side object in Safari that indicates the site meets ApplePay requirements, detects the availability of an ApplePay-capable iDevice nearby and can communicate with it for authorization.
Basically, the client side JavaScript checks if the client-side object is available and the iDevice is nearby:
If yes, enable showing ApplePay buttons and actions, etc. -- and making JavaScript calls to the client-side object to process the ApplePay transactions.
If no, just move on -- nothing for ApplePay to do here
The client-side JavaScript is straight forward. The server-side calls to ApplePay servers are straight forward. The server-side calls to the Payment Processor servers are what they are for ApplePay transactions.
It appears that it would be quite easy to setup a site to handle ApplePay on the Web.
To me, the great unknown is the client-side object.
AFAICT, both the developer and the Merchant need to codesign the client-side object -- per Apple's specifications.
I suspect that the client-side object is a compiled Swift module -- and the effort to port it to other browsers would be similar to including a (gasp) Java Applet in a browser.
freediverx said: I'm with you, but we make up the tiny minority that I mentioned. I'm struggling to understand how ApplePay will take the web by storm with such a tiny desktop footprint.
It is even more niche than just the small Mac market share because it will supposedly only work for Macs running Sierra which will abandon compatibility for another bunch of Macs that one would have expected to support it since they run El Capitan just fine.
I don't think all Sierra-compatible Macs will support this either, since the wireless authentication with the iPhone or Watch may be dependent on the same BT4 hardware that is required for Handoff. My 2009 iMac, or example, will be compatible with Sierra but does not support Handoff/Continuity features.
I doubt we'll be seeing ApplePay as an option on eBay, the only place I use PayPal.
Why? It would be in E-Bays best interest to support Apple Pay.
I'm not sure they would see it that way. Apple Pay transactions would probably cost them more money and limit their access and control over their users and their data. Same reason why retailers like CVS and Walmart have blocked it.
But, on the Web the merchant's site, likely has the user's data already -- customer name, address ... Then, the merchant's site presents the user with product pages, builds a shopping cart, then payment processing (ApplePay or CC). The only thing the merchant's site loses ifs the user's CC info if he uses ApplePay. The merchant actually gains because he has no liability if his site is hacked -- with ApplePay all the hacker would get is expired, one-time tokens.
I'm not sure they would see it that way. Apple Pay transactions would probably cost them more money and limit their access and control over their users and their data. Same reason why retailers like CVS and Walmart have blocked it.
But, on the Web the merchant's site, likely has the user's data already -- customer name, address ... Then, the merchant's site presents the user with product pages, builds a shopping cart, then payment processing (ApplePay or CC). The only thing the merchant's site loses ifs the user's CC info if he uses ApplePay. The merchant actually gains because he has no liability if his site is hacked -- with ApplePay all the hacker would get is expired, one-time tokens.
Hmm, good point. What are PayPal's merchant fees compared to credit card banks?
I'm not sure they would see it that way. Apple Pay transactions would probably cost them more money and limit their access and control over their users and their data. Same reason why retailers like CVS and Walmart have blocked it.
But, on the Web the merchant's site, likely has the user's data already -- customer name, address ... Then, the merchant's site presents the user with product pages, builds a shopping cart, then payment processing (ApplePay or CC). The only thing the merchant's site loses ifs the user's CC info if he uses ApplePay. The merchant actually gains because he has no liability if his site is hacked -- with ApplePay all the hacker would get is expired, one-time tokens.
Hmm, good point. What are PayPal's merchant fees compared to credit card banks?
freediverx said: I'm with you, but we make up the tiny minority that I mentioned. I'm struggling to understand how ApplePay will take the web by storm with such a tiny desktop footprint.
It is even more niche than just the small Mac market share because it will supposedly only work for Macs running Sierra which will abandon compatibility for another bunch of Macs that one would have expected to support it since they run El Capitan just fine.
I don't think all Sierra-compatible Macs will support this either, since the wireless authentication with the iPhone or Watch may be dependent on the same BT4 hardware that is required for Handoff. My 2009 iMac, or example, will be compatible with Sierra but does not support Handoff/Continuity features.
Your post got me to do some more reading ...
You're correct that the Continuity/Handoff feature is required and that uses BTLE (and WiFi -- the Mac and the iDevice must be on the same network). If you have more than 1 iDevice, the Handoff feature uses WiFi to determine which iDevice is closest to the Mac by timing the signal response between the two.
In a prior post, I said that ApplePay for the Web requires/uses a client-side object and JavaScript. Apparently Handoff supplies that client-side object to Safari.
I suspect that Apple used existing Handoff code for Safari, because it was already written and tested -- and could be updated to include ApplePay on the new OSes.
Both of you are right that the Mac/Safari/Handoff requirement addresses a very small niche of the market.
Here's the question facing Apple: Do they want to sell Safari, Macs, or iDevices?
The resounding choice should be iDevices!
That makes me suspect that after a controlled rollout with the Mac/Safari/Handoff requirement, they will offer it on other browsers and platforms.
The biggest limitation to non-Mac hardware market, likely, would be the requirement for BTLE.
Exciting, however it has to be available worldwide. I understand that the Apple Pay hardware has to be launched county by country.. But the web Apple Pay should be easier to implement, since it's software only.
PayPal works, but in the past when I've had issues their support was so bad it's not funny. I literally got locked out of my account for 3 months through no fault of my own because that was their policy.
Paypal has a great anti-fraud system. And that is not their policy.
That said, it's also a downside because it tracks every single bit of identity information ever attached. Simply moving to "the ghetto" is enough to get your Paypal account locked because of neighboring buildings have had past fraudulent activity. The policy is they have to call YOU if your account has suspicious fraud activity, and that is initiated by keeping your contact information up to date.
What gets PayPal accounts locked "forever" are chargebacks.
I don't think all Sierra-compatible Macs will support this either, since the wireless authentication with the iPhone or Watch may be dependent on the same BT4 hardware that is required for Handoff. My 2009 iMac, or example, will be compatible with Sierra but does not support Handoff/Continuity features.
the Mac/Safari/Handoff requirement addresses a very small niche of the market.
Here's the question facing Apple: Do they want to sell Safari, Macs, or iDevices?
The resounding choice should be iDevices!
That makes me suspect that after a controlled rollout with the Mac/Safari/Handoff requirement, they will offer it on other browsers and platforms.
In 2014, Apple said there were 80 million Mac users:
They sell about 20m Macs every year so assuming a portion of new users rather than just upgrades, that could be over 100 million active Mac users. It's not quite the billion iOS devices or Windows machines but that's still a lot of people and Apple Pay for the web works for iOS users too.
Apple Pay for the web affects all of Apple's devices, which cumulatively come to over 1 billion devices so I don't think there's an immediate incentive to support other platforms directly but it shouldn't be hard to use other platforms indirectly and Apple doesn't really doesn't have to do anything. Given that the iOS devices can do the checkout independently, the other platforms just have to get the iOS device to the checkout.
This can be done by 3rd parties using extensions so for example someone using Chrome on Windows can have it send a link to Chrome or an app on iOS and it would pass the link via an extension to Safari, which opens the checkout for payment and the payment happens directly on the iOS device. It would take a few seconds longer than Continuity but has the same benefit of not adding card details.
- You would go to some e-commerce site, setup a cart and the site would detect you are not using Safari as the Javascript check for the API would fail and instead of showing Apple Pay buttons it shows another button to pay indirectly on the mobile device. - This button sends a link with a time-limited session id for the e-commerce site to Chrome or some other app on iOS. Chrome on the Mac would be able to send it via Handoff directly to Safari on iOS. - Chrome on iOS opens this link in Safari via extensions if the link is sent from Chrome on Windows or a Chromebook. - Safari then logs in to the e-commerce site automatically using the id and takes the buyer right to the checkout. - Now the buyer just hits Pay with Apple Pay just like they would if they had originally made the cart on the iPhone/iPad directly. - Windows, Chromebook, Android tablet users with iPhones/iPads can send the login links over and pay with Apple Pay.
This can be done by 3rd parties using extensions so for example someone using Chrome on Windows can have it send a link to Chrome or an app on iOS and it would pass the link via an extension to Safari, which opens the checkout for payment and the payment happens directly on the iOS device. It would take a few seconds longer than Continuity but has the same benefit of not adding card details.
- You would go to some e-commerce site, setup a cart and the site would detect you are not using Safari as the Javascript check for the API would fail and instead of showing Apple Pay buttons it shows another button to pay indirectly on the mobile device. - This button sends a link with a time-limited session id for the e-commerce site to Chrome or some other app on iOS. Chrome on the Mac would be able to send it via Handoff directly to Safari on iOS. - Chrome on iOS opens this link in Safari via extensions if the link is sent from Chrome on Windows or a Chromebook. - Safari then logs in to the e-commerce site automatically using the id and takes the buyer right to the checkout. - Now the buyer just hits Pay with Apple Pay just like they would if they had originally made the cart on the iPhone/iPad directly. - Windows, Chromebook, Android tablet users with iPhones/iPads can send the login links over and pay with Apple Pay.
Actually it's even easier than that.
The iOS and watchOS Pass Kit API has been revised so that your Apple Pay code can be common (shared) among the Watch, iOS apps and extensions. The Safari JavaScript process is almost identical to the Pass Kit process.
The other platform, Chrome for instance, needs to provide a mobile app -- an iOS app (and watchOS app) that supports Apple Pay through the Pass Kit API.
- You would go to some e-commerce site, setup a cart and the site would detect you are not using Safari as the Javascript check for the API would fail and instead of showing Apple Pay buttons it shows another button to pay indirectly on the mobile device.
If the JavaScript Check for the API fails, the browser would call the mobile app and it would check if Apple Pay is possible (almost exactly the same as the JavaScript API).
If Apple Pay is possible, the mobile app returns a response to the browser which would then display the Apple Pay button. (The Apple Pay button images are available to Apple developers so they could be sent to (or included in) the Chrome browser
- This button sends a link with a time-limited session id for the e-commerce site to Chrome or some other app on iOS. Chrome on the Mac would be able to send it via Handoff directly to Safari on iOS. - Chrome on iOS opens this link in Safari via extensions if the link is sent from Chrome on Windows or a Chromebook. - Safari then logs in to the e-commerce site automatically using the id and takes the buyer right to the checkout.
The mobile app can do all this with the Pass Kit API, and communicate directly with the browser -- there is no need to involve Safari in the process -- either from the browser or from the mobile app.
- Now the buyer just hits Pay with Apple Pay just like they would if they had originally made the cart on the iPhone/iPad directly. - Windows, Chromebook, Android tablet users with iPhones/iPads can send the login links over and pay with Apple Pay.
When the buyer hits the Apple Pay button in the browser, a call is made to the mobile app which issues a Pass Kit call (almost identical to the Safari JavaScript call) to display a Payment Request on the iPhone or Watch.
The user accepts, or not
The payment is processed or not
The appropriate response is sent to the browser
It is important to remember that aside from displaying the Apple Pay button and detecting that it was clicked, actual payment is done on the mobile device. Likely, you would display a facsimile of the Payment Request on the browser with instructions to confirm (make the payment) on the mobile device which displays the real Payment Request.
Apple could have implemented Apple Pay on the Web with Safari using the above process. The only disadvantage, I can see, is that the above requires an initial call to the mobile app to determine if Apple Pay is possible -- provided by Handoff in Safari.
Comments
Why would anybody want to install Safari on Windows or Linux? The old Safari on Windows was not exactly a great success, and it was not without reason.
I agree. Almost, like what legitimate business would want you to use PayPal over a real credit card. I see PayPal, I generally think scam.
https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0
That could be a smart move, but only if they were committed to making it a superior product. Safari on Windows was pretty crappy for a long time - buggy, outdated, abandoned. The competition is Chrome, not IE.
I'm not sure they would see it that way. Apple Pay transactions would probably cost them more money and limit their access and control over their users and their data. Same reason why retailers like CVS and Walmart have blocked it.
I'm sure it will, and that's where most people will use it. But desktop still accounts for at least half of e-commerce, and some of the more complex transactions can be daunting on a smartphone. Again, this product announcement seems focused primarily on the desktop, where Safari has minuscule marketshare.
And again, the disclaimer that I happen to be an avid Safari user.
Safari is faster, more reliable, more secure, and more energy efficient by far than Chrome.
Safari for Windows was pretty much abandoned for many years, which is why it sucked.
I'm with you, but we make up the tiny minority that I mentioned. I'm struggling to understand how ApplePay will take the web by storm with such a tiny desktop footprint.
Mmm ...
I watched most of the developer video for Apple Pay on the Web.
The client-side API is written in JavaScript along with a little HTML and CSS (mainly to include ApplePay images and buttons).
I'd estimate about 30 lines of HTML and CSS (more if the ApplePay button is displayed on each product page (obviating the need for a Checkout button).
There were about 100 lines (or less) of JavaScript code.
The JavaScript calls both Apple Servers and the Merchant's Servers and are designed to provide fast response.
The Merchant's servers call Apple's servers and Payment Processor servers to process the ApplePay transaction.
Additionally, there is a client-side object in Safari that indicates the site meets ApplePay requirements, detects the availability of an ApplePay-capable iDevice nearby and can communicate with it for authorization.
Basically, the client side JavaScript checks if the client-side object is available and the iDevice is nearby:
The client-side JavaScript is straight forward. The server-side calls to ApplePay servers are straight forward. The server-side calls to the Payment Processor servers are what they are for ApplePay transactions.
It appears that it would be quite easy to setup a site to handle ApplePay on the Web.
To me, the great unknown is the client-side object.
AFAICT, both the developer and the Merchant need to codesign the client-side object -- per Apple's specifications.
I suspect that the client-side object is a compiled Swift module -- and the effort to port it to other browsers would be similar to including a (gasp) Java Applet in a browser.
For starters:
https://www.paypal.com/webapps/mpp/merchant-fees
Your post got me to do some more reading ...
You're correct that the Continuity/Handoff feature is required and that uses BTLE (and WiFi -- the Mac and the iDevice must be on the same network). If you have more than 1 iDevice, the Handoff feature uses WiFi to determine which iDevice is closest to the Mac by timing the signal response between the two.
In a prior post, I said that ApplePay for the Web requires/uses a client-side object and JavaScript. Apparently Handoff supplies that client-side object to Safari.
I suspect that Apple used existing Handoff code for Safari, because it was already written and tested -- and could be updated to include ApplePay on the new OSes.
Both of you are right that the Mac/Safari/Handoff requirement addresses a very small niche of the market.
Here's the question facing Apple: Do they want to sell Safari, Macs, or iDevices?
The resounding choice should be iDevices!
That makes me suspect that after a controlled rollout with the Mac/Safari/Handoff requirement, they will offer it on other browsers and platforms.
The biggest limitation to non-Mac hardware market, likely, would be the requirement for BTLE.
Whew!
That said, it's also a downside because it tracks every single bit of identity information ever attached. Simply moving to "the ghetto" is enough to get your Paypal account locked because of neighboring buildings have had past fraudulent activity. The policy is they have to call YOU if your account has suspicious fraud activity, and that is initiated by keeping your contact information up to date.
What gets PayPal accounts locked "forever" are chargebacks.
http://www.trustedreviews.com/news/mac-install-base-hits-80-million-user-milestone
They sell about 20m Macs every year so assuming a portion of new users rather than just upgrades, that could be over 100 million active Mac users. It's not quite the billion iOS devices or Windows machines but that's still a lot of people and Apple Pay for the web works for iOS users too.
Apple Pay for the web affects all of Apple's devices, which cumulatively come to over 1 billion devices so I don't think there's an immediate incentive to support other platforms directly but it shouldn't be hard to use other platforms indirectly and Apple doesn't really doesn't have to do anything. Given that the iOS devices can do the checkout independently, the other platforms just have to get the iOS device to the checkout.
This can be done by 3rd parties using extensions so for example someone using Chrome on Windows can have it send a link to Chrome or an app on iOS and it would pass the link via an extension to Safari, which opens the checkout for payment and the payment happens directly on the iOS device. It would take a few seconds longer than Continuity but has the same benefit of not adding card details.
- You would go to some e-commerce site, setup a cart and the site would detect you are not using Safari as the Javascript check for the API would fail and instead of showing Apple Pay buttons it shows another button to pay indirectly on the mobile device.
- This button sends a link with a time-limited session id for the e-commerce site to Chrome or some other app on iOS. Chrome on the Mac would be able to send it via Handoff directly to Safari on iOS.
- Chrome on iOS opens this link in Safari via extensions if the link is sent from Chrome on Windows or a Chromebook.
- Safari then logs in to the e-commerce site automatically using the id and takes the buyer right to the checkout.
- Now the buyer just hits Pay with Apple Pay just like they would if they had originally made the cart on the iPhone/iPad directly.
- Windows, Chromebook, Android tablet users with iPhones/iPads can send the login links over and pay with Apple Pay.
The iOS and watchOS Pass Kit API has been revised so that your Apple Pay code can be common (shared) among the Watch, iOS apps and extensions. The Safari JavaScript process is almost identical to the Pass Kit process.
The other platform, Chrome for instance, needs to provide a mobile app -- an iOS app (and watchOS app) that supports Apple Pay through the Pass Kit API.
It is important to remember that aside from displaying the Apple Pay button and detecting that it was clicked, actual payment is done on the mobile device. Likely, you would display a facsimile of the Payment Request on the browser with instructions to confirm (make the payment) on the mobile device which displays the real Payment Request.
Apple could have implemented Apple Pay on the Web with Safari using the above process. The only disadvantage, I can see, is that the above requires an initial call to the mobile app to determine if Apple Pay is possible -- provided by Handoff in Safari.