Payment Request API for Apple Pay
webkit.org
webkit.org
I know Apple Pay's killer app when it was first announced was the ability to pay easily in-store, but I feel like this is actually a bigger deal. I never had much annoyance with whipping out a card at a grocery store, but paying for things online in a way that's ridiculously fast as well as secure has always been a dicey proposition. This is a huge leap forward.
You’d only get a card number when using the “basic-card” payment method, which Safari does not support.
Apple Pay provides a payment token instead, which does not reveal your physical card number.
Basically you don't have to worry anymore about merchants getting hacked and getting card numbers stolen, because the tokens they use in place of card numbers are tied to iPhone-based authentication (device possession + PIN/biometrics).
Seems like all the marketing around Apple Pay is about convenience, but security is a big part of the story.
Also I think you missed the part where Apple Pay doesn't involve 3 digit CVVs.
Then, payments would just stop getting through unless customers were willing to spend $40 (on a $60 purchase). That ended our little experiment. I couldn't care less about credit card companies' unwillingness to deal in child porn and Nazi propaganda. For us, they simply work.
The decentralised nature of Bitcoin has also been proven to be mythological anyway. You can't use it (or any other cryptocurrency) without access to centralised services for exchange and other services. And those companies will adopt the same policies as CC companies and banks as they grow larger, professionalize, and draw scrutiny.
The only positive was the small fortune that had accrued in the meantime. The earliest orders had exchange rates of around $100:1BC. We didn't care about it December or so, and got lucky again in that the problems with transaction costs both coincided with BC's peak and were the reason for us to cash out.
Maybe you were trying to be flippant, but it came off as somewhere between ignorance and slander.
Citation? PayPal/Venmo seem far, far ahead.
PayPal is widely supported online but I doubt they are far, far ahead in the real world, which I think is what people mean by "mobile" wallet.
Between Apple Pay, Samsung Pay, and Android Pay (which I believe recently got rebranded as just Google Pay), Apple Pay is ahead in userbase numbers by a considerable margin — perhaps not as much now as a year ago, but I doubt it was overtaken.
Does it only support Apple Pay? Kinda of a downgrade from Chrome and the W3 specification:
https://developers.google.com/web/fundamentals/payments/
https://www.w3.org/TR/payment-request/
Oh, and WeChat Pay has 600 million active users, far more than Apple Pay:
https://www.statista.com/statistics/744944/mobile-payment-pl...
How would they present that and make it clear to users that that’s far less secure than Apple Pay? Why would they do that?
Wasn’t this API basically invented to provide a standard complaint way of doing something like Apple Pay? Here you go.
No, the API invented so that the browser could act as an intermediary between many payment-requesting services and payment services, such as PayPal, PayTM, Apple Pay, etc.
They chose to limit support exclusively to Apple Pay, so that users won't have a choice.
This is not a case of “embrace and extend“ where Apple took something open and locked it down. This is a case of where existing functionality is now available any standards compliant way instead of having to use Apple’s custom JavaScript calls.
User still have the choice of entering their credit cards the same way they have for the last 20+ years. It’s not like you’re forcing ALL payment on the web through this.
I notice you didn’t propose a suggestion to the security/UI delima I mentioned. I am 100% willing to bet that’s why they didn’t add basic-card support. And it seems like a good decision to me.
This is a brand new API that basically no one uses. If websites start using it because they want to support Apple Pay and see it will be easier to support other payment methods on other browsers… isn’t that a benefit?
I don’t see how this is anything but a very positive move compared to the official way to support Apple Pay last month.
> But that didn’t happen UNTIL Apple made their own and everyone else decided they wanted one too.
Please, PayPal has had it for over a decade...
Or, as someone from Apple wrote:
> The ability for apps like PayPal to handle payments in the browser requires the Payment Handler API [1]. We aren't announcing support for Payment Handler here, just Payment Request.
> It's not like we're actively restricting or blocking these apps, we just haven't written the code to do this.
Edge's implentation: https://docs.microsoft.com/en-us/microsoft-edge/dev-guide/wi... Chrome's implementation: https://developers.google.com/web/fundamentals/payments/
“We’re pleased to announce that Safari 11.1 on macOS and Safari on iOS 11.3 now support the W3C Payment Request API for conducting Apple Pay transactions on the web.”
"W3C Payment Request API for conducting Apple Pay transactions"
My question is: is this only for Apple Pay? Safari won't support any other payment method/service?
> The browser then presents the payments UI to the user, who selects a payment method and authorizes the transaction. A payment method can be as straightforward as a credit card that is already stored by the browser, or as esoteric as third-party application written specifically to deliver payments to the site.
So if you have the PayPal app installed, you should be able to choose it as the payment method and so on.
My question is if the Apple implementation on Safari restricts the payment methods only to Apple Pay, bocking any other payment services or apps.
It's not like we're actively restricting or blocking these apps, we just haven't written the code to do this.
Is my guess right that such code will never be written?
WebKit implements Payment Request, and Safari supports Apple Pay as a payment method. Other browsers that implement Payment Request might support other methods.
Edit: spelling
So Safari ONLY supports Apple Pay?
Also, Chrome on iOS has to use the Safari rendering engine, since Apple blocks third party rendering engines, so not sure if that would actually work.
Essentially, that's Apple making sure that if you have an iPhone, you can use any payment method, as long as it is Apple Pay.
Once web payments is implemented widely I’ll likely start avoiding shops that don’t implement them.
Quick 101 on how card fees work generally:
Card issuer banks (Citibank, Chase, Bank of America, etc.) contract with a card network (VISA, MC, etc.) and earn a standard fee schedule called Interchange (it's public, you can look it up, typically 1.x-2.x% depending on the card type). This is the bulk of where the card fees go, and often funds card rewards and benefits.
Meanwhile merchants contract with processors (e.g. Chase Paymentech, Heartland, First Data, Square, etc. etc.) who interface with all the card networks, marking up those interchange fees with their own margins. The processors may set up merchants with equipment, or maybe a third party POS vendor does that. But most fundamentally processors are responsible for any merchant-related fraud on the network.
That is why processor markups and merchant vetting procedures can vary -- and why Apple would never take the place of the processor. It's merchant-specific work and involves financially vouching for them. The less vetting the processor does (Square, Stripe), the higher the markup. The more vetting, the close to interchange the fee is going to be.
[1] https://www.digitaltransactions.net/apple-pay-no-charge-for-...
Great job guys!
Similarly how you can use Apple Pay to call an Uber/Lyft in-app.
That said, Apple Pay is just a layer between you and the user's credit card - there's no functional difference at the transaction layer between accepting Apple Pay and having a credit card form in your App. This is why Stripe/Paypal et al. all 'support' Apple Pay. You still need a payment processor who can take the Apple Pay token and turn it into a transaction that puts money into your account.
The in-app-purchase API, however, directly charge's the user's credit card on file with Apple and is credited to your developer account as a payment.
TL;DR Apple Pay is a layer between customer and payment processor, IAPs are a layer between customer and merchant. Apple takes 30% of IAP. Payment processors of Apple Pay take a cut before passing payment on to merchant (Stripe is 2.9% + 30c/transaction, for instance).
Somewhat related: It doesn't seem to be the case anymore but I have the distinct recollection of paying for Hulu through the iPad app as an IAP at a subscription price of $13.99/month only to discover Hulu was charging $11.99/month if purchased through their site. I think Apple cracked down on folks with different IAP pricing vs. direct subscription pricing, but for a while it was a very frustrating effect of the 30% cut that you're forced to give to Apple if you want to allow any in-app subscription on an Apple device.
Edit: I was right, they just recently dropped it when they rolled out their redesign
https://www.macrumors.com/2017/12/21/hulu-apple-itunes-billi...