Apple Pay 작동 방식에 대한 오해

• 실제 카드 번호를 숨기는 구조는 Apple Pay만의 기능이 아니라 Google Pay·Samsung Pay 등 주요 디지털 지갑에서도 쓰이는 결제 방식임
• 핵심은 물리 카드 번호인 FPAN과 기기별 결제 번호인 DPAN의 분리이며, 같은 카드라도 iPhone과 iPad에서는 서로 다른 DPAN이 사용됨
• DPAN은 가맹점 간 추적을 어렵게 만들 수 있지만, 같은 가맹점 안에서는 후속 거래에도 유지돼 단일 가맹점의 구매 이력 추적은 막지 못함
• 결제 정보 유출 때는 FPAN보다 DPAN이 안전하며, DPAN은 거래마다 붙는 고유 암호화 번들과 함께 제출될 때만 작동함
• Apple Pay는 이름, 이메일, 청구지·배송지, 구매 상품 같은 개인 정보를 자동으로 숨기지 않으며, 결제 화면에 표시된 정보는 가맹점에 전달된다고 봐야 함

---

DPAN은 Apple Pay 전용 기능이 아님

• Apple Pay가 실제 신용카드 번호를 숨긴다고 할 때 핵심은 DPAN임
• FPAN은 물리 카드에 인쇄된 15~18자리 funding primary account number이고, DPAN은 device primary account number임
• DPAN은 DNS 레코드와 비슷하게 이해할 수 있음
  • 사용자는 실제 IP 주소를 몰라도 도메인 이름으로 웹사이트에 접근함
  • 같은 카드도 Apple Pay를 iPhone과 iPad에서 쓰면 각 기기가 고유 번호를 받아 서로 다른 DPAN을 사용함
• 이름부터 “Apple Pay number”가 아니라는 점이 중요함
  • Google Pay와 Samsung Pay도 미국의 주요 디지털 지갑으로서 같은 방식으로 실제 카드 번호를 숨김
  • Amazon Pay와 Shop Pay 버튼도 결제가 다른 회사를 통해 처리되므로 기술적으로 DPAN은 아니지만, 가맹점이 실제 FPAN을 보지 못하게 함

가맹점과 은행도 실제 카드 번호 노출을 줄이려 함

• 가맹점이 실제 신용카드 번호를 직접 처리하면 위험 부담이 커짐
• 현대 결제 수락 도구는 실제 카드 정보에 접근하는 사람을 최대한 줄이는 방식으로 결제 정보를 수집하게 만듦
• 은행이 DPAN을 쓰지 않을 것이라는 추측은 실제 사례와 맞지 않음
  • Wells Fargo, Chase, Bank of America 등 여러 은행은 자체 디지털 지갑을 운영했거나 운영했고, 모두 DPAN으로 일반 계정 번호를 보호함
  • 미국 대형 은행들이 쓰는 Paze도 DPAN을 사용함
  • Paze가 내세우는 주요 이유 중 하나는 “Paze does not share your actual card number with the merchant.”임

DPAN이 막는 추적과 막지 못하는 추적

• DPAN이 거래마다 바뀐다는 말은 정확하지 않음
• 같은 가맹점에서 이어지는 거래에는 동일한 DPAN이 사용됨
• 이 구조는 여러 가맹점의 거래 데이터를 사들여 한 사람의 쇼핑 경향을 파악하려는 데이터 브로커에게 장벽이 될 수 있음
• 반대로 단일 가맹점은 Apple Pay가 제공한 DPAN만으로도 해당 고객의 거래 이력을 볼 수 있음
  • Target이 자사 구매 이력을 바탕으로 고객 상태를 추론한 사례 같은 상황을 Apple Pay가 막지는 못함
  • 다른 디지털 지갑도 같은 한계를 가짐

데이터 유출 때 DPAN이 주는 보호

• 결제 카드 정보가 유출되는 상황에서는 DPAN이 FPAN보다 안전함
• 2024년에 가맹점이 신용카드 번호를 직접 다루는 일은 없어야 하지만, 결제 게이트웨이가 해킹되어 DPAN과 만료일이 유출되는 상황은 생길 수 있음
• 공격자는 유출된 DPAN만으로 결제를 실행할 수 없음
  • DPAN은 각 거래에 고유한 암호화 번들의 일부로 제출될 때만 작동함
  • Apple Pay로 수집된 카드에 대해 반복 결제를 실행하는 방법은 있지만, 해커가 이를 할 수 있어서는 안 됨
• 그래서 모든 디지털 지갑이 수집하는 DPAN이 유출되는 것보다 FPAN 유출이 훨씬 더 위험함

Apple Pay가 개인 정보를 자동으로 숨기지는 않음

• Apple Pay가 개인 정보를 자동으로 가린다는 생각은 사실과 다름
• 테스트 가맹점 계정에서 실제 Apple Pay 거래를 실행하면 가맹점 수준 리포트에 이름, 이메일, 청구지와 집 주소 같은 정보가 표시됨
• 물리 상품 결제에는 배송 정보가 필요하므로 Apple Pay SDK는 가맹점이 고객에게 받을 개인 정보를 선택할 수 있게 함
• 상품 정보도 Apple Pay에 전달되어 구매자가 무엇을 사는지 보여줄 수 있고, 이 정보 역시 가맹점에 전달됨
• 결제 시 Apple Pay 카드에 표시되는 정보는 가맹점에 전달된다고 봐야 함
  • 이 점에서 Apple Pay는 다른 결제 방식과 같음
  • 가맹점은 체크아웃에서 필요하거나 원하는 개인 정보를 선택해 요청함
  • 다른 디지털 지갑도 같은 방식으로 작동함

디지털 지갑이 실제로 제공하는 보호

• Apple Pay는 좋은 결제 수단이고, Apple은 이런 형태의 디지털 지갑을 대중화하는 데 역할을 함
• 다만 Apple Pay의 기능은 업계에서 고유하지 않음
• DPAN은 여러 가맹점에 걸친 한 사람의 구매 추적을 더 어렵게 만들고, 결제 카드 정보 유출 시 고객 위험을 줄이는 데 유용함

[GN⁺]

Hacker News 의견들

• Apple Pay와 Google Pay가 실제로 어떻게 동작하는지 ELI5로 알고 싶음. 예전에는 카드 정보를 가맹점이나 결제 대행사에 그냥 넘긴다고 생각했고, 원문도 비슷하게 보이는데, Google Pay에서 Amex를 쓰면 MasterCard 때와 달리 일부 가맹점이 결제를 거부하는 것도 봤음
  가끔은 Apple/Google이 결제 대행사나 결제 수단 자체처럼 동작하는 것처럼 느껴짐. 거래 데이터를 모으고, 마트 단말기도 Apple/Google Pay 앱을 위한 특별 지원이 필요했던 것처럼 보였기 때문임
  그렇다면 Apple/Google만의 독점적인 비법은 무엇인지, 왜 오픈소스 대안으로 대체하기 어렵거나 불가능한지 궁금함. iOS/Android에서 NFC 칩에 온전히 접근할 수 있는 쪽이 Apple/Google뿐이라서 그런 건가?
  https://news.ycombinator.com/item?id=39845805

  • Apple/Google만의 비법은 딱히 없음. 전 세계 많은 은행이 자체 HCE 지갑을 제공하지만 Android에서만 동작함. Apple은 필요한 API를 제공하지 않았고, EU에서는 이제 바뀌는 중임
    중요한 건 기본값임. 기기당 기본 Visa, Mastercard 지갑은 하나만 둘 수 있고, 탭하기 전에 따로 앱을 열 필요가 없는 쪽이 유리함. Google Pay는 여러 은행 카드를 지원하므로, 특정 발급 은행의 HCE 지갑보다 큰 이점이 있음
    Apple/Google은 새 카드를 특정 기기에 등록할 때 중재에 관여하지만, 실제 POS 거래 흐름에는 들어가지 않음
    가맹점은 여전히 기반 카드 브랜드를 받아야 함. 현대의 Google Pay와 Apple Pay는 카드 브랜드를 바꿔주는 프록시 카드가 아니며, Curve 같은 서비스와 다름
    오프라인 단말기는 별도 지원이 필요하지 않음. 단말기가 버그가 있지 않은 한, 기반 카드 체계를 받는 곳이면 동작함. 물리·논리 프로토콜은 플라스틱 카드와 같고 단말기 입장에서는 거의 구분되지 않음
    웹에서는 다름. 쇼핑몰 웹사이트와 결제 서비스 제공자가 명시적으로 지원해야 함
  • Apple/Google Pay는 비접촉 신용카드와 같은 방식인 비접촉 EMV를 사용함. Visa/MC의 Paywave, Paypass 뒤에 있는 표준임
    그래서 무선 단말기는 대체로 Apple Pay와 Google Pay를 그냥 받았고, 특별 지원이 많이 필요하지 않았음. 바뀐 것 중 하나는 이런 기기가 더 안전하다고 여겨져 비접촉 카드보다 결제 한도가 올라간 점으로 기억함
    오픈소스 구현이 어려운 이유는 EMV 구현이 복잡하고, 전문 장비를 통한 많은 테스트와 검증이 필요하기 때문임. 기기에는 개인 키를 안전하게 보관할 보안 영역이 필요하고, 앱은 생체인증이나 PIN 잠금 해제가 사용됐음을 확인해 사용자 보안을 보증할 수 있어야 함
    또한 설정 과정에서 카드 발급 은행의 백엔드와 연동해 필요한 키와 정보를 발급받아야 함. 오픈소스 구현도 은행과 계약을 맺고 UL 같은 곳을 통한 실험실 검증을 거쳐야 할 가능성이 큼
  • 유일한 “비법”은 책임 전환임. 전통적인 온라인·비접촉 결제는 “카드 소지자 부재” 거래로 분류되어 사기 책임이 가맹점에 더 많이 감
    Apple Pay와 Google Pay, 은행 제공 결제 앱들은 생체인증으로 카드 소지자 승인을 확인해 일부 결제를 “카드 소지자 존재”로 바꿈
    그래서 일부 차지백 유형은 즉시 거절되고, 다른 유형도 가맹점 증빙 요구가 낮아짐
    이건 카드 네트워크 표준의 일부이고, 관심 있으면 https://www.emvco.com/에서 볼 수 있음
    오픈소스 옵션이 없는 이유는 구현의 보안을 인증해야 해서 은행과 일할 상업 주체가 필요하기 때문임. 게다가 은행마다 따로 통합해야 하니 상대해야 할 은행이 너무 많음
  • Google Pay에서 Amex는 거부되고 MasterCard는 되는 경우는 보통 카드 단말기 제공자의 설정 문제이거나, 카드 체계와 통신하는 매입사 백엔드에서 모바일 지갑 기능 인증이 부족해서 생김
    모든 카드 체계, 모든 결제 방식, 모든 기기를 아우르는 종단 간 거래를 제대로 동작하게 만드는 일은 꽤 까다로움. 카드 체계마다 지원하는 “결제 커널” 매개변수와 인증 요구사항이 다름
    또는 거래 수수료를 아끼려는 시도일 수도 있음. Amex는 일반적으로 가맹점에 훨씬 비쌈
  • 여기에 좋은 정보가 있음
    https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...

• Apple Pay가 처음 널리 쓰이기 시작했을 때, 소매 결제 처리 경험을 바탕으로 꽤 자세히 살펴봤음. 당시 가장 인상 깊었던 건 그것이 얼마나 업계 표준에 깊게 뿌리내리고 있었는지였음
  무선 통신 이후의 어떤 부분도 Apple 전용이 아니었고, 이 글을 읽어보면 지금까지도 그 점은 유지된 것으로 보임
  당시 카드 기반 탭투페이를 의도적으로 받던 일부 가맹점은, 매우 표준적인 Apple 탭투페이를 의도치 않게 받게 되자 시스템을 바꿔야 했던 것으로 기억함. CVS가 특히 떠오르는데, 경쟁 결제 체계에 참여하고 있어서 그 체계가 매장에서 된다는 점을 Apple Pay와의 차별점으로 삼고 싶어 했던 것 같음
  최근 “이건 Apple Pay만 한다”는 신화가 생기기 시작했을 때, 내가 마지막으로 봤던 때 이후 뭔가 바뀐 건가 싶어 의아했는데, 저자가 이 맥락에서 최신 검토를 해줘서 반가움

  • 개인적인 일화로, Apple Pay가 처음 출시됐을 때는 미국에서만 동작했음. 더 정확히는 미국에서만 설정할 수 있었음. 그 직후 탭투페이가 표준인 호주로 이사했음
    공식 지원은 아니었는데도 호주 어디서나 Apple Pay가 동작해서 꽤 놀라웠음. 미국에서는 극소수 가맹점만 지원했지만, 호주는 표준 기반이라 POS의 99%가 이미 지원했던 셈임
  • 표준 기반이었지만 Apple의 출시와 마케팅 방식은 꽤 영리해서, Apple Pay가 유일한 휴대폰 탭투페이인 듯한 인상을 줬음. 가맹점은 “Apple Pay accepted” 표지판을 붙이고 Google은 언급하지 않아, 비Apple 결제가 되는지 혼란이 생겼음
    Android 결제의 혼란스러운 상태도 한몫함. Samsung Pay는 NFC를 뜻할 수도 있고 마그네틱 스트라이프 에뮬레이션을 뜻할 수도 있었음. Google은 브랜딩을 못하기로 유명하고, Wallet과 Google Pay의 여러 반복 사이에서 아직도 뭐가 뭔지 파악하기 어려움
  • 가장 웃긴 건 Apple Pay가 모바일 결제 시장에 늦게 들어온 축이었다는 걸 사람들이 잊는다는 점임. 사실상 마지막에 가까웠음

• 이런 논의에서 빠진 점은 Apple Pay와 Google Pay, Samsung Pay 같은 지갑의 거래도 이제는 기반 카드 번호로 한 거래만큼 추적 가능하다는 것임
  DPAN은 특정 기기에 고유하지만, 요즘 가맹점의 결제 서비스 제공자는 카드 네트워크의 승인 응답에서 PAR이라는 고유 식별자를 받을 수 있음. 이 식별자는 같은 카드의 모든 DPAN에서 동일하고, 같은 기본 계좌라면 카드 번호가 바뀌어도 유지되는 방향을 목표로 함
  PAR로는 가맹점이 결제 청구를 할 수 없으므로 보안 문제는 아니지만, 디지털 지갑 결제가 일반 카드나 카드 번호 결제보다 더 사적일 거라고 기대하면 안 됨
  https://wcapra.com/payment-account-reference-capraplus-your-...
  https://www.securetechalliance.org/wp-content/uploads/EMVCo-...

  • 정부 조치가 없는 한 앞으로 어떤 것도 더 사적이 될 거라고 기대하지 않음
  • 일본은 그렇지 않음. Apple Pay가 익명 ICOCA/Suica 카드를 쓰고, 원하면 삭제하고 다시 만들 수 있음
  • 호주의 내 지역 은행인 NAB는 같은 기본 계좌에서 카드 번호가 바뀌어도 이걸 유지함. 여기 대부분의 신용카드에서는 꽤 일반적일 것 같음

• Matt Birchler의 글에는 “이전 버전에서는 DPAN이 가맹점마다 바뀐다고 했지만 실수였다. 너무 급하게 쓴 내 잘못이다”라는 문단이 추가됐음. 그런데 글의 나머지 부분은 여전히 가맹점별 고유 DPAN이 있는 것처럼 보이고, 그 근거를 찾을 수 없음
  Apple 자체 문서 https://support.apple.com/en-us/HT203027도 DPAN, 여기서는 Device Account Number가 기기별로만 고유하다고 말함. 카드가 Apple Pay에 추가되면 해당 기기의 DPAN이 생성되고, 카드를 삭제했다가 다시 추가하지 않는 한 이후 바뀌지 않음
  그래서 같은 카드를 iPhone과 Apple Watch 두 기기에서 쓰면 DPAN이 달라 추적되기 어렵지만, 같은 기기에서 같은 카드를 여러 가맹점에 쓰면 데이터 브로커가 추적할 수 있다고 봄

  • 결제 업계에서는 DPAN을 일반적으로 안정적인 식별자로 보지 않음. 카드 추가·삭제와 무관하게 주기적으로 교체될 수 있음
  • 은행이 신용카드 데이터를 팔고 있다면, PAN이 다르다는 건 별 차이가 없음
  • Apple Pay로 결제할 때 카드 마지막 네 자리가 매번 달라지는 걸 봤음. 주로 Apple Watch를 쓰는데, 가맹점이 다를 때뿐 아니라 같은 가맹점에서도 달랐음

• 왜 SSO와 모바일 결제가 누구나 제공자를 만들 수 있는 표준 인터페이스가 아닌지 모르겠음. “Login with Google”이나 “Login with Apple” 대신 “내 기본 설정 SSO 제공자로 로그인”이 있어야 하는 것 아닌가? “내 기본 결제 제공자로 결제”도 마찬가지임
  더 나쁘게는 공급자나 사이트가 이런 제공자 중 일부만 지원하는 경우가 많아서, SSO가 사실상 SSO가 아니게 됨
  이유는 있겠지만 깊게 찾아보진 않았음. 모든 공급자가 따르는 공통 합의 규격이 있어야 할 것 같고, 없다면 언젠가 법으로 그렇게 강제될 가능성이 큼

  • SSO에서 찾는 건 RFC 7591[0]에 가까움. OAuth IdP에 즉석에서 등록하는 방법을 설명함. RFC 8414[1]는 등록 절차의 메타데이터를 가져올 well-known 위치를 설명함
    표준은 이미 있고, 이론적으로는 로그인 폼에 이메일을 입력하거나 브라우저가 자동완성하면 그 도메인의 OAuth 로그인으로 이어지고, 서버가 그 도메인과 처음 통신하는 경우 즉석에서 클라이언트 등록까지 할 수 있음. 실제로 쓰이는 건 본 적 없지만 있으면 좋겠음
    [0] https://datatracker.ietf.org/doc/html/rfc7591
    [1] https://datatracker.ietf.org/doc/html/rfc8414
  • 이유는 “성장과 참여” 때문임. 2010년쯤부터 기술은 사용자를 empower하는 도구에서 사용자 시간을 스팸으로 낭비시키는 도구로 바뀌었음
    서비스를 제공하고 공정한 요금을 받는 쪽에서, 사용자에게 스팸을 보내거나 데이터를 수집해 나중에 더 스팸을 보내는 쪽으로 이동했음
    열린 표준은 현 제공자들이 원하는 게 아님. 그러면 사용자가 쉽게 다른 대안으로 갈아타고 더 이상 “참여”하지 않게 되기 때문임
  • 사용자 검증 방식이 사업자마다 크게 달라서, 각 사업자는 자신들이 요구하는 기준을 SSO 공급자가 지키는지 심사하고 신뢰해야 함. SSO 공급자가 백만 개라면 각자가 어떤 기준을 지키는지 알기 어려움
  • “Login with Google”을 지원하려면 Google 쪽 설정이 필요함. 이 앱이 무엇이고, 인증 후 어느 URL로 리다이렉트해야 하는지 등을 알려줘야 함. 그렇지 않으면 보안 문제가 생김
  • 그건 고통스럽고 사기 유입의 자석이기 때문임. Stack Overflow가 어디서나 OpenID를 쓰도록 장려했을 때 문제가 생겼음

• 흥미롭게도 Apple Pay는 호주 현지 대형 은행들이 몇 년 동안 비접촉 결제 사용을 늘리려고 밀어붙인 뒤에 출시됐음. 그래서 Apple이 들어와 미국식 수수료를 요구했을 때, 인프라는 이미 은행들이 직접 깔아둔 상태였음
  호주 대형 은행들은 수년간 Apple Pay 지원을 버텼지만, 고객 압박이 너무 커지자 결국 물러섰음
  지금도 다들 이 일에 매우 불만이 있고, 규제기관이 NFC 칩 개방을 강제하면 즉시 Apple Pay를 버릴 것임. 하지만 지금까지는 국내 최대 은행들의 하소연에 공감해줄 사람을 찾기 어려웠음

  • 재미있게도 호주 은행들은 ACCC에 Apple Pay 조건을 놓고 Apple과 공동 협상하고 보이콧할 수 있도록 카르텔 구성 허가를 요청했지만 거절당했음
    https://www.accc.gov.au/media-release/accc-denies-authorisat...
  • 사용자들이 가만있지 않는 한 은행들이 Apple Pay를 버리긴 어려움
    캐나다 은행들도 Android에서 자체 비접촉 결제인 TD Pay 같은 걸 시도했지만 아무도 원하지 않았음. 결국 포기하고 Google Pay를 제공했음
    비슷하게 흘러갈 것으로 봄. Apple이 NFC 결제를 열어도 아무도 은행 앱을 쓰지 않고 Apple Pay나 Google Pay 같은 1차 지원을 선호할 것임
    Samsung Pay와 Google Pay 중 실제로 얼마나 많은 사람이 Samsung Pay를 쓰는지만 봐도 됨
  • Apple이 미국의 비접촉 결제 인프라를 만든 것도 아님. 비접촉 인터페이스는 이미 있었고, 자체 로고도 있었으며, 탭 카드로 사용할 수 있었음
    CVS 같은 일부 소매업체는 Apple Pay가 도입되자 탭 결제를 꺼버렸음
  • https://www.apple.com/newsroom/2024/01/apple-announces-chang...
  • Apple Pay 이전에 NAB 같은 은행들이 휴대폰 뒷면에 붙이는 NFC 스티커를 “봐라, Apple Pay만큼 좋다”는 식으로 제공하던 게 기억남

• “가맹점은 체크아웃에서 필요한 만큼의 개인 정보를 요청할 수 있고, Apple Pay가 이를 막지는 않는다”는 부분이 오프라인 쇼핑에서도 일어나는지 궁금함
  계란을 마트에서 사는 데 내 이름과 주소는 필요하지 않음. Apple/Google은 분명 필요하지 않은 정보도 공유할 때 내 동의를 요구하나? 약관이나 shrink-wrap EULA처럼 받아들이거나 떠나는 식인가?
  이런 결제 시스템은 써본 적 없음

  • POS 결제에서는 보통 기기 계정 번호인 DPAN만 가맹점에 공유됨. 이름도 대개 가려지며, 비접촉 카드와 비슷하고 칩·마그네틱 결제와는 다름
    글에서 언급한 추가 정보는 “온라인” 결제에서만 공유됨. 다만 여기에는 휴대폰으로 QR 코드를 스캔하고 Safari나 App Clip에서 결제하는 경우도 포함되며, 요즘 몇몇 식당에서 본 방식임
    그렇게 하면 식당은 요청한 만큼 정보를 받음. 이름, 주소, 이메일 주소까지 포함될 수 있음. 보통 결제 시트에 표시되는 것 같지만, 처음 식당에서 썼을 때는 잘 인식하지 못했음
    이제는 웨이터에게 실제 단말기를 가져와 탭하게 해달라고 하거나, 그냥 실물 카드를 줌

• 약간 주제에서 벗어나지만, Apple Pay가 거래 승인 전에 현재 결제할 금액을 화면에 보여주지 못하는 이유를 아직도 이해하지 못하겠음
  사용자 경험 문제가 아니라 Apple 기기가 그 금액을 아예 모르는 것 같음. 이유가 뭘까?

  • 휴대폰을 그냥 플라스틱 카드처럼 생각하면 됨. 휴대폰은 NFC 리더기의 요청을 기다리다가, 요청이 오면 “카드 번호”를 전송하고 끝임
    이걸 이해하는 데 시간이 좀 걸렸음. 비행기 모드에서 Apple Pay가 어떻게 동작하는지 이해하지 못했는데, 당연히 동작함. 기존 Visa 카드도 인터넷 연결 없이 잘 되기 때문임
    근본적으로 둘은 같은 것임. 모두가 표준대로 동작하면 추가로 “지원”할 것이 없는 이유도 그 때문임. jjcm의 형제 댓글 참고: https://news.ycombinator.com/item?id=39846117
    그래서 NFC 리더기가 결제 금액을 “방송”하지 않는다고 봄. 플라스틱 카드는 그 정보를 처리할 방법이 없었고, iPhone도 그 정보를 받아서 “잠깐, 사용자가 스와이프로 승인할 때까지 기다려”라고 할 방법이 없음

• Gruber가 “이건 Apple Pay만 한다”고 어디서 말했는지 모르겠음. 글쓴이는 Gruber가 몇 가지 실수했거나 세부사항을 정확히 잡지 못한 부분을 짚고, 그게 전부처럼 보임

  • https://daringfireball.net/linked/2024/03/21/garland-monopol...
    [업데이트: 이런, 내가 틀렸다. 결제 업계에서 일하는 Matt Birchler가 동작 방식을 잘 설명했고, 주요 은행과 신용카드사가 탭투페이 거래에서 가맹점별 “DPAN” 번호를 생성한다는 것이 드러났다. 그래도 Apple Wallet이 카드 발급사가 제공하는 어떤 디지털 결제 앱보다 적어도 동등하거나 더 안전하다는 내 주장은 유지한다.]
    원저자인 Gruber의 글임
  • “은행이나 신용카드 발급사가 NFC 탭투페이 접근 권한을 얻는다고 해서 스스로 이런 일을 할 가능성은 매우 낮다”는 부분에 대해, Birchler는 은행들이 실제로 했다고 짚었음
    Gruber도 자신의 실수를 인정했음
    Gruber는 공개적인 Apple 팬이지만 대체로 사실관계는 맞추고, 모르는 부분은 인정하며, 해당 분야 전문가를 링크하던 편이었음
    하지만 EU DMA의 Apple 조치 이후로는 객관성을 완전히 잃은 것처럼 보임. EC보다 법률 문구를 더 잘 이해하는 척하고, 매우 다른 유럽 입법 방식에 미국식 접근을 적용하고, Apple의 악의적인 발언을 그대로 받아들이는 식임
    이 변화는 Apple의 EU에 대한 이상할 정도의 악의적인 태도와 맞물려 있어서, 근본 문제는 Gruber가 Apple을 너무 신뢰하는 것일 수도 있음
    미국 정부의 반독점 소송에도 그 태도를 이어가는 것 같음
    공정하게 보자면, 소셜 미디어에는 법률 전문가인 척하는 Apple 지지자들이 가득하고 거의 모든 것을 틀리게 말하므로, 그가 합법적인 반대 관점을 보기 어려울 수도 있음
  • “Apple Pay가 이것을 한다”와 “Apple Pay만 이것을 한다”는 큰 차이가 있음. Gruber는 전자를 말한 것 같은데, 저자는 어쩐지 후자로 읽은 듯함

• “Apple은 이런 디지털 지갑을 대중화하는 데 훌륭한 일을 했지만, 그들이 하는 일은 업계에서 고유한 것이 아니다”라는 부분에 대해, 기억이 틀릴 수도 있지만 Apple Pay가 처음 나왔을 때는 꽤 독특했다고 생각함. 그래서 지원하는 곳이 매우 적었음
  다른 휴대폰 결제 시스템, 예를 들면 초기 Samsung Pay 같은 것은 카드 번호를 단말기에 그대로 보냈던 것 같음

  • 미국에서는 드물었음. 유럽과 아시아에서는 비접촉 결제가 한동안 지원됐고, 영국은 2007년부터 가능했음. 다만 영국은 적어도 초기에는 한도가 꽤 낮았음
    흥미롭게도 영국은 아직도 £100 한도가 있는 것 같은데, 미국에서는 Android 휴대폰 비접촉 결제로 $2000가 넘는 금액도 결제해봤음
  • 당시에도 한두 가지 다른 방식이 있었지만, 과장된 자동완성에 가까웠던 것 같음. Google Pay의 어떤 버전은 웹사이트에 정보를 채우는 것이었고, 백그라운드에서 실제 카드 번호를 어떻게든 넘겼던 것으로 기억함
    아마 은행에만 직접 보내서 가맹점은 보지 못했을 수도 있지만, 그래도 실제 번호였음. DPAN을 쓴 것으로 처음 들은 건 Apple이었음
  • EMVCo의 비접촉 규격은 항상 토큰화된 카드 번호였음. Samsung Pay가 온라인 결제에서 PAN을 넘겼을 수는 있음
  • Apple Pay는 시장에 들어온 마지막 주요 구현에 가까웠다고 봄. EMV 표준 기반의 첫 구현은 원래 Google Wallet이었고, Google 특유의 글로벌 출시 실패로 막혔음
    미국은 여러 이유로 카드 결제 기술이 매우 뒤처져 있음. 폴란드에서 전 세계에서 수년간 쓰던 카드를 들고 방문했을 때, 계산원이 결제할 수 있도록 특수한 우회 방법부터 배워야 했을 정도였음