Mastodon

Addressing 4 Misconceptions About Payments I Typically Hear from Apple Enthusiasts

Posted by Matt Birchler
— 5 min read

I’ve posted a lot both here and on Twitter about payments over the past year for two main reasons:

  1. The App Store rules around payments have been in question, so now payments are just another Apple-related subject.
  2. Lots of people commenting on this stuff have incomplete understandings on how this stuff works, and I’d like to share better information.

Why Listen to Me?

I’m a product designer at a major payments provider that processes billions of transactions per year, and is used by over 1/4 million merchants worldwide. As a technical product designer, my job requires me to have an understanding of how merchants operate, what they want, and how data is passed around (yes, I literally review the API logs during a transaction’s lifecycle).

As always, this post is entirely my own opinion and does not share any sensitive data.

Misconception 1: Merchants want to mishandle my credit card

Nope, in fact the vast majority of merchants would just as well never know your card number in the first place. There is something called “SAQ-A compliance” which is something that many, many merchants want to fall under. The super short version of this is that a merchant is exposing themselves to much less risk (and can save tons of money) if they can take payments without ever seeing your card.

I made this video earlier this year showing how merchants do this on the web.

https://youtu.be/Mj6VMsQBljE

Misconception 2: Apple is the only company people trust to process e-commerce transactions

This isn’t too common, but lots of people do seem to argue that “normal people” don’t trust anyone else with payments. I mean Apple is definitely quite trustworthy here, but they’re far from the only one who can do it, and they’re far from the only company “normal people” seem to trust. The App Store processed about $72 billion (estimated) in transaction volume last year, but e-commerce in general processed around $4.5 trillion last year. Apple’s App Store accounts for 1-2% of that total, which is impressive, but truly a drop in the bucket, and “normal people” are quite familiar with paying many other places.

Misconception 3: When I use an Apple Pay button on the web, Apple runs the transaction

This is a big one, and no, Apple does not process these sales at all. Here’s what happens when you see a payment form with an Apple Pay button and a “key in your card number” form:

  1. You click the Apple Pay button
  2. The merchant’s site feeds in the payment details to the Apple Pay SDK
  3. Safari displays a UI for the transaction total and any required fields/shipping options to the user.
  4. You confirm the sale.
  5. The Apple Pay SDK encrypts the card data and gives it to the merchant.
  6. The merchant makes an API transaction request to their payment provider with the encrypted token.
  7. The provider decrypts the token and gets the card info, the customer billing info, and shipping info.
  8. All this data is sent to the merchant’s processor (def not Apple) to approve or decline.
  9. The processor approves/declines the transaction.
  10. The merchant’s API request gets a response showing approved/declined.
  11. The merchant’s reporting shows the customer’s name, address, shipping details, and masked card number/expiration date.

Depending on how the merchant used Apple Pay, they can save that card to charge later as well, so it is not necessarily a one-time use token, even.

The important thing to know here is that when you use an Apple Pay button on the web, you’re saving time and reducing the odds of a typo in your payment details, but the transaction flow is basically the same for the merchant. And like I mentioned in the first misconception, the odds are that all ways a merchant takes your card data on their site involve the card number being hidden from them.

Misconception 4: Apple doesn’t sell line-item data for advertising

This tweet came across my feed yesterday when I was tweeting about payments:

Security isn’t just about fraud prevention. Most credit card processors and credit card companies sell your transaction data, unless you live in California.

Followed up by:

Purchases made through IAP aren’t itemized to the credit card companies. American Express doesn’t know what you purchased. It just shows as paying Apple.

Ok, so selling transaction data is indeed a thing, and while not everyone does it, enough do it that it’s something you should be aware of. However, this specific argument is barking up the wrong tree.

Banks do sell payment data, but that data is almost entirely just where you shop, not what you’re buying. My bank knows I buy things from Apple, but they don’t know what I buy from Apple. They also know that I buy things from other companies, but it’s exceptionally likely they also don’t know what I’m buying from those companies. Why?

To get into this, we need to talk about transaction data “levels” when it comes to e-commerce (retail is different, and we don’t have time to get into it). This is a bit simplified, but there are generally 3 levels you can qualify for:

  1. Level 1 data is the card number, expiration, CVV, and customer name/address.
  2. Level 2 data is generally things like order ID, PO number, and shipping details.
  3. Level 3 data includes more shipping data, as well as line item details.

The vast majority of the e-commerce you, an individual usually experience is likely Level 1, and sometimes Level 2. Level 1 is the bare minimum to run a transaction, plus a few things that help validate you are the actual card holder (CVV and address verification), and this is generally what gets sent to the payment processor.

Shipping data falls into Level 2 data, but just because you provide shipping details, actually doesn’t mean that’s a Level 2 transaction. Many times this shipping info is simply collected for the merchant to send you the product and it never even makes it to the payment processor (aka your or the merchant’s banks).

But those original tweets refer to the final level, Level 3.

Again, the merchant may be collecting line item data from you, but that could be just so they know what your order is and what they need to fulfill. This does not make the transaction “Level 3” though, it only qualifies if those line items are passed onto the processor. In the vast majority of cases, they are not. See, Level 3 processing is considered an add-on for most merchants, if it’s available at all. That means you pay extra for being able to send this data with your transactions. Most merchants don’t want to do that, but some will because it can mean lower overall fees in some cases.

Additionally, Level 3 transactions are usually used in B2B (business-to-business) or B2G (business-to-government) transactions. B2C (business-to-consumer) is almost always irrelevant here. A merchant will send this enhanced data because they want to drop the processor fee from something like 2.8% to 2.2% (it varies, of course). That difference doesn’t seem like much, but remember, these are B2B and B2G transactions, which tend to be quite large. The difference is trivial on a $15 lunch ($0.09), but on a $40,000 order, that’s $240, which ain’t nothing and adds up fast!

Anyway, this is a long way of saying:

  1. The vast majority of the time, your line item data is not sent to the processor.
  2. It’s usually banks selling data about where you shop, not what specific things you’re buying.
  3. Merchants can sell/use line item data for ads or sell it off, but they also need to know what you’re buying so that you can give you the things you paid for. That’s true whether you’re buying direct or through Apple’s in-app purchase system.

That’s It for Today

There is probably more I could jump into, but these are the 4 that I’ve seen in the past few days alone that I wanted to hit on right now. I think it’s good that people are interested in payments technology and want to talk about it, but I think it’s important for us to be talking about things accurately and not in the vague way I usually see online.