Những hiểu lầm về cách Apple Pay hoạt động

 (birchtree.me)
1 điểm bởi GN⁺ 2024-03-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Cơ chế che giấu số thẻ thực tế không phải là tính năng riêng của Apple Pay mà là phương thức thanh toán cũng được dùng trong các ví điện tử lớn như Google Pay và Samsung Pay
  • Điểm cốt lõi là sự tách biệt giữa FPAN, số thẻ vật lý, và DPAN, số thanh toán theo từng thiết bị; ngay cả cùng một thẻ thì iPhone và iPad cũng dùng các DPAN khác nhau
  • DPAN có thể khiến việc theo dõi giữa nhiều người bán trở nên khó hơn, nhưng trong cùng một người bán thì nó vẫn được giữ lại cho các giao dịch tiếp theo, nên không ngăn được việc theo dõi lịch sử mua hàng trong một người bán duy nhất
  • Khi xảy ra rò rỉ thông tin thanh toán, DPAN an toàn hơn FPAN, và DPAN chỉ hoạt động khi được gửi kèm với gói mã hóa duy nhất gắn cho từng giao dịch
  • Apple Pay không tự động che giấu thông tin cá nhân như tên, email, địa chỉ thanh toán/giao hàng hay mặt hàng đã mua; nên có thể xem những thông tin hiển thị trên màn hình thanh toán là sẽ được chuyển cho người bán

DPAN không phải tính năng độc quyền của Apple Pay

  • Khi nói Apple Pay che giấu số thẻ tín dụng thực, điểm mấu chốt nằm ở DPAN
  • FPAN là funding primary account number gồm 15~18 chữ số được in trên thẻ vật lý, còn DPAN là device primary account number
  • Có thể hiểu DPAN tương tự như bản ghi DNS
    • Người dùng vẫn truy cập website bằng tên miền mà không cần biết địa chỉ IP thực tế
    • Ngay cả cùng một thẻ, nếu dùng Apple Pay trên iPhone và iPad thì mỗi thiết bị sẽ nhận một số riêng và dùng DPAN khác nhau
  • Điều quan trọng là ngay từ tên gọi, nó không phải là “Apple Pay number”
    • Google Pay và Samsung Pay, những ví điện tử lớn tại Mỹ, cũng che giấu số thẻ thực theo cùng cách này
    • Các nút Amazon Pay và Shop Pay cũng khiến thanh toán được xử lý qua công ty khác, nên về mặt kỹ thuật không phải DPAN, nhưng vẫn không để người bán nhìn thấy FPAN thực

Người bán và ngân hàng cũng muốn giảm việc lộ số thẻ thực

  • Nếu người bán trực tiếp xử lý số thẻ tín dụng thực, gánh nặng rủi ro sẽ tăng lên
  • Các công cụ chấp nhận thanh toán hiện đại được thiết kế để thu thập thông tin thanh toán theo cách giảm tối đa số người có thể truy cập dữ liệu thẻ thực
  • Suy đoán rằng ngân hàng sẽ không dùng DPAN là không khớp với thực tế
    • Nhiều ngân hàng như Wells Fargo, Chase và Bank of America đã hoặc từng vận hành ví điện tử riêng, và tất cả đều bảo vệ số tài khoản thông thường bằng DPAN
    • Paze, dịch vụ đang được các ngân hàng lớn của Mỹ sử dụng, cũng dùng DPAN
    • Một trong những lý do chính mà Paze nêu ra là “Paze does not share your actual card number with the merchant.”

Kiểu theo dõi mà DPAN ngăn được và không ngăn được

  • Nói rằng DPAN thay đổi theo từng giao dịch là không chính xác
  • Với các giao dịch tiếp diễn tại cùng một người bán, cùng một DPAN sẽ được sử dụng
  • Cấu trúc này có thể tạo ra rào cản cho các data broker muốn mua dữ liệu giao dịch từ nhiều người bán để suy ra xu hướng mua sắm của một cá nhân
  • Ngược lại, một người bán đơn lẻ vẫn có thể xem lịch sử giao dịch của khách hàng đó chỉ bằng DPAN mà Apple Pay cung cấp
    • Apple Pay không ngăn được những tình huống như trường hợp Target suy đoán tình trạng khách hàng dựa trên lịch sử mua hàng của chính mình
    • Các ví điện tử khác cũng có cùng giới hạn này

Sự bảo vệ mà DPAN mang lại khi xảy ra rò rỉ dữ liệu

  • Trong tình huống thông tin thẻ thanh toán bị rò rỉ, DPAN an toàn hơn FPAN
  • Năm 2024, người bán lẽ ra không nên trực tiếp xử lý số thẻ tín dụng, nhưng vẫn có thể xảy ra trường hợp cổng thanh toán bị hack làm lộ DPAN và ngày hết hạn
  • Kẻ tấn công không thể thực hiện thanh toán chỉ với DPAN bị lộ
    • DPAN chỉ hoạt động khi được gửi như một phần của gói mã hóa riêng cho từng giao dịch
    • Có cách để thực hiện thanh toán lặp lại với thẻ đã được thu thập qua Apple Pay, nhưng đó không phải điều hacker có thể làm được
  • Vì vậy, so với việc DPAN do các ví điện tử thu thập bị lộ, rò rỉ FPAN nguy hiểm hơn rất nhiều

Apple Pay không tự động che giấu thông tin cá nhân

  • Ý nghĩ rằng Apple Pay tự động ẩn thông tin cá nhân là không đúng sự thật
  • Nếu thực hiện một giao dịch Apple Pay thực tế trong tài khoản người bán thử nghiệm, báo cáo ở cấp độ người bán sẽ hiển thị các thông tin như tên, email, địa chỉ thanh toán và địa chỉ nhà
  • Với thanh toán hàng hóa vật lý, thông tin giao hàng là cần thiết, nên Apple Pay SDK cho phép người bán chọn loại thông tin cá nhân muốn nhận từ khách hàng
  • Thông tin sản phẩm cũng được chuyển tới Apple Pay để hiển thị cho người mua biết họ đang mua gì, và thông tin này cũng được chuyển cho người bán
  • Có thể xem thông tin hiển thị trên thẻ Apple Pay tại thời điểm thanh toán là sẽ được chuyển cho người bán
    • Ở điểm này, Apple Pay cũng giống các phương thức thanh toán khác
    • Người bán sẽ chọn yêu cầu những thông tin cá nhân cần hoặc muốn có trong bước checkout
    • Các ví điện tử khác cũng hoạt động theo cách tương tự

Sự bảo vệ mà ví điện tử thực sự mang lại

  • Apple Pay là một phương thức thanh toán tốt, và Apple đã góp phần phổ biến kiểu ví điện tử này tới đại chúng
  • Tuy vậy, các tính năng của Apple Pay không phải là độc nhất trong ngành
  • DPAN hữu ích trong việc khiến quá trình theo dõi mua sắm của một cá nhân qua nhiều người bán trở nên khó hơn, đồng thời giảm rủi ro cho khách hàng khi thông tin thẻ thanh toán bị rò rỉ

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-29
Ý kiến trên Hacker News

  • Muốn được giải thích kiểu ELI5 về cách Apple Pay và Google Pay thực sự hoạt động. Trước đây tôi nghĩ họ chỉ chuyển thông tin thẻ cho bên bán hoặc đơn vị xử lý thanh toán, và bài gốc cũng có vẻ như vậy, nhưng tôi cũng từng thấy khi dùng Amex trên Google Pay thì một số nơi bán từ chối thanh toán, trong khi MasterCard lại được chấp nhận
    Đôi khi Apple/Google tạo cảm giác như đang hoạt động như một bên xử lý thanh toán hay thậm chí là chính phương thức thanh toán. Vì họ thu thập dữ liệu giao dịch, và các máy POS trong siêu thị cũng có vẻ như từng cần hỗ trợ riêng cho ứng dụng Apple/Google Pay
    Vậy thì bí quyết độc quyền riêng của Apple/Google là gì, và vì sao khó hoặc không thể thay thế bằng một phương án mã nguồn mở? Có phải là vì trên iOS/Android chỉ Apple/Google mới có thể truy cập đầy đủ vào chip NFC không?
    https://news.ycombinator.com/item?id=39845805

    • Thực ra Apple/Google không có bí quyết riêng gì cả. Nhiều ngân hàng trên thế giới cung cấp ví HCE của riêng họ, nhưng chỉ hoạt động trên Android. Apple đã không cung cấp API cần thiết, và ở EU thì hiện giờ điều này đang thay đổi
      Điều quan trọng là mặc định. Mỗi thiết bị chỉ có thể đặt một ví Visa hoặc Mastercard mặc định, và bên nào không cần phải mở ứng dụng trước khi chạm để thanh toán thì có lợi thế. Google Pay hỗ trợ thẻ của nhiều ngân hàng, nên có ưu thế lớn hơn so với ví HCE của từng ngân hàng phát hành cụ thể
      Apple/Google có tham gia làm trung gian khi đăng ký thẻ mới vào một thiết bị cụ thể, nhưng không tham gia vào luồng giao dịch POS thực tế
      Bên bán vẫn phải chấp nhận thương hiệu thẻ nền tảng. Google Pay và Apple Pay hiện đại không phải là thẻ proxy dùng để đổi thương hiệu thẻ, và khác với các dịch vụ như Curve
      Thiết bị đầu cuối ngoại tuyến không cần hỗ trợ riêng. Trừ khi thiết bị đầu cuối có lỗi, nếu nơi đó chấp nhận hệ thống thẻ nền tảng thì sẽ hoạt động. Giao thức vật lý và logic giống như thẻ nhựa, và từ góc nhìn của thiết bị đầu cuối thì gần như không thể phân biệt
      Trên web thì khác. Website mua sắm và nhà cung cấp dịch vụ thanh toán phải hỗ trợ một cách tường minh
    • Apple/Google Pay sử dụng EMV không tiếp xúc, tức là cơ chế giống như thẻ tín dụng không tiếp xúc. Đây là tiêu chuẩn đứng sau Paywave của Visa và Paypass của MC
      Vì vậy các thiết bị đầu cuối không dây nhìn chung đã chấp nhận Apple Pay và Google Pay một cách tự nhiên, không cần quá nhiều hỗ trợ đặc biệt. Một thay đổi mà tôi nhớ là các thiết bị kiểu này được xem là an toàn hơn, nên hạn mức thanh toán được nâng cao hơn so với thẻ không tiếp xúc
      Lý do khó có bản triển khai mã nguồn mở là vì việc triển khai EMV rất phức tạp, và cần nhiều thử nghiệm cũng như xác thực bằng thiết bị chuyên dụng. Thiết bị cần có vùng bảo mật để lưu trữ khóa riêng an toàn, và ứng dụng phải có khả năng xác nhận rằng xác thực sinh trắc học hoặc mở khóa bằng PIN đã được sử dụng để đảm bảo an toàn cho người dùng
      Ngoài ra, trong quá trình thiết lập còn phải tích hợp với backend của ngân hàng phát hành thẻ để nhận các khóa và thông tin cần thiết. Ngay cả một bản triển khai mã nguồn mở cũng rất có thể phải ký hợp đồng với ngân hàng và trải qua xác thực trong phòng thí nghiệm thông qua những nơi như UL
    • “Bí quyết” duy nhất là chuyển trách nhiệm. Thanh toán trực tuyến và không tiếp xúc truyền thống được phân loại là giao dịch “không có chủ thẻ hiện diện”, nên trách nhiệm gian lận nghiêng nhiều hơn về phía bên bán
      Apple Pay, Google Pay và các ứng dụng thanh toán do ngân hàng cung cấp xác nhận sự chấp thuận của chủ thẻ bằng sinh trắc học, từ đó biến một số khoản thanh toán thành “có chủ thẻ hiện diện”
      Vì vậy một số kiểu chargeback sẽ bị từ chối ngay, còn với những kiểu khác thì yêu cầu chứng minh từ phía bên bán cũng được giảm bớt
      Đây là một phần của tiêu chuẩn mạng lưới thẻ, và nếu quan tâm thì có thể xem tại https://www.emvco.com/
      Lý do không có lựa chọn mã nguồn mở là vì cần chứng nhận tính bảo mật của phần triển khai, nên phải có một thực thể thương mại để làm việc với ngân hàng. Hơn nữa còn phải tích hợp riêng với từng ngân hàng, nên số lượng ngân hàng phải làm việc cùng là quá lớn
    • Trường hợp Amex bị từ chối còn MasterCard thì được trên Google Pay thường là do vấn đề cấu hình của nhà cung cấp thiết bị đầu cuối thẻ, hoặc do backend của bên thanh toán kết nối với hệ thống thẻ thiếu chứng nhận tính năng ví di động
      Việc làm cho một giao dịch đầu cuối hoạt động trơn tru trên mọi hệ thống thẻ, mọi phương thức thanh toán và mọi thiết bị là khá khó. Mỗi hệ thống thẻ có các tham số “payment kernel” và yêu cầu chứng nhận hỗ trợ khác nhau
      Hoặc cũng có thể là một nỗ lực nhằm tiết kiệm phí giao dịch. Amex thường đắt hơn nhiều đối với bên bán
    • Có thông tin hay ở đây
      https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...

  • Khi Apple Pay bắt đầu được sử dụng rộng rãi lần đầu, tôi đã xem xét nó khá kỹ dựa trên kinh nghiệm xử lý thanh toán bán lẻ của mình. Điều gây ấn tượng nhất lúc đó là nó bám rễ sâu đến mức nào vào các tiêu chuẩn của ngành
    Không có phần nào sau giao tiếp không dây là dành riêng cho Apple, và đọc bài này thì có vẻ đến nay điều đó vẫn không thay đổi
    Tôi nhớ khi đó một số cửa hàng vốn cố ý chấp nhận tap-to-pay dựa trên thẻ, đã vô tình chấp nhận cả Apple tap-to-pay rất tiêu chuẩn, nên phải thay đổi hệ thống. Tôi đặc biệt nhớ đến CVS; có vẻ họ tham gia một hệ thống thanh toán cạnh tranh và muốn dùng việc hệ thống đó hoạt động trong cửa hàng như một điểm khác biệt so với Apple Pay
    Khi gần đây bắt đầu xuất hiện huyền thoại kiểu “cái này chỉ Apple Pay mới làm được”, tôi đã thấy lạ không biết có gì thay đổi kể từ lần cuối mình xem hay không, nên rất mừng vì tác giả đã cập nhật lại trong bối cảnh này

    • Một giai thoại cá nhân: khi Apple Pay mới ra mắt, nó chỉ hoạt động ở Mỹ. Chính xác hơn là chỉ có thể thiết lập ở Mỹ. Ngay sau đó tôi chuyển đến Úc, nơi tap-to-pay là tiêu chuẩn
      Dù không được hỗ trợ chính thức, Apple Pay vẫn hoạt động ở khắp nơi tại Úc, điều này khiến tôi khá bất ngờ. Ở Mỹ chỉ có rất ít cửa hàng hỗ trợ, nhưng ở Úc thì vì dựa trên tiêu chuẩn nên 99% POS đã hỗ trợ sẵn rồi
    • Dù dựa trên tiêu chuẩn, cách Apple tung ra và tiếp thị sản phẩm khá khôn khéo, tạo cảm giác như Apple Pay là tap-to-pay bằng điện thoại duy nhất. Cửa hàng dán biển “Apple Pay accepted” mà không nhắc đến Google, khiến mọi người bối rối không biết thanh toán không phải Apple có dùng được không
      Tình trạng rối rắm của thanh toán Android cũng góp phần vào đó. Samsung Pay có thể mang nghĩa NFC hoặc giả lập dải từ. Google thì nổi tiếng là không giỏi xây dựng thương hiệu, và giữa nhiều vòng lặp của Wallet với Google Pay, đến giờ vẫn khó hiểu chính xác cái nào là cái nào
    • Điều buồn cười nhất là mọi người quên mất rằng Apple Pay thực ra thuộc nhóm vào thị trường thanh toán di động muộn. Gần như là một trong những bên cuối cùng

  • Điều còn thiếu trong các cuộc thảo luận này là giao dịch từ các ví như Apple Pay, Google Pay và Samsung Pay hiện nay cũng có thể bị theo dõi gần tương đương giao dịch bằng số thẻ nền tảng
    DPAN là duy nhất cho từng thiết bị, nhưng ngày nay nhà cung cấp dịch vụ thanh toán của cửa hàng có thể nhận được một mã định danh duy nhất gọi là PAR trong phản hồi chấp thuận từ mạng thẻ. Mã này giống nhau trên mọi DPAN của cùng một thẻ, và còn hướng tới việc vẫn giữ nguyên ngay cả khi số thẻ thay đổi miễn là cùng một tài khoản cơ sở
    Không thể dùng PAR để cửa hàng lập yêu cầu thanh toán nên đây không phải vấn đề bảo mật, nhưng đừng kỳ vọng thanh toán ví số sẽ riêng tư hơn thanh toán bằng thẻ thông thường hay số thẻ
    https://wcapra.com/payment-account-reference-capraplus-your-...
    https://www.securetechalliance.org/wp-content/uploads/EMVCo-...

    • Tôi không kỳ vọng bất cứ thứ gì trong tương lai sẽ trở nên riêng tư hơn nếu không có biện pháp từ chính phủ
    • Nhật Bản thì không như vậy. Apple Pay dùng thẻ ICOCA/Suica ẩn danh, và nếu muốn bạn có thể xóa rồi tạo lại
    • NAB, ngân hàng địa phương của tôi ở Úc, vẫn giữ nguyên điều này ngay cả khi số thẻ thay đổi trên cùng một tài khoản cơ sở. Có lẽ đây là điều khá phổ biến với hầu hết thẻ tín dụng ở đây

  • Trong bài của Matt Birchler có thêm một đoạn: “Ở phiên bản trước tôi đã nói DPAN thay đổi theo từng cửa hàng, nhưng đó là lỗi. Tôi viết quá vội nên nhầm.” Tuy nhiên phần còn lại của bài vẫn tạo cảm giác như có DPAN riêng cho từng cửa hàng, và tôi không tìm thấy cơ sở cho điều đó
    Tài liệu của chính Apple https://support.apple.com/en-us/HT203027 cũng nói DPAN, ở đây gọi là Device Account Number, chỉ duy nhất theo thiết bị. Khi thêm thẻ vào Apple Pay, DPAN của thiết bị đó sẽ được tạo ra và sau đó không đổi trừ khi bạn xóa thẻ rồi thêm lại
    Vì vậy nếu bạn dùng cùng một thẻ trên hai thiết bị là iPhone và Apple Watch thì DPAN sẽ khác nhau nên khó theo dõi hơn, nhưng nếu dùng cùng một thẻ trên cùng một thiết bị ở nhiều cửa hàng thì tôi cho rằng các data broker vẫn có thể theo dõi được

    • Trong ngành thanh toán, DPAN thường không được xem là một mã định danh ổn định. Nó có thể bị thay định kỳ, không liên quan đến việc thêm hay xóa thẻ
    • Nếu ngân hàng đang bán dữ liệu thẻ tín dụng, thì việc PAN khác nhau cũng chẳng tạo ra nhiều khác biệt
    • Tôi đã thấy bốn số cuối của thẻ thay đổi qua từng lần khi thanh toán bằng Apple Pay. Tôi chủ yếu dùng Apple Watch, và nó thay đổi không chỉ giữa các cửa hàng khác nhau mà ngay cả tại cùng một cửa hàng

  • Tôi không hiểu vì sao SSO và thanh toán di động lại không phải là giao diện tiêu chuẩn để bất kỳ ai cũng có thể làm nhà cung cấp. Thay vì “Login with Google” hay “Login with Apple”, chẳng phải nên có “đăng nhập bằng nhà cung cấp SSO mặc định của tôi” sao? “thanh toán bằng nhà cung cấp thanh toán mặc định của tôi” cũng tương tự
    Tệ hơn nữa là nhà cung cấp hoặc website thường chỉ hỗ trợ một số nhà cung cấp trong số đó, khiến SSO trên thực tế không còn là SSO nữa
    Chắc hẳn có lý do, nhưng tôi chưa tìm hiểu sâu. Có vẻ nên có một đặc tả chung được mọi nhà cung cấp tuân theo, và nếu chưa có thì sau này rất có thể sẽ bị luật pháp bắt buộc

    • Với SSO, thứ bạn đang tìm có lẽ gần với RFC 7591[0]. Nó mô tả cách đăng ký tức thời với một OAuth IdP. RFC 8414[1] mô tả vị trí well-known để lấy metadata của quy trình đăng ký đó
      Tiêu chuẩn đã tồn tại rồi, và về lý thuyết, nhập email vào form đăng nhập hoặc để trình duyệt tự động điền có thể dẫn đến đăng nhập OAuth của tên miền đó, và nếu máy chủ đang giao tiếp với tên miền đó lần đầu thì thậm chí còn có thể đăng ký client ngay lập tức. Tôi chưa từng thấy nó được dùng ngoài thực tế, nhưng sẽ rất hay nếu có
      [0] https://datatracker.ietf.org/doc/html/rfc7591
      [1] https://datatracker.ietf.org/doc/html/rfc8414
    • Lý do là vì “tăng trưởng và tương tác”. Từ khoảng năm 2010, công nghệ đã chuyển từ công cụ trao quyền cho người dùng sang công cụ lãng phí thời gian của người dùng bằng spam
      Đã có sự chuyển dịch từ việc cung cấp dịch vụ và thu phí công bằng sang việc spam người dùng hoặc thu thập dữ liệu để sau này spam thêm nữa
      Tiêu chuẩn mở không phải là điều các nhà cung cấp hiện tại mong muốn. Vì như vậy người dùng có thể dễ dàng chuyển sang lựa chọn khác và không còn “tương tác” nữa
    • Cách xác minh người dùng khác nhau rất nhiều giữa các doanh nghiệp, nên mỗi doanh nghiệp phải thẩm định và tin tưởng rằng nhà cung cấp SSO có đáp ứng các tiêu chuẩn mà họ yêu cầu hay không. Nếu có cả triệu nhà cung cấp SSO thì rất khó biết mỗi bên đang tuân thủ tiêu chuẩn nào
    • Để hỗ trợ “Login with Google”, phía Google cần có cấu hình. Bạn phải cho họ biết ứng dụng này là gì, URL nào sẽ được redirect tới sau khi xác thực, v.v. Nếu không thì sẽ phát sinh vấn đề bảo mật
    • Vì nó phiền toái và là thỏi nam châm hút gian lận. Stack Overflow từng gặp vấn đề khi khuyến khích dùng OpenID ở mọi nơi

  • Điều thú vị là Apple Pay được ra mắt ở Úc sau khi các ngân hàng lớn trong nước đã thúc đẩy việc dùng thanh toán không tiếp xúc trong nhiều năm. Vì vậy khi Apple bước vào và đòi mức phí kiểu Mỹ, hạ tầng lúc đó đã do chính các ngân hàng tự dựng sẵn
    Các ngân hàng lớn của Úc đã chống lại việc hỗ trợ Apple Pay trong nhiều năm, nhưng cuối cùng phải lùi bước vì áp lực khách hàng quá lớn
    Đến giờ mọi người vẫn rất bất mãn về chuyện này, và nếu cơ quan quản lý buộc phải mở chip NFC thì họ sẽ lập tức bỏ Apple Pay. Nhưng cho đến nay vẫn khó tìm được ai đồng cảm với lời than phiền của các ngân hàng lớn nhất nước

    • Thú vị là các ngân hàng Úc từng đề nghị ACCC cho phép họ lập cartel để cùng đàm phán với Apple về điều khoản Apple Pay và tẩy chay Apple, nhưng đã bị từ chối
      https://www.accc.gov.au/media-release/accc-denies-authorisat...
    • Trừ khi người dùng chịu ngồi yên, còn không thì ngân hàng khó mà bỏ Apple Pay
      Các ngân hàng Canada cũng từng thử giải pháp thanh toán không tiếp xúc riêng trên Android như TD Pay, nhưng chẳng ai muốn dùng. Cuối cùng họ bỏ cuộc và cung cấp Google Pay
      Tôi nghĩ rồi cũng sẽ diễn ra tương tự. Kể cả Apple có mở NFC cho thanh toán thì cũng sẽ không ai dùng app của ngân hàng, mà vẫn thích hỗ trợ trực tiếp kiểu Apple Pay hay Google Pay hơn
      Cứ nhìn xem trong số Samsung Pay và Google Pay thì thực tế có bao nhiêu người dùng Samsung Pay là biết
    • Apple cũng không phải là bên xây dựng hạ tầng thanh toán không tiếp xúc ở Mỹ. Giao diện không tiếp xúc đã tồn tại từ trước, có logo riêng, và có thể dùng bằng thẻ chạm
      Một số nhà bán lẻ như CVS thậm chí còn tắt thanh toán chạm khi Apple Pay được giới thiệu
    • https://www.apple.com/newsroom/2024/01/apple-announces-chang...
    • Tôi nhớ là trước thời Apple Pay, các ngân hàng như NAB từng phát miếng dán NFC để dán vào mặt sau điện thoại như thể muốn nói “đấy, cũng tốt như Apple Pay thôi mà”

  • Tôi tò mò liệu phần “merchant có thể yêu cầu lượng thông tin cá nhân cần thiết tại bước checkout, và Apple Pay không ngăn điều đó” có xảy ra cả trong mua sắm trực tiếp không
    Mua trứng ở siêu thị thì đâu cần tên và địa chỉ của tôi. Apple/Google có thực sự yêu cầu tôi đồng ý khi chia sẻ cả những thông tin không cần thiết không? Hay lại kiểu chấp nhận hoặc rời đi như điều khoản sử dụng hay shrink-wrap EULA?
    Tôi chưa từng dùng các hệ thống thanh toán kiểu này

    • Với thanh toán qua POS, thông thường chỉ có DPAN, tức số tài khoản thiết bị, được chia sẻ với merchant. Tên cũng thường bị che đi, tương tự thẻ không tiếp xúc và khác với thanh toán bằng chip hoặc dải từ
      Thông tin bổ sung được nhắc đến trong bài chỉ được chia sẻ trong thanh toán “trực tuyến”. Tuy vậy, điều này cũng bao gồm trường hợp quét mã QR bằng điện thoại rồi thanh toán trong Safari hoặc App Clip, kiểu mà tôi thấy ở một số nhà hàng dạo gần đây
      Làm vậy thì nhà hàng sẽ nhận được lượng thông tin mà họ yêu cầu. Có thể bao gồm tên, địa chỉ, thậm chí cả địa chỉ email. Hình như thường có hiển thị trong payment sheet, nhưng lần đầu tôi dùng ở nhà hàng thì không nhận ra rõ
      Giờ thì tôi sẽ yêu cầu nhân viên mang máy POS thật đến để tôi chạm thanh toán, hoặc đơn giản là đưa thẻ vật lý

  • Hơi lạc đề một chút, nhưng tôi vẫn không hiểu vì sao Apple Pay không thể hiển thị số tiền hiện tại cần thanh toán trên màn hình trước khi giao dịch được chấp thuận
    Có vẻ đây không phải vấn đề trải nghiệm người dùng mà là thiết bị Apple hoàn toàn không biết số tiền đó. Lý do là gì?

    • Cứ xem điện thoại như một chiếc thẻ nhựa là được. Điện thoại chờ yêu cầu từ đầu đọc NFC, rồi khi có yêu cầu thì gửi “số thẻ” đi là xong
      Tôi đã mất một thời gian mới hiểu được điều này. Tôi không hiểu Apple Pay hoạt động thế nào ở chế độ máy bay, nhưng dĩ nhiên là nó vẫn hoạt động. Vì thẻ Visa thông thường cũng hoạt động tốt mà không cần kết nối Internet
      Về cơ bản, hai thứ đó là một. Nếu mọi bên đều hoạt động theo tiêu chuẩn thì cũng vì thế mà không có gì cần “hỗ trợ” thêm. Xem bình luận anh em của jjcm: https://news.ycombinator.com/item?id=39846117
      Vì vậy tôi cho rằng đầu đọc NFC không “phát” số tiền thanh toán. Thẻ nhựa vốn không có cách nào xử lý thông tin đó, và iPhone cũng không có cách để nhận thông tin đó rồi nói “khoan, chờ đến khi người dùng vuốt để chấp thuận đã”

  • Tôi không rõ Gruber đã nói ở đâu rằng “chỉ Apple Pay mới làm được điều này”. Có vẻ tác giả đang chỉ ra một vài chỗ Gruber sai hoặc không nắm chính xác chi tiết, rồi làm như đó là toàn bộ vấn đề

    • https://daringfireball.net/linked/2024/03/21/garland-monopol...
      [Cập nhật: Chết thật, tôi đã sai. Matt Birchler, người làm trong ngành thanh toán, đã giải thích rất rõ cách nó hoạt động, và hóa ra các ngân hàng lớn cùng hãng thẻ tín dụng tạo ra số “DPAN” theo từng nhà bán hàng cho các giao dịch tap-to-pay. Dù vậy, tôi vẫn giữ quan điểm rằng Apple Wallet ít nhất cũng an toàn ngang, hoặc an toàn hơn, bất kỳ ứng dụng thanh toán số nào do đơn vị phát hành thẻ cung cấp.]
      Đây là bài viết của Gruber, tác giả gốc
    • Về đoạn “ngay cả khi ngân hàng hay đơn vị phát hành thẻ tín dụng có quyền truy cập NFC tap-to-pay thì khả năng họ tự làm việc này là rất thấp”, Birchler đã chỉ ra rằng các ngân hàng thực sự đã làm như vậy
      Gruber cũng đã thừa nhận sai lầm của mình
      Gruber là một fan công khai của Apple, nhưng nhìn chung ông ấy thường giữ đúng sự thật, thừa nhận những gì mình không biết và dẫn link tới chuyên gia trong lĩnh vực liên quan
      Nhưng kể từ các động thái của Apple liên quan đến EU DMA, ông ấy có vẻ đã hoàn toàn mất tính khách quan. Kiểu như giả vờ hiểu ngôn ngữ pháp lý còn hơn cả EC, áp dụng cách tiếp cận kiểu Mỹ vào một mô hình lập pháp châu Âu rất khác, và chấp nhận nguyên xi các phát ngôn thiếu thiện chí của Apple
      Sự thay đổi này đi kèm với thái độ thù địch kỳ lạ của Apple đối với EU, nên có thể vấn đề gốc rễ là Gruber tin Apple quá nhiều
      Có vẻ ông ấy cũng giữ nguyên thái độ đó với vụ kiện chống độc quyền của chính phủ Mỹ
      Công bằng mà nói, trên mạng xã hội có đầy những người ủng hộ Apple giả làm chuyên gia pháp lý và nói sai gần như mọi thứ, nên có thể ông ấy khó nhìn thấy các quan điểm phản đối có cơ sở pháp lý
    • Có khác biệt rất lớn giữa “Apple Pay làm điều này” và “chỉ Apple Pay làm điều này”. Có vẻ Gruber muốn nói theo nghĩa đầu, nhưng tác giả lại bằng cách nào đó đọc thành nghĩa sau

  • Về đoạn “Apple đã làm rất tốt trong việc phổ biến các ví điện tử như vậy, nhưng những gì họ làm không phải là thứ độc nhất trong ngành”, có thể tôi nhớ nhầm nhưng tôi nghĩ khi Apple Pay mới ra mắt thì nó khá độc đáo. Vì thế mà số nơi hỗ trợ rất ít
    Các hệ thống thanh toán điện thoại khác, ví dụ như Samsung Pay thời kỳ đầu, hình như đã gửi nguyên số thẻ tới thiết bị đầu cuối

    • Ở Mỹ thì điều đó khá hiếm. Ở châu Âu và châu Á, thanh toán không tiếp xúc đã được hỗ trợ từ trước khá lâu, và ở Anh thì đã có từ năm 2007. Tuy vậy, ít nhất trong giai đoạn đầu ở Anh, hạn mức khá thấp
      Điều thú vị là ở Anh dường như vẫn còn giới hạn £100, trong khi ở Mỹ tôi đã từng thanh toán hơn $2000 bằng hình thức không tiếp xúc trên điện thoại Android
    • Khi đó cũng có một hai cách khác, nhưng chúng có vẻ gần giống tự động điền bị thổi phồng hơn. Một số phiên bản của Google Pay là điền thông tin vào website, và theo tôi nhớ thì ở hậu trường nó bằng cách nào đó chuyển số thẻ thực
      Có thể nó chỉ gửi trực tiếp cho ngân hàng để nhà bán hàng không nhìn thấy, nhưng dù vậy đó vẫn là số thật. Lần đầu tôi nghe nói đến việc dùng DPAN là từ Apple
    • Chuẩn không tiếp xúc của EMVCo ngay từ đầu đã là số thẻ được token hóa. Samsung Pay có thể đã chuyển PAN trong thanh toán trực tuyến
    • Tôi cho rằng Apple Pay gần như là triển khai lớn cuối cùng gia nhập thị trường. Triển khai đầu tiên dựa trên chuẩn EMV ban đầu là Google Wallet, nhưng đã bị chặn lại bởi kiểu thất bại ra mắt toàn cầu rất đặc trưng của Google
      Mỹ đang tụt hậu rất xa về công nghệ thanh toán bằng thẻ vì nhiều lý do. Khi tôi đến Ba Lan với chiếc thẻ đã được dùng suốt nhiều năm ở khắp nơi trên thế giới, tôi thậm chí còn phải học các cách lách đặc biệt để nhân viên thu ngân có thể xử lý thanh toán