14 ต.ค. 2568·5 นาที
Apple Pay ในแอปมือถือ: คืออะไรและทำงานอย่างไร
เรียนรู้ว่า Apple Pay ในแอปมือถือคืออะไร ทำงานอย่างไรเบื้องหลัง และวิธีผนวกอย่างปลอดภัยเพื่อเร่งการเช็คเอาต์และเพิ่มอัตราการแปลง
เรียนรู้ว่า Apple Pay ในแอปมือถือคืออะไร ทำงานอย่างไรเบื้องหลัง และวิธีผนวกอย่างปลอดภัยเพื่อเร่งการเช็คเอาต์และเพิ่มอัตราการแปลง
Apple Pay เป็นกระเป๋าเงินดิจิทัลและบริการชำระเงินของ Apple ช่วยให้ผู้ใช้เก็บบัตรเครดิต เดบิต และบัตรเติมเงินหรือบัตรร้านค้าบางประเภทไว้ได้อย่างปลอดภัยบน iPhone, Apple Watch, iPad หรือ Mac และชำระด้วยการแตะแค่ครั้งเดียวหรือมองหน้าจอเพื่อยืนยัน
แทนที่จะต้องกรอกหมายเลขบัตรและข้อมูลเรียกเก็บเงิน ผู้ใช้จะยืนยันด้วย Face ID, Touch ID หรือรหัสผ่านอุปกรณ์ Apple จะสร้างโทเค็นเฉพาะอุปกรณ์ จึงไม่ส่งหมายเลขบัตรจริงไปยังผู้ค้า
Apple Pay ทำงานได้ในสามบริบทหลัก:
คู่มือนี้มุ่งไปที่การใช้งาน Apple Pay ในแอป ซึ่งประสบการณ์การชำระทั้งหมดอยู่ภายในแอป
การพิมพ์ข้อมูลบัตรบนหน้าจอเล็กช้ากว่าและมักเกิดข้อผิดพลาดได้ง่าย Apple Pay แทนที่ฟอร์มหลายช่องด้วยการโต้ตอบครั้งเดียว ซึ่งโดยทั่วไปจะ:
เพราะที่อยู่และบัตรถูกเก็บไว้บนอุปกรณ์อยู่แล้ว Apple Pay ยังลดแรงเสียดทานสำหรับลูกค้าใหม่ด้วย
Apple Pay ทำงานบนรุ่น iPhone, iPad, Apple Watch และ Mac ที่ใหม่พอสมควรในภูมิภาคที่รองรับ กับเครือข่ายหลักเช่น Visa, Mastercard, American Express และระบบท้องถิ่นหลายแห่ง ขึ้นกับธนาคารผู้ออกบัตร
Apple Pay เหมาะเมื่อ:
มันควรอยู่ เคียงข้าง แบบฟอร์มบัตรแบบดั้งเดิมและวอลเล็ตอื่นๆ ไม่ควรแทนที่ทั้งหมด เพื่อให้ผู้ใช้ที่ไม่มี Apple Pay ยังคงมีตัวเลือกชำระเงิน
Apple Pay ซ่อนความซับซ้อนมากมายไว้เบื้องหลังประสบการณ์ "แตะสองครั้งเพื่อจ่าย" ที่ง่าย ในเบื้องหลัง ฝ่ายต่างๆ และชั้นความปลอดภัยหลายชั้นจะประสานงานกันเพื่อเคลื่อนย้ายเงินอย่างปลอดภัย
การทำธุรกรรม Apple Pay ทั่วไปเกี่ยวข้องกับ:
เมื่อผู้ใช้เพิ่มบัตรไปที่ Apple Wallet หมายเลขบัตรจริง (FPAN — Funding Primary Account Number) จะถูกส่งอย่างปลอดภัยไปยังเครือข่ายบัตรและผู้ออกบัตร พวกเขาจะตอบกลับด้วย DPAN (Device Primary Account Number) และกุญแจคริปโตกราฟิกเฉพาะอุปกรณ์นั้น
DPAN คือสิ่งที่ Apple Pay ใช้ในการทำธุรกรรม แอปของคุณและแบ็กเอนด์จะไม่เห็น FPAN นี่คือหัวใจของโมเดลการโทเค็นของ Apple Pay: อุปกรณ์ใช้หมายเลขบัตรสำรองและคริปโตกราฟแบบครั้งเดียวแทนการเปิดเผยหมายเลขบัตรจริง
บนอุปกรณ์ที่รองรับ ข้อมูลการชำระและกุญแจจะเก็บใน Secure Element (หรือถูกปกป้องผ่าน Secure Enclave) เมื่อผู้ใช้ยืนยันตัวตน (Face ID, Touch ID หรือรหัสผ่านอุปกรณ์) Secure Element จะ:
แอปของคุณจะได้รับโทเค็นที่มองไม่ทะลุและเข้ารหัสผ่าน Apple Pay APIs แล้วส่งต่อไปยังแบ็กเอนด์ ซึ่งจะส่งต่อไปยัง PSP หรือเกตเวย์
PSP จะถอดรหัสโทเค็น ดึง DPAN และ cryptogram แล้วส่งคำขอ authorization ผ่านเครือข่ายบัตรไปยังธนาคารผู้ออก ผู้ออกตรวจสอบ cryptogram และสถานะบัตร แล้วอนุมัติหรือปฏิเสธ
หลังจากนั้น ในขั้นตอน settlement จำนวนเงินที่อนุมัติจะถูก capture, บรรจุเป็นชุด และโอนจากธนาคารผู้ออกไปยังธนาคารผู้รับ (acquirer) ของผู้ค้า สำหรับแอปของคุณ นี่คือการบันทึกการชำระหรือการเสร็จสิ้นการขาย แต่เบื้องหลังคือการประสานงานระหว่าง acquirer, เครือข่ายบัตร และผู้ออกโดยใช้ DPAN — ไม่ใช่หมายเลขบัตรจริงของลูกค้า
ก่อนเพิ่ม Apple Pay ในแอป คุณต้องเตรียมข้อกำหนดทางเทคนิค ธุรกิจ และภูมิภาค
ในฝั่งผู้ค้า คุณต้องมี:
หลายผู้ค้ายังสร้าง Merchant Identity certificate สำหรับการตรวจสอบผู้ค้าในฟลูว์แบบเว็บหรือไฮบริด
Apple Pay ในแอปรองรับบน:
ตรวจสอบเอกสารปัจจุบันของ Apple สำหรับการสนับสนุนเวอร์ชันขั้นต่ำ โดยเฉพาะเมื่อต้องพึ่งพา API ใหม่ๆ
Apple Pay ไม่ได้เปิดให้บริการทุกประเทศหรือทุกธนาคาร คุณต้องตรวจสอบว่า:
Apple อาจจำกัดบางหมวดผู้ค้าและบางกรณีการใช้งาน (เช่น สินค้ผิดกฎหมาย บริการดิจิทัลบางประเภท หรือธุรกิจความเสี่ยงสูง) ตรวจสอบว่า:
สุดท้าย คุณต้องใช้ PSP หรือเกตเวย์ที่รองรับการโทเค็นของ Apple Pay และการถอดรหัส ยืนยันว่า
ฟลว์ Apple Pay ที่ราบรื่นรู้สึกแทบมองไม่เห็นสำหรับผู้ใช้ ต่อไปนี้คือลำดับขั้นตอนทั่วไป
การเดินทางมักเริ่มจากหน้าผลิตภัณฑ์หรือตะกร้า เมื่อผู้ใช้เลือกไอเท็มและตัวเลือก (ขนาด สี จำนวน) พวกเขาจะไปที่เช็คเอาต์
ในหน้าตะกร้าหรือเช็คเอาต์ ให้แสดงปุ่ม Apple Pay มาตรฐานที่ Apple กำหนด ปุ่มควร:
เมื่อผู้ใช้แตะปุ่ม แผ่นระบบ Apple Pay จะเลื่อนขึ้นจากด้านล่างหน้าจอ
แผ่นนี้มักรวมถึง:
ผู้ใช้สามารถปรับเปลี่ยนรายละเอียด (บัตร การจัดส่ง ข้อมูลติดต่อ) ได้ในแผ่นก่อนยืนยัน
เพื่ออนุญาตการชำระ ผู้ใช้ยืนยันด้วย:
แผ่นระบบจะแจ้งชัดเจน เช่น “Double-click to pay” บนอุปกรณ์ที่ใช้ Face ID
หลังการยืนยัน แผ่นจะแสดงความคืบหน้าแล้วหายไป ส่งผู้ใช้กลับมาในแอปของคุณ
แอปควรแสดงสถานะที่ชัดเจนทันที:
การทำให้สถานะเหล่านี้ชัดเจนช่วยให้ผู้ใช้มั่นใจว่าสถานะการชำระเงินไม่กำกวมและพวกเขายังคงควบคุมกระบวนการอยู่
การติดตั้ง Apple Pay บน iOS มุ่งเน้นที่เฟรมเวิร์ก PassKit และคลาสสำคัญบางตัว ต่อไปนี้คือฟลว์ระดับแอปจากต้นจนจบ
การตั้งค่านี้เชื่อม bundle ของแอปกับตัวตนผู้ค้า เพื่อให้ Apple Pay tokens สามารถสร้างให้กับเซิร์ฟเวอร์ของคุณได้
PKPaymentRequestimport PassKit
func createPaymentRequest() -> PKPaymentRequest? {
guard PKPaymentAuthorizationController.canMakePayments() else { return nil }
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.com.yourcompany.app"
request.countryCode = "US"
request.currencyCode = "USD"
request.supportedNetworks = [.visa, .masterCard, .amex]
request.merchantCapabilities = [.capability3DS]
request.paymentSummaryItems = [
PKPaymentSummaryItem(label: "Pro Subscription", amount: 9.99),
PKPaymentSummaryItem(label: "Your Company", amount: 9.99)
]
return request
}
merchantIdentifier, countryCode, และ currencyCode ต้องตรงกับการตั้งค่าผู้ค้าของคุณ supportedNetworks สะท้อนเครือข่ายบัตรที่คุณและ PSP รองรับ อย่างน้อยควรรวม .capability3DS ใน merchantCapabilities
PKPaymentButtonใช้ PKPaymentButton แทนปุ่มแบบกำหนดเองเพื่อปฏิบัติตามแนวทาง UI ของ Apple:
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
วางไว้ในตำแหน่งที่มีเจตนาซื้อสูงสุด: หน้าผลิตภัณฑ์ ตะกร้า และเช็คเอาต์สุดท้าย ปิดหรือซ่อนหาก PKPaymentAuthorizationController.canMakePayments() คืนค่าเป็น false
PKPaymentAuthorizationController และจัดการ callbackสร้าง controller จาก request และยอมให้คลาสของคุณ conform กับ PKPaymentAuthorizationControllerDelegate:
func startApplePay() {
guard let request = createPaymentRequest() else { return }
let controller = PKPaymentAuthorizationController(paymentRequest: request)
controller.delegate = self
controller.present(completion: nil)
}
extension CheckoutViewController: PKPaymentAuthorizationControllerDelegate {
func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController,
didAuthorizePayment payment: PKPayment,
handler completion: @escaping (PKPaymentAuthorizationResult) -> Void) {
// Send payment.token to your server for processing
// Then call completion(.init(status: .success, errors: nil)) or .failure
}
func paymentAuthorizationControllerDidFinish(_ controller: PKPaymentAuthorizationController) {
controller.dismiss(completion: nil)
}
}
ใน didAuthorizePayment คุณส่ง payment.token ไปยังเซิร์ฟเวอร์ของคุณเพื่อชาร์จ เมื่อเซิร์ฟเวอร์ตอบกลับ ให้เรียก completion ด้วย .success หรือ .failure แล้วปิดแผ่นใน paymentAuthorizationControllerDidFinish
ตรรกะฝั่งเซิร์ฟเวอร์คือสิ่งที่เปลี่ยนแผ่นระบบ Apple Pay ให้กลายเป็นการโอนเงินจริง แอปเก็บการอนุญาตผู้ใช้ ส่วนแบ็กเอนด์ของคุณตรวจสอบผู้ค้า ประมวลผลโทเค็น และคุยกับเกตเวย์การชำระเงิน
ก่อนแสดงแผ่นระบบ แอปของคุณต้องขอ merchant session จาก Apple
PKPaymentAuthorizationController ไปยังแบ็กเอนด์ของคุณฟลว์นี้พิสูจน์ให้ Apple เห็นว่าแอปเชื่อมโยงกับตัวตนผู้ค้าของคุณและโดเมน
หลังจากผู้ใช้อนุญาตการชำระ แอปจะได้รับโทเค็นการชำระที่เข้ารหัส (PKPaymentToken) และส่งไปยังแบ็กเอนด์ผ่าน HTTPS
บนเซิร์ฟเวอร์:
เกตเวย์จะถอดรหัสโทเค็น (โดยใช้ network tokens หรือ DPAN) และรันการอนุมัติผ่านเครือข่ายบัตร
เกตเวย์มักให้สองฟลว์:
แบ็กเอนด์ของคุณควรบันทึก transaction ID, จำนวน, สกุลเงิน และสถานะ — แต่ไม่ใช่ข้อมูลบัตรดิบหรือเนื้อหาโทเค็นที่ถอดรหัสแล้ว
เก็บเฉพาะสิ่งที่จำเป็นสำหรับการกระทบยอด คืนเงิน และการสนับสนุนลูกค้า:
อย่าเก็บหมายเลขบัตรเต็ม CVV หรือโทเค็นการชำระที่ไม่ได้เข้ารหัสบนเซิร์ฟเวอร์ของคุณ โอนการจัดการที่ละเอียดอ่อนให้เกตเวย์ที่เป็นไปตาม PCI และมั่นใจว่าการสื่อสารทั้งหมดใช้ TLS พร้อมการล็อกและการควบคุมการเข้าถึงที่เข้มงวด
Apple Pay ถูกออกแบบให้แอปของคุณไม่สัมผัสหมายเลขบัตรดิบ แต่คุณยังต้องเข้าใจโมเดลความปลอดภัยและความรับผิดชอบของตน
เมื่อผู้ใช้เพิ่มบัตรลงใน Apple Pay ผู้ออกและเครือข่ายจะทดแทนหมายเลข PAN จริงด้วย Device Account Number (DAN)
ระหว่างการชำระ:
แอปและแบ็กเอนด์ของคุณเห็นเพียงโทเค็นและเมตาดาต้าการทำธุรกรรม ไม่เห็นรายละเอียดบัตรจริง
กุญแจและข้อมูลการชำระจะถูกเก็บและประมวลผลใน Secure Enclave ซึ่งเป็นคอปโรเซสเซอร์แยกฮาร์ดแวร์
การอนุญาตถูกผูกกับการตรวจสอบตัวตนของผู้ใช้:
แอปของคุณจะได้รับเพียงสัญญาณสำเร็จหรือไม่สำเร็จจากแผ่นระบบ ไม่สามารถเข้าถึงข้อมูลไบโอเมตริกซ์หรือเนื้อหาใน Secure Enclave ได้
แต่ละธุรกรรม Apple Pay ใช้:
เครือข่ายและผู้ออกตรวจสอบค่าเหล่านี้ ช่วยป้องกันการโคลน การเล่นซ้ำ และการดัดแปลง
Apple Pay สามารถลดขอบเขต PCI DSS ของแอปคุณได้มากเพราะ:
อย่างไรก็ตาม:
สำหรับคำแนะนำทางการ ให้ปรึกษาธนาคารผู้ออกของคุณ PSP และผู้ประเมินความปลอดภัยที่ได้รับการรับรอง
Apple Pay ลดความเสี่ยง แต่การรวมอย่างประมาทสามารถนำความเสี่ยงกลับมาได้
คำแนะนำปฏิบัติ:
โดยเคารพขอบเขตเหล่านี้ คุณจะใช้ประโยชน์จากการป้องกันที่ Apple Pay มีให้ในขณะที่ลดภาระการปฏิบัติตามของตัวเอง
การทดสอบครบถ้วนคือหนทางเดียวที่จะมั่นใจว่าการรวม Apple Pay ทำงานถูกต้องสำหรับลูกค้าจริง นั่นเริ่มจากการตั้งค่า sandbox และแผนการทดสอบที่ชัดเจน
ในบัญชี Apple Developer / App Store Connect ของคุณ สร้างบัญชีทดสอบ sandbox ภายใต้ Users and Access → Sandbox บัญชี Apple ID พิเศษเหล่านี้ใช้บนอุปกรณ์ทดสอบเพื่อจำลองผู้ใช้จริงโดยไม่เรียกเก็บเงิน
บนอุปกรณ์ทดสอบ:
ใช้ tester หลายบัญชีสำหรับโปรไฟล์ผู้ใช้ต่างๆ (ภูมิภาค สกุลเงิน เครือข่ายบัตร) เพื่อทำซ้ำกรณีมุมได้ต่อเนื่อง
iOS Simulator รองรับการทดสอบ Apple Pay พื้นฐาน ซึ่งมีประโยชน์สำหรับการตรวจสอบ UI และพัฒนาเบื้องต้น คุณสามารถจำลองการอนุญาตและเช็คว่า PKPaymentAuthorizationController ทำงาน
อย่างไรก็ตาม ให้ยืนยันบนอุปกรณ์จริงเสมอเพราะอุปกรณ์จริงเท่านั้นที่ให้:
ถือว่า Simulator เป็นความสะดวก ไม่ใช่ตัวแทนที่สมบูรณ์
ครอบคลุมฟลว์ต่อไปนี้อย่างน้อย (ทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์):
ใช้หมายเลขบัตรทดสอบและทริกเกอร์เฉพาะของเกตเวย์เพื่อบังคับการปฏิเสธและรหัสข้อผิดพลาด
บันทึกพอให้ติดตามปัญหา แต่ไม่บันทึกข้อมูลการชำระที่ละเอียดอ่อน หลีกเลี่ยง:
แทนที่จะบันทึก:
created → authorized → captured → failed)เชื่อมโยงบันทึกฝั่งไคลเอนต์และเซิร์ฟเวอร์ด้วย correlation ID ที่ส่งจากแอปไปยังแบ็กเอนด์
ระหว่างรันการทดสอบ ให้เฝ้าดู:
ถ้าพบข้อผิดพลาดเป็นช่วงๆ หรือการอนุมัติช้า ให้ตรวจสอบทั้งสถานะของเกตเวย์และสถานะของ Apple ก่อนสรุปว่าเป็นบั๊กการรวมระบบ นี่จะช่วยประหยัดเวลา
การออกแบบ Apple Pay ที่คิดมาอย่างดีสามารถเปลี่ยนจาก "สิ่งที่น่ามี" เป็นตัวขับเคลื่อนการแปลงเล็กๆ การวางตำแหน่งและคำสั้นๆ มีผลมาก
ใช้ Apple Pay ในจุดที่เจตนาซื้อชัดเจนที่สุด:
หลีกเลี่ยงการซ่อน Apple Pay ไว้หลังการแตะเพิ่มเติม เช่น "More payment options" เพราะทุกก้าวเพิ่มโอกาสให้ผู้ใช้ไม่ดำเนินการต่อ
เสนอ Apple Pay เป็น express checkout จาก:
เมื่อใช้เป็น express checkout ให้ชัดว่าที่อยู่จัดส่งและข้อมูลติดต่อจะถูกจัดการระหว่างการอนุญาต Apple Pay
ปฏิบัติตาม Human Interface Guidelines ของ Apple:
หลีกเลี่ยงสีหรือไอคอนที่ปรับแต่งจนลดการจดจำหรือขัดกับกฎแบรนด์
ให้ Apple Pay ช่วย:
เป้าหมายคือ แตะเดียวที่ชัดเจน ไม่ใช่ช่องทางหลายหน้าที่ยาวนาน
วิธีที่เร็วที่สุดที่จะเสียยอดขายคือสถานะล้มเหลวที่ทำให้ผู้ใช้สับสน วางแผนสำหรับข้อผิดพลาดด้วย:
บันทึกรายละเอียดข้อผิดพลาดอย่างเงียบๆ สำหรับทีม แต่แสดงเฉพาะสิ่งที่ผู้ใช้ต้องรู้และทำต่อได้
ปัญหา Apple Pay ส่วนใหญ่เกิดจากการตั้งค่าผิด ตรวจสอบว่า merchant ID ในโค้ดตรงกับบัญชี Apple Developer และการตั้งค่าในเกตเวย์อีกรอบ ตัวอักษรผิดตัวเดียวหรือใช้ sandbox ID ใน production ก็ทำให้ล้มเหลวได้
ต่อมา ให้ยืนยัน entitlements และ capabilities:
ถ้าปุ่ม Apple Pay ไม่ปรากฏหรือแผ่นไม่ขึ้น การตั้งค่ามักเป็นต้นเหตุหลัก
Apple Pay อาจรองรับในบางประเทศ ธนาคาร หรืออุปกรณ์แต่ไม่ทั้งหมด
ใช้ PKPaymentAuthorizationController.canMakePayments() และ canMakePayments(usingNetworks:) ก่อนแสดงปุ่ม หากคืนค่าเป็น false ให้ซ่อนปุ่มและแสดงคำอธิบายสั้นๆ พร้อมตัวเลือกชำระอื่น
เมื่อผู้ใช้รายงานว่าบัตร "ไม่รองรับ" ให้ตรวจสอบ:
ความล้มเหลวในการยืนยัน merchant มักแสดงเป็นแผ่น Apple Pay หายไปอย่างรวดเร็วหรือไม่ปรากฏเลย ในแอปเนทีฟ มักเกิดจาก:
บนเซิร์ฟเวอร์ ให้บันทึก:
บันทึกเหล่านี้มักชี้ไปยังองค์ประกอบที่ตั้งค่าผิดได้ทันที
ไม่ใช่ทุกความล้มเหลวเป็นปัญหาทางเทคนิค หลายครั้งเป็น การปฏิเสธจากผู้ออกบัตร
ตรวจสอบการตอบกลับจากเกตเวย์หรือผู้ประมวลผล แยกระหว่าง:
แมปหมวดเหล่านี้เป็นข้อความที่เป็นมิตรแก่ผู้ใช้ เช่น:
หลีกเลี่ยงการเปิดเผยรหัสข้อผิดพลาดดิบจากเกตเวย์หรือรายละเอียดทางเทคนิคเกินจำเป็น
เพื่อรักษา Apple Pay ให้เสถียรใน production ให้ลงทุนกับ structured logging รอบการพยายามชำระแต่ละครั้ง:
ตั้งแดชบอร์ดและการแจ้งเตือนสำหรับการเพิ่มขึ้นของอัตราการปฏิเสธ ข้อผิดพลาดการยืนยัน merchant หรือการหมดเวลา เชื่อมเหตุการณ์ฝั่งไคลเอนต์กับบันทึกเซิร์ฟเวอร์เพื่อค้นหาตำแหน่งที่ล้มเหลวได้เร็วขึ้น
ระดับการสังเกตนี้จะลดเวลาดีบักเมื่อปัญหาเกิดในทราฟฟิกจริงอย่างมาก
เมื่อ Apple Pay ใช้งานในแอปมือถือของคุณแล้ว คุณต้องพิสูจน์ว่ามันช่วยปรับปรุงการเช็คเอาต์จริง ไม่ใช่แค่ดูทันสมัย ซึ่งหมายถึงการติดตามเหตุการณ์ที่ถูกต้อง ดูเมตริกหลัก และรันทดลองอย่างมีโครงสร้าง
เริ่มด้วยการนิยามช่องทางที่ชัดเจนและบันทึกเหตุการณ์ในแต่ละขั้นตอน:
เชื่อมโยงเหตุการณ์เหล่านี้กับบริบท:
สิ่งนี้ช่วยให้เห็นว่าผู้ใช้หลุดออกจุดไหน และเป็นปัญหา UX (ยกเลิก) ทางเทคนิค (authorization failures) หรือฝั่งแบ็กเอนด์ (capture failures)
ชุดเมตริกที่ชัดเจนช่วยให้ตัดสินผลได้ง่ายขึ้น:
ติดตามเมตริกเหล่านี้ตามช่วงเวลาและตามเวอร์ชันแอปเพื่อดูว่าการเปลี่ยนแปลงส่งผลหรือไม่
รันทดลองเพื่อปรับแต่งผลกระทบ:
วัดผลความแตกต่างในอัตราการนำไปใช้ อัตราความสำเร็จ เวลาจ่าย และอัตราการแปลง การเปลี่ยนแปลงรูปแบบเพียงเล็กน้อยก็ให้ผลต่างที่มีนัยได้
ผสานรวมการวิเคราะห์อย่างระมัดระวังเพื่อเคารพการรับประกันความเป็นส่วนตัวของ Apple Pay และกฎระเบียบ:
แพลตฟอร์มวิเคราะห์หลักสามารถจัดการเหตุการณ์ Apple Pay ได้ตราบใดที่ payload ปราศจากข้อมูลการชำระที่ละเอียดอ่อน
ข้อมูลจาก Apple Pay มีประโยชน์เกินกว่าปุ่มเดียว:
เมื่อเวลาผ่านไป การวัดเหล่านี้ช่วยปรับแต่งไม่เพียงแต่ Apple Pay ในแอปมือถือ แต่ทั้งประสบการณ์เช็คเอาต์ ทำให้ทุกขั้นตอนเร็วขึ้น ชัดเจนขึ้น และน่าเชื่อถือขึ้นสำหรับผู้ใช้
การรองรับ Apple Pay มักไม่จบแค่แอป iOS เดียว ผู้ใช้คาดหวังการจ่ายแบบเดียวกันข้ามอุปกรณ์และช่องทาง การเลือกการออกแบบควรสะท้อนสิ่งนั้น
แอปเนทีฟ ใช้ PKPaymentAuthorizationController และส่งโทเค็นการชำระตรงไปยังแบ็กเอนด์ ให้ข้อดีคือ:
Apple Pay บนเว็บ (Safari) ใช้ JavaScript และ Payment Request API เหมาะเมื่อ:
สำหรับหลายทีม จุดลงตัวคือ: Apple Pay เนทีฟในแอป และ Apple Pay บนเว็บใน Safari โดยใช้ backend การชำระเงินร่วมกัน
ถ้าคุณรองรับ Google Pay, PayPal หรือวอลเล็ตอื่น ให้จัดฟลว์ให้สอดคล้อง:
แบบนี้การสลับอุปกรณ์หรือวิธีการชำระจะไม่ทำให้ผู้ใช้รู้สึกต้องเรียนรู้ระบบใหม่
สำหรับ React Native, Flutter และเฟรมเวิร์กคล้ายกัน คุณมักจะพึ่งพา:
ทดสอบบน iPhone, iPad, และ Apple Watch ที่เกี่ยวข้อง:
ตั้งเป้าสำหรับระบบการออกแบบและตรรกะเช็คเอาต์เดียวที่ข้าม iOS, เว็บ และแพลตฟอร์มอื่นๆ โดยมีชั้นบูรณาการบางส่วนเฉพาะสำหรับแต่ละช่องทาง แทนการทำงานชิ้นเดียวหลายครั้ง
การดูแล Apple Pay ให้ดีไม่ใช่เรื่องการเขียนใหม่ใหญ่โต แต่เป็นการบำรุงรักษาอย่างมีระเบียบ
Apple Pay พึ่งพา merchant IDs และใบรับรอง Payment Processing ที่มีวันหมดอายุ
สร้างแผนความเป็นเจ้าของ: ใครเป็นเจ้าของบัญชี Apple Developer, ใบรับรองอยู่ที่ไหน, และถูกใช้ใน CI/CD และบนเซิร์ฟเวอร์อย่างไร
จากนั้น:
ทุกการออกเวอร์ชัน iOS สำคัญควรกระตุ้นรอบการทดสอบสำหรับฟลว์ Apple Pay บน beta และ build สุดท้าย ให้เน้นที่:
เฝ้าดู:
วางแผนการตรวจสอบการออกแบบอย่างน้อยปีละครั้งเพื่อให้ข้อความ ตำแหน่งปุ่ม และการเข้าถึงสอดคล้องกับแนวทางปัจจุบัน
เครือข่ายบัตร สกุลเงิน และภูมิภาคที่รองรับเปลี่ยนตามเวลา ทำให้การตั้งค่าเหล่านี้ยืดหยุ่นได้:
ประสานงานกับเกตเวย์เมื่อพวกเขาเพิ่มเครือข่ายหรือวิธีการท้องถิ่น แล้วอัปเดต PKPaymentRequest ตามความจำเป็น
สำหรับการเปลี่ยนเกตเวย์ โครงสร้างแอป หรือรูปแบบโทเค็น:
จัดทำเอกสารฟลว์เหล่านี้เพื่อให้สมาชิกทีมใหม่สามารถดูแลได้โดยไม่ต้องย้อนรอยโค้ดมากเกินไป
คาดหวังการโทเค็นที่ลึกขึ้นกับเครือข่าย ใบเสร็จและการอัปเดตคำสั่งที่สมบูรณ์ยิ่งขึ้นใน Wallet และการเชื่อมต่อที่แน่นขึ้นระหว่างในแอป เว็บ และในร้าน ฟีเจอร์เช่น Tap to Pay on iPhone และตัวเลือกการเงินในภูมิภาคจะขยายต่อไป ดังนั้นออกแบบการรวมให้เป็นแบบคอนฟิกได้และพร้อมรับฟีเจอร์ใหม่โดยไม่ต้องเขียนระบบแกนหลักใหม่
Apple Pay คือกระเป๋าเงินดิจิทัลของ Apple ที่ช่วยให้ผู้ใช้จ่ายเงินด้วยบัตรที่เก็บไว้บน iPhone, iPad, Apple Watch หรือ Mac ได้โดยไม่ต้องพิมพ์ข้อมูลบัตรลงในฟอร์ม
ในแอปมือถือ มันแทนที่การกรอกข้อมูลบัตรด้วยแผ่นระบบ (system sheet) ที่ปลอดภัยซึ่งผู้ใช้ยืนยันการชำระด้วย Face ID, Touch ID หรือรหัสผ่านอุปกรณ์ แอปจะได้รับโทเค็นการชำระที่เข้ารหัสแทนข้อมูลบัตรดิบ แล้วส่งโทเค็นนั้นไปยังแบ็กเอนด์และเกตเวย์เพื่อเรียกเก็บเงินจริง
วิธีนี้ทำให้การชำระเร็วขึ้น ลดความผิดพลาด และช่วยให้หมายเลขบัตรไม่ตกอยู่ในโครงสร้างพื้นฐานของแอปของคุณ
คุณควรเพิ่ม Apple Pay เมื่อ:
Apple Pay เหมาะที่สุดเมื่อทำงานเป็นตัวเลือกเสริมควบคู่กับช่องทางอื่นๆ เช่น บัตรหรือ PayPal อย่าลบวิธีการชำระเดิมทั้งหมด ให้เสนอ Apple Pay เป็นเส้นทางที่เร็วที่สุดสำหรับผู้ใช้ที่มีสิทธิ์
อย่างน้อยคุณต้องมี:
นอกจากนี้ต้องดำเนินการในภูมิภาคและกับธนาคารที่รองรับ Apple Pay และตรวจสอบว่า MCC (Merchant Category Code) และสินค้าบริการของคุณสอดคล้องกับข้อกำหนดของ Apple
บน iOS ให้ทำตามขั้นตอนหลักนี้:
อุปกรณ์สร้างโทเค็นการชำระที่เข้ารหัสซึ่งประกอบด้วย:
โทเค็นนี้ถูกเข้ารหัสสำหรับผู้ประมวลผลการชำระของคุณ ดังนั้นแอปและแบ็กเอนด์ของคุณรับโทเค็นเป็นก้อนทึบที่ไม่ต้องรู้รายละเอียดภายใน เซิร์ฟเวอร์ของคุณส่งต่อให้เกตเวย์ซึ่งถอดรหัสและส่งคำขออนุมัติไปยังเครือข่ายบัตรและผู้ออกบัตร แล้วคืนสถานะสำเร็จหรือปฏิเสธ
คุณจะไม่เห็น PAN หรือกุญแจคริปโตกราฟิกจริง — คุณเห็นเพียงเมตาดาต้าการทำธุรกรรมและสถานะ
แบ็กเอนด์ของคุณควร:
อย่าพยายามถอดรหัสโทเค็นเองหรือเก็บไว้ระยะยาว ปล่อยให้เกตเวย์ที่เป็นไปตาม PCI จัดการการประมวลผลข้อมูลที่ละเอียดอ่อน
สาเหตุทั่วไปที่ทำให้ Apple Pay ไม่แสดงแผ่นระบบหรือทำงานล้มเหลว ได้แก่:
เริ่มจากตรวจสอบการตั้งค่าใน Apple Developer portal, entitlements ใน Xcode และการตั้งค่าเกตเวย์ จากนั้นดูบันทึกเซิร์ฟเวอร์สำหรับข้อผิดพลาดการยืนยัน merchant และรหัสข้อผิดพลาดจากเกตเวย์
เพื่อทดสอบ Apple Pay อย่างปลอดภัย:
ใช้ Simulator สำหรับการตรวจสอบ UI เบื้องต้น แต่ทดสอบบนอุปกรณ์จริงเสมอเพื่อทดสอบการตั้งค่า Wallet, ไบโอเมตริกซ์ และสภาวะเครือข่ายจริง
แนวทาง UX ที่ช่วยเพิ่มอัตราการแปลง:
PKPaymentButton อย่างเป็นทางการ พร้อมข้อความสนับสนุนที่ชัดเจน เช่น “Pay instantly with Apple Pay”การออกแบบแบบนี้ช่วยลดแรงเสียดทานและทำให้ Apple Pay เป็นทางลัดที่รวดเร็วและเชื่อถือได้
ติดตาม Apple Pay เป็นช่องทางตัวหนึ่งในกราฟช่องทางการชำระเงินของคุณ สัญญาณสำคัญได้แก่:
รัน A/B tests สำหรับตำแหน่งปุ่มและข้อความ แล้วเปรียบเทียบพฤติกรรมผู้ใช้และอัตราการยกเลิกเพื่อวัดผลกระทบจริง
PKPaymentRequest ที่ระบุ merchant identifier, country, currency, supported networks และ summary itemsPKPaymentButton ในตำแหน่งที่ผู้ใช้ตัดสินใจจ่ายPKPaymentAuthorizationController พร้อมคำขอของคุณdidAuthorizePayment ให้ส่ง payment.token ไปยังแบ็กเอนด์ของคุณเพื่อประมวลผล.success หรือ .failure แล้วปิดแผ่นระบบการยืนยันตัวตนด้วยไบโอเมตริกซ์ การสร้างโทเค็น และงานหนักส่วนใหญ่จะถูกจัดการโดย UI ของระบบ