Does anyone know if this is going to be available via the standardised Web Payments API? [1] (support being worked on by Chrome [2] and Microsoft Edge [3]) That way web developers won't need to build different implementations for different platforms.
As a quick correction, the current Web Payments API (PaymentRequest) that is making its way through the W3C process is at https://w3c.github.io/browser-payment-api/. It's not the one from web-payments.org.
What Apple has announced so far is actually quite similar to PaymentRequest. Apple is a part of the Working Group, so this isn't a huge surprise. I am hopeful that the two implementations will converge rather quickly over the next few months. Apple emailed the public working group list expressing this hope as well [1].
For full disclosure, I am an editor on the PaymentRequest spec, and I work on Chrome.
"There are several differences between the Apple Pay API and the Payment Request API, and we look forward using the experience we've gained while working on it to help push the Payment Request API forward. We'll follow up with specific emails or GitHub issues on the main technical differences. A couple of the more important differences are:
* the API requires merchant validation, ensuring that bad actors' access to Apple Pay may be revoked;
* the canMakePayments() and canMakePaymentsWithActiveCard() methods help ensure we reveal user information to the site responsibly."
Another solid product page by Stripe. Simple, elegant, fast, responsive. For example, the "demo video" isn't actually a video - it's a composition of small images, DOM elements with CSS animation.
Stripe is just one of X layers which Apple Pay can run on. There's no need for them to get into that business.
The next stage for Apple Pay is to run their own payment network between Apple Pay users. No Stripe required, Apple takes a processing fee instead of First Data, etc.
Maybe Square too/instead. The ability to send cash through an iMessage with Square was demoed in the keynote, and I have to think that Apple would have really liked to have been able to do that themselves with Apple Pay.
CEO and board have a fiduciary responsibility to the shareholders. If Apple showed up with enough cash ($5-6B?) it would be hard for the board to say no. That kind of money might be an overpayment, but with the amount of cash that Apple has, you can afford to make any number of poorly priced strategic investments. Stripe is still small enough that Apple could vastly overpay and it would make little difference for Apple, while being enough money that the board had to agree to the deal.
That said, I sure hope they don't do that. Stripe would do better at a platform company like Amazon than Apple if it was decided they needed to be bought to continue growing.
> CEO and board have a fiduciary responsibility to the shareholders.
While there is a fiduciary responsibility, private != public in this regard. If the Collison's retain enough equity to control the company, doesn't matter what the rest of the board thinks (I have no idea what their cap table looks like, to be clear)
This is big news, conversions on mobile web have always been much lower than on desktop. I hope having a little less friction along the way will help improve things.
There are many barriers to purchase on mobile web, such as users being less likely to have enough time to complete the purchase, user distrust of mobile web sites / card forms, potential network disconnect during transaction, difficulty typing the card number (and I bet near 0% of potential customers know about the scan card feature), small screen makes it hard to know if you're really on the right product for you, etc.
This might reduce barriers but there will still be some. Also, I doubt that Safari's credit card autofill had much impact on conversion overall - is there any data about this?
Although many merged features between macOS and iOS seem a bit gimmicky, this one is a huge step forward and it is a good example of how to implement a feature that is both convenient and secure.
Heck, I predict it will hugely increase online commerce because people will not feel iffy about handing over credit card details to random web sites; as long as the sites support pay by phone (where the card itself is not even shared), you will be able to fearlessly shop from a lot more web sites. In a way, Amazon should be a bit worried: given a decent cross-site shop-search mechanism and a much more reliable checkout experience, the whole web looks a lot more like one super-store.
It seems pretty likely now, with the addition of unlocking via the Apple Watch and using an iPhone to authenticate web payments on a Mac, that Apple will be adding a fingerprint sensor to a future MacBook.
While I'm sure that Apple would love it if everyone owned a Mac, iPhone, and Apple Watch, there are lots of people out there that may only own a Mac, or own a Mac and an Android phone. I think Apple would still prefer that these people use Apple Pay if possible.
I've been looking into payment services lately and it looks like very few have pricing schemes that work well if most of your income consists of micropayments of $1-3 or less. Stripe's pricing seems to be fairly standard, so I'll use it to illustrate my point: the fixed 30c cost on a $1 payment is 30%, which seems prohibitively expensive for this use case.
So Heartland Payment has an interesting scheme where micropayments are aggregated over a certain time period (say 2 hours) and then charged en masse. Another work around is to require users buy "credits" that they can then use for micro purchases at any given time.
From the demo, the payment overlay seems integrated directly into Safari. Hopefully there's an OS level API that Chrome et al. can hook into, otherwise it's going to be fairly limited in adoption.
Personally, if my old macbook can handle the new OS, I'll move my online shopping over to Safari.
That said, I would have much preferred that it work on any browser on any OS and only require an iPhone, but I'm interested in Apple Pay online enough to change some habits.
New Macbooks are rumored to be coming with a TouchID sensor which could change things a bit down the road. For now requiring an iPhone seems like a decent compromise.
Two features that I am bumfuzzled weren't in Apple Pay from day one:
1. The ability to use Apple Pay for e-commerce transactions
2. The ability for any iPhone/iPad to accept Apple pay
The idea that you can only use Apple Pay physically always felt a bit limiting, and iPhone and iPads are becoming a standard PoS device. Supporting acceptance of payments natively on these devices seems like a no-brainer.
> The idea that you can only use Apple Pay physically always felt a bit limiting
Except that you could use it in apps from the start? Device to device sounds great, but that's not close to how Apple Pay works (standard credit cards, not merchant accounts). Square and others now simply provide NFC readers and it works fine.
By physically, I mean having to use it from the device. I don't know how common a use case I represent, but I do most of my e-commerce purchasing from my laptop. I would have more more apt to adopt Apple Pay had I been able to place an order on amazon.com and pay with it from my web browser.
My thinking is that it would lower the barrier of entry. The iPad/iPhone cannot be used to accept payments without some kind of addon that can break or get lost. The moment someone buys an iPhone/iPad, they can accept payments. It also opens some interesting use cases such as micro-payments between individuals. For example, paying a buddy back for your part of lunch or paying someone in-person for a purchase from Craigslist.
> It also opens some interesting use cases such as micro-payments between individuals. For example, paying a buddy back for your part of lunch or paying someone in-person for a purchase from Craigslist.
Unless Apple plans on opening a bank, the limiting factor here is still that you/your buddy will be taking a haircut on the credit card processing fees.
Apple Pay doesn't replace the card network, and the card networks are NOT interested in being structured to be micropayment friendly.
Another completely missed opportunity on their part. Apple has the cash and where with all to be a bank. All they would need to do is purchase a community bank somewhere, and bam, they could start cutting out credit card processors. No doubt it would be a lot of work, but when you have $200 billion in the bank and their focus, it becomes quite doable.
I had that thought when Apple Pay was first introduced last year. Seemed like a no-brainer, especially since Apple doesn't mind doing the walled-garden thing.
Sorry if this is off-topic, but I've been wondering this for a long time now: is it just me or does it seem like a lot more risky to type out your credit card info on every site that supports Stripe?
Continuity is really a crutch for identity, and to reduce risk. My bet is once - Apple Pay on Safari on macOS & iOS via iPhone/watch - qualifies for a lower rate, Apple could open up Apple Pay to other browsers, cross platform - on both desktop and mobile.
only support for Safari on touch-id enabled devices. doubt Apple will provide API or any other x-platform support. most impactful for mobile commerce sites without strong App or App traffic.
Stripe and Braintree have been supporting Apple Pay on iOS for a while. But Apple just announced today Apple Pay for the web on your desktop (OS X/macOS) or mobile web browser, and Stripe's announcing that they're adding support for it.
It's there number - 45. Shipping or forwarding brokers.
When emailed, they say of course it's not allowed you must choose another payment processor. But having quizzed my local circle, I know of many drop shippers who are using shopify payments.
I even emailed stripe and they said, sadly drop shipping is not accepted. But they did not say why.
Drop shipping with Shopify is being heavily promoted right now in Internet Marketing circles. Here is one such product that was launched recently: https://www.youtube.com/watch?v=Wnp4TnFaVJM
It's all about Shopify and Drop shipping and he's using their own payment processor. You guessed it, powered by stripe.
So what's going on here then?
Are stripe allowing drop shipping when they turn a blind eye to it?
I really wanted to use them, now using a competitor.
I don't see anything about drop shipping on that page. I'd also have guessed that any past restrictions would have been on the drop shipper not the companies using drop shippers, but that's just an uninformed guess.
A drop shipping store is a web "store" that's little more than a form that forwards your order to a distributor or wholesaler or some other real store. The distributor makes wholesale and ships direct to you, the "drop shipper" pockets everything you paid above wholesale as their cut for deceiving you into believing they were some kind of stock-holding entity when in reality you could have gone to the wholesaler and saved money.
It's a niche rife with scammers, hence most payment processors officially wanting nothing to do with them.
Let's say I run a webstore called cookhardwoodfloors.com. I sell hardwood floors, but I don't hold any invetory. When I make a sale, I send an email to another company that holds the inventory. I ask them to ship out the item to my buyer.
No, Not from the manufacturer usually, just a third party, and to consumer, not retailers. Some third parties advertise themselves as drop shippers and some don't know they are drop shipping. If I list an iPhone on ebay and instead of shipping it out ( I don't have it) I go to amazon and order it and put the buyers shipping address and have amazon ship it directly to my buyer - that is drop shipping. I am selling something that I don't have in stock and having a third party ship it out.
Listen, I work for a giant manufacturer, I know what drop shipping is. You've given another example of drop shipping, the first being manufacturer directly to retail, without using a distributor. In the end, drop shipping is about cutting out the middle man (distributor, or in your case the retailer).
[1]: https://web-payments.org/specs/#transactions
[2]: https://www.youtube.com/watch?v=yelPlCVZLEE
[3]: https://blogs.windows.com/msedgedev/2016/02/03/2016-platform...