Kesalahpahaman tentang cara kerja Apple Pay

• Struktur yang menyembunyikan nomor kartu asli bukan fitur khusus Apple Pay, melainkan metode pembayaran yang juga digunakan di dompet digital utama seperti Google Pay dan Samsung Pay
• Intinya adalah pemisahan antara FPAN, yaitu nomor kartu fisik, dan DPAN, yaitu nomor pembayaran per perangkat; bahkan untuk kartu yang sama, iPhone dan iPad akan menggunakan DPAN yang berbeda
• DPAN dapat mempersulit pelacakan lintas merchant, tetapi dalam merchant yang sama DPAN tetap dipertahankan untuk transaksi lanjutan, sehingga pelacakan riwayat pembelian oleh satu merchant tidak terhalang
• Saat terjadi kebocoran informasi pembayaran, DPAN lebih aman daripada FPAN, dan DPAN hanya berfungsi jika dikirim bersama bundel kriptografi unik yang melekat pada tiap transaksi
• Apple Pay tidak otomatis menyembunyikan informasi pribadi seperti nama, email, alamat penagihan/pengiriman, atau barang yang dibeli; informasi yang ditampilkan di layar pembayaran pada dasarnya harus dianggap diteruskan ke merchant

---

DPAN bukan fitur eksklusif Apple Pay

• Saat dikatakan bahwa Apple Pay menyembunyikan nomor kartu kredit asli, inti utamanya adalah DPAN
• FPAN adalah funding primary account number 15–18 digit yang tercetak pada kartu fisik, sedangkan DPAN adalah device primary account number
• DPAN dapat dipahami mirip seperti catatan DNS
  • Pengguna dapat mengakses situs web dengan nama domain tanpa mengetahui alamat IP sebenarnya
  • Bahkan untuk kartu yang sama, jika Apple Pay digunakan di iPhone dan iPad, masing-masing perangkat menerima nomor unik sehingga memakai DPAN yang berbeda
• Penting bahwa dari namanya saja ini bukan “Apple Pay number”
  • Google Pay dan Samsung Pay juga menyembunyikan nomor kartu asli dengan cara yang sama sebagai dompet digital utama di AS
  • Tombol Amazon Pay dan Shop Pay juga memproses pembayaran melalui perusahaan lain, jadi secara teknis bukan DPAN, tetapi tetap membuat merchant tidak melihat FPAN yang sebenarnya

Merchant dan bank juga ingin mengurangi paparan nomor kartu asli

• Jika merchant memproses nomor kartu kredit asli secara langsung, beban risikonya menjadi lebih besar
• Alat penerimaan pembayaran modern dibuat agar informasi pembayaran dikumpulkan dengan cara yang meminimalkan orang yang dapat mengakses data kartu asli
• Dugaan bahwa bank tidak akan menggunakan DPAN tidak sesuai dengan kasus nyata
  • Banyak bank seperti Wells Fargo, Chase, dan Bank of America menjalankan atau pernah menjalankan dompet digital mereka sendiri, dan semuanya melindungi nomor akun biasa dengan DPAN
  • Paze, yang digunakan oleh bank-bank besar di AS, juga memakai DPAN
  • Salah satu alasan utama yang diangkat Paze adalah “Paze does not share your actual card number with the merchant.”

Pelacakan yang dicegah DPAN dan yang tidak dicegah

• Pernyataan bahwa DPAN berubah pada setiap transaksi tidak tepat
• Untuk transaksi lanjutan pada merchant yang sama, DPAN yang sama akan digunakan
• Struktur ini dapat menjadi penghalang bagi data broker yang membeli data transaksi dari banyak merchant untuk memahami kebiasaan belanja seseorang
• Sebaliknya, satu merchant tetap bisa melihat riwayat transaksi pelanggan tersebut hanya dengan DPAN yang diberikan Apple Pay
  • Situasi seperti kasus Target yang menyimpulkan kondisi pelanggan berdasarkan riwayat pembelian internalnya tidak dicegah oleh Apple Pay
  • Dompet digital lain juga memiliki keterbatasan yang sama

Perlindungan yang diberikan DPAN saat terjadi kebocoran data

• Dalam situasi kebocoran informasi kartu pembayaran, DPAN lebih aman daripada FPAN
• Pada 2024, seharusnya merchant tidak lagi menangani nomor kartu kredit secara langsung, tetapi masih mungkin terjadi kasus gateway pembayaran diretas sehingga DPAN dan tanggal kedaluwarsa bocor
• Penyerang tidak dapat melakukan pembayaran hanya dengan DPAN yang bocor
  • DPAN hanya berfungsi jika dikirim sebagai bagian dari bundel kriptografi unik untuk setiap transaksi
  • Memang ada cara untuk menjalankan penagihan berulang pada kartu yang dikumpulkan lewat Apple Pay, tetapi peretas tidak semestinya dapat melakukan itu
• Karena itu, dibanding kebocoran DPAN yang dikumpulkan semua dompet digital, kebocoran FPAN jauh lebih berbahaya

Apple Pay tidak otomatis menyembunyikan informasi pribadi

• Anggapan bahwa Apple Pay otomatis menyamarkan informasi pribadi tidak sesuai fakta
• Jika menjalankan transaksi Apple Pay nyata pada akun merchant uji, laporan tingkat merchant akan menampilkan informasi seperti nama, email, alamat penagihan, dan alamat rumah
• Untuk pembayaran barang fisik, informasi pengiriman diperlukan, sehingga Apple Pay SDK memungkinkan merchant memilih informasi pribadi apa yang ingin diminta dari pelanggan
• Informasi produk juga diteruskan ke Apple Pay sehingga dapat menampilkan apa yang dibeli pengguna, dan informasi ini juga diteruskan ke merchant
• Informasi yang ditampilkan pada kartu Apple Pay saat pembayaran pada dasarnya harus dianggap diteruskan ke merchant
  • Dalam hal ini Apple Pay sama dengan metode pembayaran lain
  • Merchant memilih dan meminta informasi pribadi yang diperlukan atau diinginkan saat checkout
  • Dompet digital lain juga bekerja dengan cara yang sama

Perlindungan yang benar-benar diberikan dompet digital

• Apple Pay adalah metode pembayaran yang baik, dan Apple berperan dalam memopulerkan bentuk dompet digital seperti ini
• Namun, fungsi Apple Pay tidak unik di industri
• DPAN berguna untuk mempersulit pelacakan pembelian seseorang di banyak merchant dan untuk mengurangi risiko pelanggan saat data kartu pembayaran bocor

[GN⁺]

Komentar Hacker News

• Saya ingin penjelasan ELI5 tentang bagaimana Apple Pay dan Google Pay sebenarnya bekerja. Dulu saya mengira informasi kartu begitu saja diteruskan ke merchant atau payment processor, dan tulisan aslinya juga tampak mirip seperti itu, tetapi saat memakai Amex di Google Pay, saya juga pernah melihat sebagian merchant menolak pembayaran, berbeda dengan saat memakai MasterCard
  Kadang rasanya Apple/Google bertindak seperti payment processor atau metode pembayaran itu sendiri. Soalnya mereka mengumpulkan data transaksi, dan terminal di supermarket juga tampaknya membutuhkan dukungan khusus untuk aplikasi Apple/Google Pay
  Kalau begitu, saya penasaran apa rahasia eksklusif Apple/Google, dan mengapa sulit atau mustahil digantikan dengan alternatif open source. Apakah karena hanya Apple/Google yang punya akses penuh ke chip NFC di iOS/Android?
  https://news.ycombinator.com/item?id=39845805

  • Tidak ada rahasia khusus milik Apple/Google. Banyak bank di seluruh dunia menyediakan dompet HCE mereka sendiri, tetapi hanya berjalan di Android. Apple tidak menyediakan API yang diperlukan, dan di UE hal ini sekarang mulai berubah
    Yang penting adalah default. Hanya bisa ada satu dompet Visa, Mastercard default per perangkat, dan pihak yang tidak perlu membuka aplikasi terpisah sebelum tap punya keunggulan. Google Pay mendukung kartu dari banyak bank, jadi punya keunggulan besar dibanding dompet HCE milik bank penerbit tertentu
    Apple/Google terlibat sebagai perantara saat kartu baru didaftarkan ke perangkat tertentu, tetapi tidak masuk ke alur transaksi POS yang sebenarnya
    Merchant tetap harus menerima merek kartu dasarnya. Google Pay dan Apple Pay modern bukan kartu proksi yang mengubah merek kartu, dan berbeda dari layanan seperti Curve
    Terminal offline tidak memerlukan dukungan terpisah. Selama terminalnya tidak bermasalah, pembayaran akan berjalan di tempat yang menerima skema kartu dasarnya. Protokol fisik dan logisnya sama dengan kartu plastik, dan dari sisi terminal hampir tidak bisa dibedakan
    Di web, situasinya berbeda. Situs web toko online dan penyedia layanan pembayaran harus mendukungnya secara eksplisit
  • Apple/Google Pay menggunakan EMV nirsentuh, cara yang sama seperti kartu kredit nirsentuh. Ini adalah standar di balik Paywave dan Paypass milik Visa/MC
    Karena itu, terminal nirkabel pada umumnya langsung menerima Apple Pay dan Google Pay, dan tidak membutuhkan banyak dukungan khusus. Salah satu perubahan yang saya ingat adalah perangkat seperti ini dianggap lebih aman sehingga limit pembayaran dinaikkan dibanding kartu nirsentuh
    Alasan implementasi open source sulit adalah karena implementasi EMV itu kompleks, dan membutuhkan banyak pengujian serta verifikasi dengan peralatan khusus. Perangkat memerlukan secure enclave untuk menyimpan kunci privat dengan aman, dan aplikasi harus dapat memastikan bahwa autentikasi biometrik atau pembukaan kunci dengan PIN telah digunakan untuk menjamin keamanan pengguna
    Selain itu, dalam proses penyiapan, sistem harus terintegrasi dengan backend bank penerbit kartu untuk menerbitkan kunci dan informasi yang diperlukan. Implementasi open source pun besar kemungkinan harus membuat kontrak dengan bank dan menjalani verifikasi laboratorium melalui pihak seperti UL
  • Satu-satunya “rahasia” adalah peralihan tanggung jawab. Pembayaran online dan nirsentuh tradisional diklasifikasikan sebagai transaksi “pemegang kartu tidak hadir”, sehingga tanggung jawab penipuan lebih banyak jatuh ke merchant
    Apple Pay, Google Pay, dan aplikasi pembayaran yang disediakan bank mengonfirmasi persetujuan pemegang kartu lewat autentikasi biometrik, sehingga sebagian pembayaran berubah menjadi “pemegang kartu hadir”
    Karena itu, beberapa jenis chargeback langsung ditolak, dan untuk jenis lain pun kebutuhan bukti dari merchant menjadi lebih ringan
    Ini adalah bagian dari standar jaringan kartu, dan jika tertarik bisa dilihat di https://www.emvco.com/
    Alasan tidak ada opsi open source adalah karena keamanan implementasinya harus disertifikasi, sehingga diperlukan entitas komersial untuk bekerja dengan bank. Selain itu, tiap bank harus diintegrasikan secara terpisah, jadi ada terlalu banyak bank yang harus ditangani
  • Kasus Amex ditolak di Google Pay sementara MasterCard diterima biasanya terjadi karena masalah konfigurasi dari penyedia terminal kartu, atau karena backend acquirer yang berkomunikasi dengan skema kartu kurang memiliki sertifikasi fungsi dompet seluler
    Membuat transaksi end-to-end berjalan dengan benar di semua skema kartu, semua metode pembayaran, dan semua perangkat itu cukup rumit. Tiap skema kartu memiliki parameter “kernel pembayaran” dan persyaratan sertifikasi yang berbeda
    Atau bisa juga itu upaya menghemat biaya transaksi. Amex umumnya jauh lebih mahal bagi merchant
  • Ada informasi bagus di sini
    https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...

• Saat Apple Pay mulai digunakan secara luas untuk pertama kalinya, saya menelaahnya cukup mendalam berdasarkan pengalaman memproses pembayaran ritel. Yang paling berkesan saat itu adalah betapa dalamnya ia berakar pada standar industri
  Tidak ada bagian setelah komunikasi nirkabel yang khusus milik Apple, dan kalau membaca tulisan ini, tampaknya hal itu masih tetap berlaku sampai sekarang
  Saya ingat saat itu sebagian merchant yang sengaja menerima tap-to-pay berbasis kartu harus mengubah sistem mereka ketika ternyata mereka tanpa sengaja juga menerima tap-to-pay Apple yang sangat standar. CVS khususnya terlintas di pikiran; sepertinya mereka ikut dalam skema pembayaran pesaing dan ingin menjadikan fakta bahwa skema itu bisa dipakai di toko sebagai pembeda dari Apple Pay
  Ketika belakangan mulai muncul mitos bahwa “ini hanya bisa dilakukan Apple Pay”, saya sempat bertanya-tanya apakah ada sesuatu yang berubah sejak terakhir kali saya melihatnya, jadi saya senang penulis melakukan tinjauan terbaru dalam konteks ini

  • Sebagai anekdot pribadi, ketika Apple Pay pertama kali diluncurkan, ia hanya berfungsi di AS. Lebih tepatnya, hanya bisa diatur di AS. Tak lama setelah itu saya pindah ke Australia, tempat tap-to-pay sudah menjadi standar
    Meski tidak didukung secara resmi, saya cukup terkejut karena Apple Pay berfungsi di mana-mana di Australia. Di AS hanya segelintir merchant yang mendukungnya, tetapi karena Australia berbasis standar, praktis 99% POS sudah mendukungnya
  • Meski berbasis standar, cara peluncuran dan pemasaran Apple cukup cerdik, sehingga memberi kesan bahwa Apple Pay adalah satu-satunya tap-to-pay lewat ponsel. Merchant memasang papan “Apple Pay accepted” dan tidak menyebut Google, sehingga muncul kebingungan apakah pembayaran non-Apple bisa digunakan
    Kondisi pembayaran Android yang membingungkan juga ikut berperan. Samsung Pay bisa berarti NFC, bisa juga berarti emulasi magnetic stripe. Google terkenal buruk dalam branding, dan di antara berbagai iterasi Wallet dan Google Pay, sampai sekarang pun masih sulit memahami mana yang mana
  • Yang paling lucu adalah orang-orang lupa bahwa Apple Pay sebenarnya tergolong terlambat masuk ke pasar pembayaran seluler. Pada dasarnya hampir yang terakhir

• Hal yang terlewat dalam diskusi seperti ini adalah bahwa transaksi dari dompet seperti Apple Pay, Google Pay, dan Samsung Pay kini juga dapat dilacak sama seperti transaksi dengan nomor kartu dasarnya
  DPAN memang unik untuk perangkat tertentu, tetapi sekarang penyedia layanan pembayaran merchant dapat menerima pengenal unik bernama PAR dari respons otorisasi jaringan kartu. Pengenal ini sama di semua DPAN untuk kartu yang sama, dan arahnya adalah tetap berlaku meski nomor kartu berubah selama akun dasarnya sama
  Merchant tidak dapat menagih pembayaran dengan PAR, jadi ini bukan masalah keamanan, tetapi jangan berharap pembayaran dompet digital lebih privat daripada pembayaran dengan kartu biasa atau nomor kartu
  https://wcapra.com/payment-account-reference-capraplus-your-...
  https://www.securetechalliance.org/wp-content/uploads/EMVCo-...

  • Tanpa tindakan pemerintah, saya tidak berharap apa pun akan menjadi lebih privat ke depannya
  • Jepang tidak begitu. Apple Pay menggunakan kartu ICOCA/Suica anonim, dan jika mau, Anda bisa menghapusnya lalu membuatnya lagi
  • Bank lokal saya di Australia, NAB, mempertahankan ini meski nomor kartu berubah untuk akun dasar yang sama. Saya rasa ini cukup umum pada sebagian besar kartu kredit di sini

• Di tulisan Matt Birchler ditambahkan paragraf yang berbunyi, “Dalam versi sebelumnya saya mengatakan DPAN berubah untuk tiap merchant, tetapi itu keliru. Salah saya karena menulis terlalu terburu-buru.” Namun bagian lain tulisannya masih tampak seolah-olah ada DPAN unik per merchant, dan saya tidak bisa menemukan dasarnya
  Dokumentasi Apple sendiri https://support.apple.com/en-us/HT203027 juga menyatakan bahwa DPAN, yang di sini disebut Device Account Number, hanya unik per perangkat. Ketika kartu ditambahkan ke Apple Pay, DPAN untuk perangkat itu dibuat, dan tidak berubah setelahnya kecuali kartu dihapus lalu ditambahkan kembali
  Jadi jika kartu yang sama dipakai di dua perangkat, iPhone dan Apple Watch, DPAN-nya berbeda sehingga lebih sulit dilacak, tetapi jika kartu yang sama dipakai di perangkat yang sama di berbagai merchant, menurut saya broker data bisa melacaknya

  • Di industri pembayaran, DPAN umumnya tidak dianggap sebagai pengenal yang stabil. Ia dapat diganti secara berkala, terlepas dari apakah kartu ditambahkan atau dihapus
  • Jika bank menjual data kartu kredit, fakta bahwa PAN-nya berbeda tidak banyak mengubah keadaan
  • Saya pernah melihat empat digit terakhir kartu berubah setiap kali membayar dengan Apple Pay. Saya terutama memakai Apple Watch, dan itu berbeda bukan hanya antar-merchant, tetapi juga di merchant yang sama

• Saya tidak mengerti mengapa SSO dan pembayaran mobile bukan antarmuka standar yang memungkinkan siapa pun membuat penyedia. Bukankah seharusnya ada “masuk dengan penyedia SSO default saya” alih-alih “Login with Google” atau “Login with Apple”? Begitu juga dengan “bayar dengan penyedia pembayaran default saya”
  Lebih buruk lagi, penyedia atau situs sering kali hanya mendukung sebagian dari penyedia ini, sehingga SSO pada praktiknya tidak benar-benar SSO
  Pasti ada alasannya, tetapi saya belum menggali lebih dalam. Rasanya perlu ada spesifikasi bersama yang diikuti semua penyedia, dan jika belum ada, besar kemungkinan suatu saat akan dipaksakan lewat hukum

  • Yang dicari di SSO lebih dekat ke RFC 7591[0]. Dokumen itu menjelaskan cara mendaftar secara instan ke OAuth IdP. RFC 8414[1] menjelaskan lokasi well-known untuk mengambil metadata proses pendaftaran
    Standarnya sudah ada, dan secara teori jika pengguna memasukkan email di formulir login atau browser melakukan autofill, itu bisa mengarah ke login OAuth domain tersebut; jika server baru pertama kali berkomunikasi dengan domain itu, bahkan pendaftaran klien bisa dilakukan secara instan. Saya belum pernah melihat ini benar-benar dipakai, tetapi akan bagus jika ada
    [0] https://datatracker.ietf.org/doc/html/rfc7591
    [1] https://datatracker.ietf.org/doc/html/rfc8414
  • Alasannya adalah “pertumbuhan dan engagement”. Sejak sekitar 2010, teknologi berubah dari alat untuk memberdayakan pengguna menjadi alat yang membuang waktu pengguna dengan spam
    Arahannya bergeser dari menyediakan layanan dan mengenakan biaya yang adil, menjadi mengirim spam kepada pengguna atau mengumpulkan data untuk mengirim lebih banyak spam di kemudian hari
    Standar terbuka bukanlah sesuatu yang diinginkan penyedia saat ini. Karena itu akan membuat pengguna mudah pindah ke alternatif lain dan tidak lagi “engage”
  • Karena metode verifikasi pengguna sangat berbeda antaroperator, masing-masing operator harus meninjau dan memercayai apakah penyedia SSO mematuhi standar yang mereka minta. Jika ada sejuta penyedia SSO, sulit mengetahui standar apa yang dipatuhi masing-masing
  • Untuk mendukung “Login with Google”, perlu ada konfigurasi di pihak Google. Mereka harus diberi tahu aplikasi ini apa, dan setelah autentikasi harus redirect ke URL mana, dan sebagainya. Jika tidak, akan muncul masalah keamanan
  • Karena itu menyakitkan dan menjadi magnet masuknya penipuan. Ketika Stack Overflow mendorong penggunaan OpenID di mana-mana, masalah pun muncul

• Menariknya, Apple Pay diluncurkan setelah bank-bank besar lokal Australia selama bertahun-tahun mendorong peningkatan penggunaan pembayaran nirsentuh. Jadi ketika Apple masuk dan meminta biaya ala AS, infrastrukturnya sudah dipasang langsung oleh bank-bank tersebut
  Bank-bank besar Australia bertahan selama bertahun-tahun untuk tidak mendukung Apple Pay, tetapi akhirnya mengalah karena tekanan pelanggan terlalu besar
  Sampai sekarang mereka semua masih sangat tidak senang soal ini, dan jika regulator memaksa pembukaan chip NFC, mereka akan segera meninggalkan Apple Pay. Namun sejauh ini sulit menemukan orang yang bersimpati pada keluhan bank-bank terbesar di negara itu

  • Menariknya, bank-bank Australia meminta izin kepada ACCC untuk membentuk kartel agar dapat bernegosiasi bersama dengan Apple dan memboikot Apple Pay terkait syarat-syaratnya, tetapi ditolak
    https://www.accc.gov.au/media-release/accc-denies-authorisat...
  • Sulit bagi bank untuk meninggalkan Apple Pay kecuali pengguna tinggal diam
    Bank-bank Kanada juga pernah mencoba pembayaran nirsentuh mereka sendiri di Android, seperti TD Pay, tetapi tidak ada yang menginginkannya. Akhirnya mereka menyerah dan menyediakan Google Pay
    Saya kira alurnya akan mirip. Bahkan jika Apple membuka pembayaran NFC, tidak ada yang akan memakai aplikasi bank dan akan lebih memilih dukungan pihak pertama seperti Apple Pay atau Google Pay
    Cukup lihat saja berapa banyak orang yang benar-benar memakai Samsung Pay dibanding Google Pay
  • Apple juga bukan yang membangun infrastruktur pembayaran nirsentuh di AS. Antarmuka nirsentuh sudah ada, sudah punya logo sendiri, dan bisa dipakai dengan kartu tap
    Beberapa peritel seperti CVS mematikan pembayaran tap ketika Apple Pay diperkenalkan
  • https://www.apple.com/newsroom/2024/01/apple-announces-chang...
  • Saya ingat sebelum Apple Pay, bank seperti NAB menyediakan stiker NFC yang ditempel di belakang ponsel, seolah-olah berkata “lihat, ini sama bagusnya dengan Apple Pay”

• Saya penasaran apakah bagian “merchant dapat meminta informasi pribadi sebanyak yang diperlukan saat checkout, dan Apple Pay tidak mencegahnya” juga terjadi saat belanja offline
  Untuk membeli telur di supermarket, nama dan alamat saya tidak diperlukan. Apakah Apple/Google pasti meminta persetujuan saya saat membagikan informasi yang sebenarnya tidak diperlukan? Apakah ini model terima atau tinggalkan seperti syarat layanan atau shrink-wrap EULA?
  Saya belum pernah memakai sistem pembayaran seperti ini

  • Dalam pembayaran POS, biasanya hanya DPAN, yaitu nomor akun perangkat, yang dibagikan kepada merchant. Nama pun umumnya disamarkan; ini mirip kartu nirsentuh dan berbeda dari pembayaran chip/magnetic stripe
    Informasi tambahan yang disebutkan dalam tulisan hanya dibagikan pada pembayaran “online”. Namun ini juga mencakup kasus memindai kode QR dengan ponsel lalu membayar di Safari atau App Clip, cara yang belakangan saya lihat di beberapa restoran
    Dengan begitu, restoran menerima sebanyak informasi yang mereka minta. Bisa mencakup nama, alamat, hingga alamat email. Biasanya tampaknya ditampilkan di payment sheet, tetapi saat pertama kali memakainya di restoran, saya tidak terlalu menyadarinya
    Sekarang saya meminta pelayan membawakan terminal fisik agar saya bisa tap, atau saya berikan saja kartu fisik

• Agak keluar topik, tetapi saya masih belum paham mengapa Apple Pay tidak bisa menampilkan jumlah yang akan dibayar saat ini di layar sebelum transaksi disetujui
  Sepertinya ini bukan masalah pengalaman pengguna, melainkan perangkat Apple memang sama sekali tidak mengetahui jumlah tersebut. Kenapa bisa begitu?

  • Anggap saja ponsel itu seperti kartu plastik biasa. Ponsel menunggu permintaan dari NFC reader, lalu ketika permintaan datang, ia mengirim “nomor kartu” dan selesai
    Butuh waktu bagi saya untuk memahami ini. Saya dulu tidak mengerti bagaimana Apple Pay bisa bekerja dalam mode pesawat, tetapi tentu saja memang bisa. Karena kartu Visa biasa pun berfungsi baik tanpa koneksi internet
    Pada dasarnya keduanya sama. Itu juga alasan mengapa, jika semua pihak berjalan sesuai standar, tidak ada lagi yang perlu “didukung” secara khusus. Lihat komentar saudara dari jjcm: https://news.ycombinator.com/item?id=39846117
    Jadi menurut saya NFC reader tidak “menyiarkan” jumlah pembayaran. Kartu plastik tidak punya cara untuk memproses informasi itu, dan iPhone juga tidak punya cara untuk menerima informasi itu lalu berkata, “tunggu dulu, tunggu sampai pengguna menyetujui dengan swipe”

• Saya tidak tahu di mana Gruber mengatakan “hanya Apple Pay yang melakukan ini”. Penulis tampaknya menunjukkan beberapa kesalahan Gruber atau bagian yang detailnya tidak ia tangkap dengan tepat, dan sepertinya hanya itu

  • https://daringfireball.net/linked/2024/03/21/garland-monopol...
    [Pembaruan: Aduh, saya keliru. Matt Birchler, yang bekerja di industri pembayaran, menjelaskan dengan baik cara kerjanya, dan ternyata bank-bank besar serta perusahaan kartu kredit membuat nomor “DPAN” per merchant untuk transaksi tap-to-pay. Meski begitu, saya tetap berpendapat bahwa Apple Wallet setidaknya setara atau lebih aman dibanding aplikasi pembayaran digital apa pun yang disediakan penerbit kartu.]
    Itu adalah tulisan Gruber, penulis aslinya
  • Mengenai bagian “sangat kecil kemungkinannya bank atau penerbit kartu kredit akan melakukan sendiri hal seperti ini meskipun mereka mendapat akses NFC tap-to-pay”, Birchler menunjukkan bahwa bank-bank memang benar-benar melakukannya
    Gruber juga mengakui kesalahannya
    Gruber memang penggemar Apple secara terbuka, tetapi biasanya ia cukup tepat soal fakta, mengakui bagian yang tidak ia ketahui, dan menautkan pakar di bidang terkait
    Namun setelah langkah Apple terkait DMA Uni Eropa, ia tampak benar-benar kehilangan objektivitas. Ia bersikap seolah lebih memahami bunyi hukum dibanding EC, menerapkan pendekatan ala AS pada cara legislasi Eropa yang sangat berbeda, dan menerima begitu saja pernyataan Apple yang berniat buruk
    Perubahan ini selaras dengan sikap Apple yang anehnya penuh permusuhan terhadap Uni Eropa, jadi akar masalahnya mungkin Gruber terlalu mempercayai Apple
    Tampaknya ia juga melanjutkan sikap itu terhadap gugatan antimonopoli pemerintah AS
    Agar adil, media sosial penuh dengan pendukung Apple yang berpura-pura menjadi pakar hukum dan salah hampir dalam semua hal, sehingga mungkin sulit baginya melihat sudut pandang tandingan yang sah
  • Ada perbedaan besar antara “Apple Pay melakukan ini” dan “hanya Apple Pay yang melakukan ini”. Sepertinya Gruber mengatakan yang pertama, tetapi entah bagaimana penulis membacanya sebagai yang kedua

• Mengenai bagian “Apple memang melakukan pekerjaan hebat dalam memopulerkan dompet digital seperti ini, tetapi apa yang mereka lakukan bukanlah sesuatu yang unik di industri”, ingatan saya mungkin keliru, tetapi menurut saya ketika Apple Pay pertama kali muncul, itu cukup unik. Karena itu, tempat yang mendukungnya sangat sedikit
  Sistem pembayaran ponsel lain, misalnya Samsung Pay awal, seingat saya mengirim nomor kartu apa adanya ke terminal

  • Di AS itu jarang. Di Eropa dan Asia, pembayaran nirsentuh sudah didukung selama beberapa waktu, dan di Inggris sudah bisa sejak 2007. Namun setidaknya pada awalnya, batasnya cukup rendah di Inggris
    Menariknya, Inggris sepertinya masih punya batas £100, sementara di AS saya pernah membayar lebih dari $2000 dengan pembayaran nirsentuh dari ponsel Android
  • Saat itu juga ada satu atau dua cara lain, tetapi sepertinya lebih mirip autofill yang dilebih-lebihkan. Saya ingat suatu versi Google Pay mengisi informasi di situs web, lalu entah bagaimana meneruskan nomor kartu asli di latar belakang
    Mungkin nomor itu hanya dikirim langsung ke bank sehingga merchant tidak melihatnya, tetapi tetap saja itu nomor asli. Pertama kali saya mendengar penggunaan DPAN adalah dari Apple
  • Spesifikasi nirsentuh EMVCo sejak awal selalu menggunakan nomor kartu yang ditokenisasi. Samsung Pay mungkin saja meneruskan PAN dalam pembayaran online
  • Menurut saya Apple Pay termasuk implementasi besar terakhir yang masuk ke pasar. Implementasi pertama berbasis standar EMV awalnya adalah Google Wallet, yang terhambat oleh kegagalan khas Google dalam peluncuran global
    AS sangat tertinggal dalam teknologi pembayaran kartu karena berbagai alasan. Ketika saya berkunjung ke Polandia dengan kartu yang sudah dipakai bertahun-tahun di seluruh dunia, sampai-sampai kasir harus lebih dulu mempelajari cara pintas khusus agar pembayaran bisa dilakukan