Browser-based Apple Pay predicted to chip away at PayPal's dominance with both consumers & merchant

2

Comments

  • Reply 21 of 49
    croprcropr Posts: 960member
    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. 

  • Reply 22 of 49
    mike1mike1 Posts: 1,923member
    dachar said:
    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.
  • Reply 23 of 49
    freediverxfreediverx Posts: 1,408member
    wizard69 said:

    It isn't that tiny of a minority. 
    4.69% isn't tiny?

    https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0

    I can see Apple bringing back Safari for Windows
    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.



    edited June 2016
  • Reply 24 of 49
    freediverxfreediverx Posts: 1,408member

    wizard69 said:
    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.
    edited June 2016
  • Reply 25 of 49
    freediverxfreediverx Posts: 1,408member

    brucemc said:
    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.
  • Reply 26 of 49
    jdgazjdgaz Posts: 357member
    Safari works just fine. No need for a different browser. Looking forward to using ApplePay on our Mac's.
  • Reply 27 of 49
    freediverxfreediverx Posts: 1,408member
    cropr said:
    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.
    patchythepirateradarthekat
  • Reply 28 of 49
    freediverxfreediverx Posts: 1,408member

    jdgaz said:
    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.
    edited June 2016
  • Reply 29 of 49
    volcanvolcan Posts: 1,791member
    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.
  • Reply 30 of 49
    dick applebaumdick applebaum Posts: 12,523member

    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:
    1. If yes, enable showing ApplePay buttons and actions, etc. -- and making JavaScript calls to the  client-side object to process the ApplePay transactions.
    2. 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.


    radarthekatbestkeptsecret
  • Reply 30 of 49
    freediverxfreediverx Posts: 1,408member
    volcan said:
    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.
  • Reply 32 of 49
    dick applebaumdick applebaum Posts: 12,523member

    wizard69 said:
    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.


    edited June 2016
  • Reply 33 of 49
    freediverxfreediverx Posts: 1,408member

    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?
  • Reply 34 of 49
    SpamSandwichSpamSandwich Posts: 31,396member
    If PayPal is our friend, who needs enemies?
  • Reply 35 of 49
    dick applebaumdick applebaum Posts: 12,523member

    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?

    For starters:

    U.S. Fees2.9% + $0.30 per transaction

    https://www.paypal.com/webapps/mpp/merchant-fees

  • Reply 36 of 49
    volcan said:
    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.


    Whew!




  • Reply 37 of 49
    palegolaspalegolas Posts: 1,283member
    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.
  • Reply 38 of 49
    misamisa Posts: 827member
    ireland said:
    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.
  • Reply 39 of 49
    MarvinMarvin Posts: 14,229moderator
    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:

    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.
  • Reply 40 of 49
    dick applebaumdick applebaum Posts: 12,523member
    Marvin said:

    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.



    edited June 2016
Sign In or Register to comment.