1 คะแนน โดย GN⁺ 2024-03-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โครงสร้างที่ซ่อนหมายเลขบัตรจริงนั้น ไม่ใช่ฟีเจอร์เฉพาะของ Apple Pay แต่เป็นรูปแบบการชำระเงินที่ใช้ในกระเป๋าเงินดิจิทัลหลักอย่าง Google Pay และ Samsung Pay เช่นกัน
  • แก่นสำคัญคือการแยกระหว่าง FPAN ซึ่งเป็นหมายเลขบัตรจริง กับ DPAN ซึ่งเป็นหมายเลขชำระเงินเฉพาะอุปกรณ์ โดยแม้จะเป็นบัตรใบเดียวกัน บน iPhone และ iPad ก็จะใช้ DPAN คนละหมายเลข
  • DPAN อาจทำให้การติดตามข้ามร้านค้าทำได้ยากขึ้น แต่ภายในร้านค้าเดียวกันจะยังคงเดิมในการทำธุรกรรมครั้งถัดไป จึง ไม่ได้ป้องกันการติดตามประวัติการซื้อภายในร้านค้าเดียว
  • เมื่อเกิดข้อมูลการชำระเงินรั่วไหล DPAN ปลอดภัยกว่า FPAN และ DPAN จะใช้งานได้ก็ต่อเมื่อถูกส่งไปพร้อมกับ ชุดเข้ารหัสเฉพาะของแต่ละธุรกรรม
  • Apple Pay ไม่ได้ซ่อนข้อมูลส่วนตัว เช่น ชื่อ อีเมล ที่อยู่เรียกเก็บเงิน·ที่อยู่จัดส่ง หรือสินค้าที่ซื้อโดยอัตโนมัติ และควรมองว่าข้อมูลที่แสดงบนหน้าชำระเงินจะถูกส่งต่อให้ร้านค้า

DPAN ไม่ใช่ฟีเจอร์เฉพาะของ Apple Pay

  • เวลาพูดว่า Apple Pay ซ่อนหมายเลขบัตรเครดิตจริง หัวใจสำคัญคือ DPAN
  • FPAN คือ funding primary account number ความยาว 15~18 หลักที่พิมพ์อยู่บนบัตรจริง ส่วน DPAN คือ device primary account number
  • DPAN สามารถทำความเข้าใจได้คล้ายกับ DNS record
    • ผู้ใช้เข้าถึงเว็บไซต์ผ่านชื่อโดเมนได้โดยไม่ต้องรู้ IP address จริง
    • แม้จะเป็นบัตรใบเดียวกัน แต่ถ้าใช้ Apple Pay บน iPhone และ iPad แต่ละอุปกรณ์จะได้รับหมายเลขเฉพาะของตนเอง จึงใช้ DPAN ต่างกัน
  • สิ่งสำคัญคือแม้แต่ชื่อก็ไม่ได้เรียกว่า “Apple Pay number”
    • Google Pay และ Samsung Pay ก็เป็นกระเป๋าเงินดิจิทัลหลักในสหรัฐฯ ที่ซ่อนหมายเลขบัตรจริงด้วยวิธีเดียวกัน
    • ปุ่ม Amazon Pay และ Shop Pay ก็ทำให้ร้านค้ามองไม่เห็น FPAN จริงเช่นกัน เพราะการชำระเงินถูกประมวลผลผ่านอีกบริษัทหนึ่ง แม้ในทางเทคนิคจะไม่ใช่ DPAN ก็ตาม

ร้านค้าและธนาคารก็ต้องการลดการเปิดเผยหมายเลขบัตรจริง

  • หากร้านค้าต้องจัดการหมายเลขบัตรเครดิตจริงโดยตรง ภาระความเสี่ยง จะสูงขึ้น
  • เครื่องมือรับชำระเงินสมัยใหม่ถูกออกแบบให้เก็บข้อมูลการชำระเงินในแบบที่ลดจำนวนผู้ที่เข้าถึงข้อมูลบัตรจริงให้เหลือน้อยที่สุด
  • การคาดเดาว่าธนาคารจะไม่ใช้ 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 เดิม
  • โครงสร้างนี้อาจเป็นอุปสรรคต่อ data broker ที่พยายามซื้อข้อมูลธุรกรรมจากหลายร้านค้าเพื่อนำไปวิเคราะห์แนวโน้มการจับจ่ายของคนคนหนึ่ง
  • ในทางกลับกัน ร้านค้าเดียวสามารถดูประวัติธุรกรรมของลูกค้ารายนั้นได้จาก DPAN ที่ Apple Pay ให้มาเพียงอย่างเดียว
    • Apple Pay ไม่ได้ป้องกันสถานการณ์อย่างกรณีที่ Target อนุมานสถานะของลูกค้าจากประวัติการซื้อของตนเอง
    • กระเป๋าเงินดิจิทัลอื่นก็มีข้อจำกัดเดียวกัน

การปกป้องที่ DPAN มอบให้เมื่อเกิดข้อมูลรั่วไหล

  • ในสถานการณ์ที่ข้อมูลบัตรชำระเงินรั่วไหล DPAN ปลอดภัยกว่า FPAN
  • ในปี 2024 ไม่ควรมีร้านค้าที่จัดการหมายเลขบัตรเครดิตโดยตรงแล้ว แต่ก็ยังอาจเกิดกรณี payment gateway ถูกแฮ็กและ DPAN กับวันหมดอายุรั่วไหลได้
  • ผู้โจมตีไม่สามารถทำรายการชำระเงินได้ด้วย DPAN ที่รั่วไหลเพียงอย่างเดียว
    • DPAN จะใช้งานได้ก็ต่อเมื่อถูกส่งเป็นส่วนหนึ่งของชุดเข้ารหัสเฉพาะสำหรับแต่ละธุรกรรม
    • มีวิธีทำการเรียกเก็บเงินซ้ำกับบัตรที่เก็บผ่าน Apple Pay ได้ แต่ไม่ควรเป็นสิ่งที่แฮ็กเกอร์ทำได้
  • เพราะฉะนั้น การที่ FPAN รั่วไหล จึงอันตรายกว่าการที่ DPAN ซึ่งกระเป๋าเงินดิจิทัลทั้งหมดเก็บไว้รั่วไหลมาก

Apple Pay ไม่ได้ซ่อนข้อมูลส่วนตัวโดยอัตโนมัติ

  • ความคิดที่ว่า Apple Pay ปกปิดข้อมูลส่วนตัวให้อัตโนมัตินั้นไม่ตรงกับความเป็นจริง
  • เมื่อลองทำธุรกรรม Apple Pay จริงในบัญชีร้านค้าทดสอบ รายงานระดับร้านค้าจะแสดงข้อมูลอย่างชื่อ อีเมล ที่อยู่เรียกเก็บเงิน และที่อยู่บ้าน
  • การชำระเงินสำหรับสินค้าที่จับต้องได้จำเป็นต้องมี ข้อมูลการจัดส่ง ดังนั้น Apple Pay SDK จึงเปิดให้ร้านค้าเลือกได้ว่าจะขอข้อมูลส่วนตัวใดจากลูกค้า
  • ข้อมูลสินค้าเองก็ถูกส่งไปยัง Apple Pay เพื่อแสดงให้ผู้ซื้อเห็นว่ากำลังซื้ออะไร และข้อมูลนี้ก็ถูกส่งต่อไปยังร้านค้าเช่นกัน
  • ควรมองว่าข้อมูลที่แสดงบนบัตร Apple Pay ระหว่างชำระเงินจะถูกส่งต่อให้ร้านค้า
    • ในแง่นี้ Apple Pay ก็เหมือนกับวิธีชำระเงินแบบอื่น
    • ร้านค้าจะเลือกขอข้อมูลส่วนตัวที่จำเป็นหรือต้องการในขั้นตอน checkout
    • กระเป๋าเงินดิจิทัลอื่นก็ทำงานในลักษณะเดียวกัน

การปกป้องที่กระเป๋าเงินดิจิทัลมอบให้จริง ๆ

  • Apple Pay เป็นวิธีชำระเงินที่ดี และ Apple ก็มีบทบาทในการทำให้กระเป๋าเงินดิจิทัลรูปแบบนี้แพร่หลายสู่คนทั่วไป
  • อย่างไรก็ตาม ความสามารถของ Apple Pay ไม่ได้มีความเฉพาะตัวในอุตสาหกรรม
  • DPAN มีประโยชน์ในการทำให้การติดตามการซื้อของคนคนหนึ่งข้ามหลายร้านค้าทำได้ยากขึ้น และช่วยลดความเสี่ยงของลูกค้าเมื่อข้อมูลบัตรชำระเงินรั่วไหล

1 ความคิดเห็น

 
GN⁺ 2024-03-29
ความคิดเห็นจาก Hacker News
  • อยากได้คำอธิบายแบบ ELI5 ว่า Apple Pay และ Google Pay ทำงานกันจริง ๆ อย่างไร แต่ก่อนเคยคิดว่าแค่ส่งข้อมูลบัตรให้ร้านค้าหรือผู้ให้บริการประมวลผลการชำระเงินตรง ๆ และต้นฉบับก็ดูเหมือนจะสื่อแบบนั้น อีกทั้งยังเคยเห็นว่าพอใช้ Amex ใน Google Pay ร้านค้าบางแห่งกลับปฏิเสธการชำระเงิน ทั้งที่ถ้าเป็น MasterCard กลับใช้ได้
    บางครั้งก็รู้สึกว่า Apple/Google ทำตัวเหมือนเป็นผู้ประมวลผลการชำระเงินหรือแม้แต่เป็นช่องทางการชำระเงินเอง เพราะมีการเก็บข้อมูลธุรกรรม และเครื่องรูดในร้านก็ดูเหมือนต้องรองรับพิเศษสำหรับแอป Apple/Google Pay
    ถ้าอย่างนั้น เคล็ดลับเฉพาะแบบผูกขาด ของ Apple/Google คืออะไรกันแน่ และทำไมถึงแทนที่ด้วยทางเลือกโอเพนซอร์สได้ยากหรือแทบเป็นไปไม่ได้ เป็นเพราะมีแค่ Apple/Google ที่เข้าถึงชิป NFC บน iOS/Android ได้อย่างเต็มรูปแบบหรือเปล่า?
    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 แบบไร้สัมผัส ซึ่งเป็นวิธีเดียวกับบัตรเครดิตแบบไร้สัมผัส เป็นมาตรฐานเบื้องหลัง Paywave ของ Visa และ Paypass ของ MC
      เพราะแบบนี้ เครื่องรับชำระเงินไร้สายส่วนใหญ่จึงรับ Apple Pay และ Google Pay ได้เลย และแทบไม่ต้องมีการรองรับพิเศษมากนัก สิ่งหนึ่งที่เปลี่ยนไปตามที่จำได้คือ อุปกรณ์แบบนี้ถูกมองว่าปลอดภัยกว่า ทำให้วงเงินชำระเงินสูงกว่าบัตรไร้สัมผัสทั่วไป
      เหตุผลที่ทำเวอร์ชันโอเพนซอร์สได้ยากก็เพราะการทำ EMV นั้นซับซ้อน และต้องมีการทดสอบกับการรับรองจำนวนมากผ่านอุปกรณ์เฉพาะทาง ตัวอุปกรณ์ต้องมี พื้นที่ปลอดภัย สำหรับเก็บ private key อย่างปลอดภัย และแอปต้องยืนยันได้ว่ามีการใช้การยืนยันตัวตนด้วยชีวมิติหรือการปลดล็อกด้วย PIN เพื่อรับประกันความปลอดภัยของผู้ใช้
      นอกจากนี้ ในขั้นตอนตั้งค่ายังต้องเชื่อมต่อกับแบ็กเอนด์ของธนาคารผู้ออกบัตรเพื่อรับกุญแจและข้อมูลที่จำเป็นด้วย แม้จะเป็นเวอร์ชันโอเพนซอร์ส ก็น่าจะยังต้องทำสัญญากับธนาคารและผ่านการตรวจรับรองในห้องแล็บจากที่อย่าง UL อยู่ดี
    • “เคล็ดลับ” อย่างเดียวจริง ๆ คือ การโอนความรับผิด การชำระเงินออนไลน์และแบบไร้สัมผัสแบบดั้งเดิมถูกจัดเป็นธุรกรรมแบบ “ไม่มีผู้ถือบัตรอยู่” ทำให้ความรับผิดกรณีฉ้อโกงตกกับร้านค้ามากกว่า
      Apple Pay, Google Pay และแอปชำระเงินที่ธนาคารให้บริการ ใช้การยืนยันตัวตนด้วยชีวมิติเพื่อยืนยันการอนุมัติจากผู้ถือบัตร ทำให้บางการชำระเงินกลายเป็นแบบ “ผู้ถือบัตรอยู่”
      ด้วยเหตุนี้ การปฏิเสธการทำรายการย้อนหลังบางประเภทจึงถูกตีกลับได้ทันที และประเภทอื่น ๆ ก็ลดภาระในการต้องส่งหลักฐานของร้านค้า
      เรื่องนี้เป็นส่วนหนึ่งของมาตรฐานเครือข่ายบัตร และถ้าสนใจก็ดูได้ที่ https://www.emvco.com/
      เหตุผลที่ไม่มีตัวเลือกโอเพนซอร์สก็เพราะต้องรับรองความปลอดภัยของการติดตั้งใช้งาน จึงจำเป็นต้องมีองค์กรเชิงพาณิชย์ที่ทำงานร่วมกับธนาคาร และยิ่งไปกว่านั้น แต่ละธนาคารก็ต้องเชื่อมต่อแยกกัน ทำให้มีธนาคารที่ต้องติดต่อมากเกินไป
    • กรณีที่ Amex ถูกปฏิเสธใน Google Pay แต่ MasterCard ใช้ได้ มักเกิดจากปัญหาการตั้งค่าของผู้ให้บริการเครื่องรับบัตร หรือไม่ก็แบ็กเอนด์ของผู้รับชำระเงินที่สื่อสารกับเครือข่ายบัตรยังรองรับ การรับรองฟังก์ชัน mobile wallet ไม่ครบ
      การทำให้ธุรกรรมต้นทางถึงปลายทางที่ครอบคลุมทุกเครือข่ายบัตร ทุกวิธีชำระเงิน และทุกอุปกรณ์ ทำงานได้ถูกต้องนั้นค่อนข้างยาก เพราะแต่ละเครือข่ายบัตรมีพารามิเตอร์ของ “payment kernel” และข้อกำหนดการรับรองที่รองรับต่างกัน
      หรืออาจเป็นความพยายามลดค่าธรรมเนียมธุรกรรมก็ได้ โดยทั่วไปแล้ว Amex มีค่าใช้จ่ายสำหรับร้านค้าสูงกว่ามาก
    • มีข้อมูลดี ๆ อยู่ที่นี่
      https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
  • ตอนที่ Apple Pay เริ่มถูกใช้อย่างแพร่หลายในช่วงแรก ฉันเคยดูมันค่อนข้างละเอียดจากประสบการณ์ด้านการประมวลผลการชำระเงินค้าปลีก สิ่งที่น่าประทับใจที่สุดในตอนนั้นคือมันหยั่งรากลึกแค่ไหนใน มาตรฐานอุตสาหกรรม
    หลังจากการสื่อสารไร้สายแล้ว ก็ไม่มีส่วนไหนที่เป็นของ Apple โดยเฉพาะ และจากที่อ่านบทความนี้ ดูเหมือนว่าจนถึงตอนนี้ก็ยังเป็นแบบนั้นอยู่
    ตอนนั้นฉันจำได้ว่ามีร้านค้าบางแห่งที่ตั้งใจรับการแตะจ่ายด้วยบัตรอยู่แล้ว แต่กลับเผลอรับการแตะจ่ายแบบ Apple ที่เป็นมาตรฐานอย่างมากโดยไม่ได้ตั้งใจ จนต้องไปเปลี่ยนระบบ ฉันนึกถึง CVS เป็นพิเศษ เพราะดูเหมือนพวกเขาเข้าร่วมระบบชำระเงินคู่แข่ง และอยากใช้จุดที่ระบบนั้นใช้ได้ในร้านของตัวเองเป็นความแตกต่างจาก Apple Pay
    พอช่วงหลังเริ่มมีความเชื่อว่า “อันนี้ทำได้เฉพาะ Apple Pay” ฉันก็สงสัยว่าหลังจากที่ตัวเองเลิกตามไปแล้วมันมีอะไรเปลี่ยนหรือเปล่า เลยดีใจที่ผู้เขียนมาทบทวนอัปเดตในบริบทนี้

    • เกร็ดส่วนตัวคือ ตอนที่ Apple Pay เปิดตัวใหม่ ๆ มันใช้ได้แค่ในสหรัฐฯ หรือพูดให้แม่นกว่านั้นคือ ตั้งค่าได้แค่ในสหรัฐฯ ไม่นานหลังจากนั้นฉันก็ย้ายไปออสเตรเลีย ซึ่ง tap-to-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 login ของโดเมนนั้น และถ้าเซิร์ฟเวอร์เพิ่งสื่อสารกับโดเมนนั้นเป็นครั้งแรก ก็ยังลงทะเบียนไคลเอนต์แบบทันทีได้ด้วย ไม่เคยเห็นใช้งานจริง แต่ถ้ามีก็น่าจะดี
      [0] https://datatracker.ietf.org/doc/html/rfc7591
      [1] https://datatracker.ietf.org/doc/html/rfc8414
    • เหตุผลคือเรื่อง “การเติบโตและการมีส่วนร่วม” ตั้งแต่ราวปี 2010 เทคโนโลยีเปลี่ยนจากเครื่องมือที่ช่วยเพิ่มอำนาจให้ผู้ใช้ ไปเป็นเครื่องมือที่ถลุงเวลาผู้ใช้ด้วยสแปม
      จากเดิมที่ให้บริการแล้วคิดค่าธรรมเนียมอย่างเป็นธรรม กลายเป็นส่งสแปมให้ผู้ใช้หรือเก็บข้อมูลไว้เพื่อส่งสแปมเพิ่มทีหลัง
      มาตรฐานแบบเปิดไม่ใช่สิ่งที่ผู้ให้บริการปัจจุบันต้องการ เพราะถ้าเป็นแบบนั้นผู้ใช้ก็ย้ายไปทางเลือกอื่นได้ง่ายและจะไม่ “มีส่วนร่วม” อีกต่อไป
    • วิธีตรวจสอบตัวตนผู้ใช้แตกต่างกันมากในแต่ละธุรกิจ ดังนั้นแต่ละธุรกิจจึงต้องตรวจสอบและไว้วางใจว่า SSO provider ปฏิบัติตามเกณฑ์ที่ตัวเองต้องการ ถ้ามี SSO provider เป็นล้านราย ก็ยากจะรู้ว่าแต่ละรายยึดมาตรฐานอะไร
    • การรองรับ “Login with Google” ต้องมีการตั้งค่าฝั่ง Google ต้องบอกว่าแอปนี้คืออะไร และหลังยืนยันตัวตนแล้วจะ redirect ไป URL ไหน ไม่อย่างนั้นจะเกิดปัญหาด้านความปลอดภัย
    • เพราะมันเจ็บปวดและเป็น แม่เหล็กดึงดูดการฉ้อโกง ตอนที่ Stack Overflow เคยผลักดันให้ใช้ OpenID ได้จากทุกที่ ก็มีปัญหาตามมา
  • ที่น่าสนใจคือ Apple Pay เปิดตัวหลังจากที่ธนาคารใหญ่ท้องถิ่นในออสเตรเลียผลักดันการใช้งานการชำระเงินแบบไร้สัมผัสมาหลายปี ดังนั้นตอนที่ Apple เข้ามาและเรียกเก็บค่าธรรมเนียมแบบอเมริกัน โครงสร้างพื้นฐานก็ถูกธนาคารวางไว้เองเรียบร้อยแล้ว
    ธนาคารใหญ่ของออสเตรเลียต้านการรองรับ Apple Pay อยู่นานหลายปี แต่สุดท้ายก็ยอมเพราะแรงกดดันจากลูกค้ามากเกินไป
    ตอนนี้ทุกคนก็ยังไม่พอใจกับเรื่องนี้มาก และถ้าหน่วยงานกำกับบังคับให้เปิดชิป NFC พวกเขาก็จะทิ้ง Apple Pay ทันที แต่จนถึงตอนนี้ก็หาคนที่เห็นใจการบ่นของธนาคารที่ใหญ่ที่สุดในประเทศได้ยาก

    • ที่ตลกคือธนาคารออสเตรเลียเคยขอให้ ACCC อนุญาตให้ ตั้งคาร์เทล เพื่อเจรจาร่วมกับ Apple และคว่ำบาตร Apple Pay แต่โดนปฏิเสธ
      https://www.accc.gov.au/media-release/accc-denies-authorisat...
    • ธนาคารคงเลิกใช้ Apple Pay ได้ยาก ตราบใดที่ผู้ใช้ยังไม่ยอมเฉย ๆ
      ธนาคารในแคนาดาก็เคยลองทำระบบชำระเงินไร้สัมผัสของตัวเองบน Android เช่น TD Pay แต่ไม่มีใครอยากใช้ สุดท้ายก็ยอมแพ้แล้วให้บริการ Google Pay
      คิดว่าน่าจะออกมาแนวเดียวกัน ต่อให้ Apple เปิด NFC payments ก็ไม่มีใครใช้แอปธนาคารอยู่ดี และจะชอบการรองรับโดยตรงแบบ Apple Pay หรือ Google Pay มากกว่า
      แค่ดูว่าระหว่าง 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 code ด้วยมือถือแล้วจ่ายผ่าน 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” แยกตามร้านค้าสำหรับธุรกรรม tap-to-pay ถึงอย่างนั้น ผมก็ยังยืนยันข้ออ้างของผมว่า Apple Wallet อย่างน้อยก็ปลอดภัยพอๆ กันหรือปลอดภัยกว่าบรรดาแอปจ่ายเงินดิจิทัลที่ผู้ออกบัตรเป็นผู้ให้บริการ]
      นี่คือโพสต์ของ Gruber ผู้เขียนต้นฉบับ
    • สำหรับส่วนที่ว่า “แม้ธนาคารหรือผู้ออกบัตรเครดิตจะได้สิทธิ์เข้าถึง NFC tap-to-pay ก็มีโอกาสน้อยมากที่พวกเขาจะทำสิ่งนี้เอง” Birchler ชี้ว่าธนาคารทำจริง
      และ Gruber ก็ยอมรับความผิดพลาดของตัวเอง
      Gruber เป็นแฟน Apple แบบเปิดเผย แต่โดยทั่วไปก็มักตรวจสอบข้อเท็จจริงให้ถูกต้อง ยอมรับเวลาที่ไม่รู้ และลิงก์ไปหาผู้เชี่ยวชาญในสาขานั้น
      แต่หลังจากมาตรการของ Apple ต่อ EU DMA เขาก็ดูเหมือนสูญเสียความเป็นกลางไปอย่างสิ้นเชิง ทั้งทำเหมือนเข้าใจถ้อยคำกฎหมายดีกว่า EC ใช้วิธีคิดแบบอเมริกันไปครอบกับแนวทางนิติบัญญัติยุโรปที่แตกต่างมาก และรับคำพูดที่มีเจตนาไม่ดีของ Apple มาแบบไม่ตั้งคำถาม
      การเปลี่ยนไปแบบนี้เกิดขึ้นพร้อมกับท่าทีที่ดูเป็นปฏิปักษ์กับ EU อย่างประหลาดของ Apple จนปัญหารากฐานอาจเป็นเพราะ Gruber เชื่อใจ Apple มากเกินไป
      และดูเหมือนเขาจะยังคงท่าทีนี้ต่อไปกับคดีผูกขาดของรัฐบาลสหรัฐฯ ด้วย
      พูดอย่างเป็นธรรม โซเชียลมีเดียเต็มไปด้วยผู้สนับสนุน Apple ที่ทำตัวเหมือนเป็นผู้เชี่ยวชาญด้านกฎหมายและพูดผิดแทบทุกเรื่อง ดังนั้นเขาอาจมองเห็นมุมคัดค้านที่มีฐานทางกฎหมายได้ยากก็ได้
    • ระหว่าง “Apple Pay ทำสิ่งนี้” กับ “มีแค่ Apple Pay เท่านั้น ที่ทำสิ่งนี้” ต่างกันมาก ดูเหมือน Gruber จะพูดอย่างแรก แต่ผู้เขียนกลับอ่านเป็นอย่างหลัง somehow
  • สำหรับประโยคที่ว่า “Apple ทำได้ยอดเยี่ยมในการทำให้กระเป๋าเงินดิจิทัลแบบนี้เป็นที่แพร่หลาย แต่สิ่งที่พวกเขาทำนั้นไม่ได้มีความเฉพาะตัวในอุตสาหกรรม” ผมอาจจำผิด แต่ตอน Apple Pay เปิดตัวครั้งแรก ผมคิดว่ามันค่อนข้างมีเอกลักษณ์ทีเดียว นั่นจึงเป็นเหตุผลว่าทำไมสถานที่ที่รองรับถึงมีน้อยมาก
    ระบบจ่ายเงินผ่านมือถืออื่นๆ เช่น Samsung Pay ยุคแรกๆ ดูเหมือนจะส่งหมายเลขบัตรจริงไปยังเครื่องปลายทางตรงๆ

    • ในสหรัฐฯ มันพบได้น้อย ในยุโรปและเอเชียรองรับการจ่ายแบบไร้สัมผัสมาระยะหนึ่งแล้ว และในสหราชอาณาจักรก็ใช้ได้ตั้งแต่ปี 2007 เพียงแต่ในช่วงแรกอย่างน้อยในสหราชอาณาจักรมีวงเงินค่อนข้างต่ำ
      ที่น่าสนใจคือสหราชอาณาจักรดูเหมือนจะยังมี วงเงิน £100 อยู่ แต่ในสหรัฐฯ ผมเคยจ่ายผ่านการชำระเงินแบบไร้สัมผัสบนโทรศัพท์ Android เป็นเงินเกิน $2000 มาแล้ว
    • ตอนนั้นก็มีวิธีอื่นอยู่หนึ่งหรือสองแบบเหมือนกัน แต่ดูคล้ายการเติมข้อมูลอัตโนมัติที่ถูกโหมเกินจริงมากกว่า Google Pay บางเวอร์ชันเป็นการกรอกข้อมูลลงเว็บไซต์ และจากที่จำได้คือมันส่งหมายเลขบัตรจริงไปเบื้องหลังไม่ทางใดก็ทางหนึ่ง
      อาจส่งตรงไปที่ธนาคารเท่านั้นจนร้านค้ามองไม่เห็นก็ได้ แต่ถึงอย่างนั้นก็ยังเป็นหมายเลขจริงอยู่ ดีที่สุดที่ผมจำได้ Apple คือรายแรกที่ผมได้ยินว่าใช้ DPAN
    • มาตรฐานการชำระเงินแบบไร้สัมผัสของ EMVCo ใช้ หมายเลขบัตรแบบโทเค็น มาโดยตลอด Samsung Pay อาจส่ง PAN ในการชำระเงินออนไลน์ก็ได้
    • ผมมองว่า Apple Pay เกือบจะเป็นการใช้งานหลักรายสุดท้ายที่เข้าสู่ตลาดเสียด้วยซ้ำ การใช้งานแรกบนมาตรฐาน EMV เดิมทีคือ Google Wallet แต่ติดเพราะ Google เปิดตัวทั่วโลกไม่สำเร็จตามสไตล์ของ Google เอง
      สหรัฐฯ ล้าหลังมากในเทคโนโลยีการชำระเงินด้วยบัตรด้วยหลายเหตุผล ถึงขั้นว่าตอนผมไปเยือนโปแลนด์พร้อมบัตรที่คนทั้งโลกใช้กันมาหลายปีแล้ว ผมยังต้องเรียนรู้วิธีเลี่ยงพิเศษก่อนเพื่อให้แคชเชียร์รับชำระเงินได้