Apple Pay ในแอปมือถือ: คืออะไรและทำงานอย่างไร

Apple Pay คืออะไรและทำไมจึงสำคัญในแอปมือถือ

Apple Pay คืออะไร

Apple Pay เป็นกระเป๋าเงินดิจิทัลและบริการชำระเงินของ Apple ช่วยให้ผู้ใช้เก็บบัตรเครดิต เดบิต และบัตรเติมเงินหรือบัตรร้านค้าบางประเภทไว้ได้อย่างปลอดภัยบน iPhone, Apple Watch, iPad หรือ Mac และชำระด้วยการแตะแค่ครั้งเดียวหรือมองหน้าจอเพื่อยืนยัน

แทนที่จะต้องกรอกหมายเลขบัตรและข้อมูลเรียกเก็บเงิน ผู้ใช้จะยืนยันด้วย Face ID, Touch ID หรือรหัสผ่านอุปกรณ์ Apple จะสร้างโทเค็นเฉพาะอุปกรณ์ จึงไม่ส่งหมายเลขบัตรจริงไปยังผู้ค้า

Apple Pay ใช้ได้ที่ไหน

Apple Pay ทำงานได้ในสามบริบทหลัก:

• ในร้าน: การชำระแบบไร้สัมผัสด้วย NFC บน iPhone หรือ Apple Watch ที่เครื่องรับชำระเงินจริง
• บนเว็บ: การชำระผ่าน Safari บน iOS และ macOS บนหน้าผลิตภัณฑ์หรือหน้าตะกร้า
• ในแอป: แผ่นระบบการชำระเงินแบบเนทีฟภายในแอป iOS และ iPadOS เรียกจากปุ่มเช็คเอาต์ของแอปโดยตรง

คู่มือนี้มุ่งไปที่การใช้งาน Apple Pay ในแอป ซึ่งประสบการณ์การชำระทั้งหมดอยู่ภายในแอป

ทำไมมันสำคัญในแอปมือถือ

การพิมพ์ข้อมูลบัตรบนหน้าจอเล็กช้ากว่าและมักเกิดข้อผิดพลาดได้ง่าย Apple Pay แทนที่ฟอร์มหลายช่องด้วยการโต้ตอบครั้งเดียว ซึ่งโดยทั่วไปจะ:

• ลดเวลาการเช็คเอาต์
• ลดการละทิ้งตะกร้า
• เพิ่มออเดอร์ที่สำเร็จและการสมัครสมาชิก

เพราะที่อยู่และบัตรถูกเก็บไว้บนอุปกรณ์อยู่แล้ว Apple Pay ยังลดแรงเสียดทานสำหรับลูกค้าใหม่ด้วย

ความพร้อมใช้งานและเมื่อใดควรใช้

Apple Pay ทำงานบนรุ่น iPhone, iPad, Apple Watch และ Mac ที่ใหม่พอสมควรในภูมิภาคที่รองรับ กับเครือข่ายหลักเช่น Visa, Mastercard, American Express และระบบท้องถิ่นหลายแห่ง ขึ้นกับธนาคารผู้ออกบัตร

Apple Pay เหมาะเมื่อ:

• ผู้ชมของคุณใช้เครื่อง iOS ในสัดส่วนที่มีนัยสำคัญ
• คุณพบการหลุดออกในขั้นตอนการป้อนข้อมูลบัตรหรือที่อยู่
• คุณต้องการรองรับการจ่ายด้วยบัตรโดยไม่ต้องจัดการข้อมูลบัตรดิบ

มันควรอยู่ เคียงข้าง แบบฟอร์มบัตรแบบดั้งเดิมและวอลเล็ตอื่นๆ ไม่ควรแทนที่ทั้งหมด เพื่อให้ผู้ใช้ที่ไม่มี Apple Pay ยังคงมีตัวเลือกชำระเงิน

วิธีการทำงานของ Apple Pay เบื้องหลัง

Apple Pay ซ่อนความซับซ้อนมากมายไว้เบื้องหลังประสบการณ์ "แตะสองครั้งเพื่อจ่าย" ที่ง่าย ในเบื้องหลัง ฝ่ายต่างๆ และชั้นความปลอดภัยหลายชั้นจะประสานงานกันเพื่อเคลื่อนย้ายเงินอย่างปลอดภัย

ผู้เล่นหลัก

การทำธุรกรรม Apple Pay ทั่วไปเกี่ยวข้องกับ:

• ผู้ใช้: เจ้าของอุปกรณ์และบัตร
• ธนาคารผู้ออก: ธนาคารที่ออกบัตรของผู้ใช้
• เครือข่ายบัตร: Visa, Mastercard, Amex เป็นต้น
• Apple: ให้ Wallet, ความปลอดภัยของอุปกรณ์ และโครงสร้างพื้นฐานการโทเค็น
• ผู้ค้า: แอปหรือธุรกิจของคุณที่ยอมรับการชำระ
• PSP / payment gateway / acquirer: ประมวลผลการชำระสำหรับผู้ค้าและเชื่อมต่อกับเครือข่ายบัตร

การโทเค็น: DPAN กับ FPAN

เมื่อผู้ใช้เพิ่มบัตรไปที่ Apple Wallet หมายเลขบัตรจริง (FPAN — Funding Primary Account Number) จะถูกส่งอย่างปลอดภัยไปยังเครือข่ายบัตรและผู้ออกบัตร พวกเขาจะตอบกลับด้วย DPAN (Device Primary Account Number) และกุญแจคริปโตกราฟิกเฉพาะอุปกรณ์นั้น

DPAN คือสิ่งที่ Apple Pay ใช้ในการทำธุรกรรม แอปของคุณและแบ็กเอนด์จะไม่เห็น FPAN นี่คือหัวใจของโมเดลการโทเค็นของ Apple Pay: อุปกรณ์ใช้หมายเลขบัตรสำรองและคริปโตกราฟแบบครั้งเดียวแทนการเปิดเผยหมายเลขบัตรจริง

Secure Element และการสร้างโทเค็นการชำระเงิน

บนอุปกรณ์ที่รองรับ ข้อมูลการชำระและกุญแจจะเก็บใน Secure Element (หรือถูกปกป้องผ่าน Secure Enclave) เมื่อผู้ใช้ยืนยันตัวตน (Face ID, Touch ID หรือรหัสผ่านอุปกรณ์) Secure Element จะ:

1. ใช้ DPAN และกุญแจเฉพาะเพื่อสร้าง payment cryptogram
2. ประกอบ Apple Pay payment token ที่มี:
   • DPAN
   • cryptogram เฉพาะธุรกรรม
   • เมตาดาต้าอื่นๆ (วันหมดอายุ, เครือข่าย เป็นต้น)
3. เข้ารหัสโทเค็นนี้สำหรับ ผู้ประมวลผลการชำระ ของคุณโดยใช้คีย์สาธารณะของพวกเขา

แอปของคุณจะได้รับโทเค็นที่มองไม่ทะลุและเข้ารหัสผ่าน Apple Pay APIs แล้วส่งต่อไปยังแบ็กเอนด์ ซึ่งจะส่งต่อไปยัง PSP หรือเกตเวย์

การอนุมัติและการชำระเงินจริง

PSP จะถอดรหัสโทเค็น ดึง DPAN และ cryptogram แล้วส่งคำขอ authorization ผ่านเครือข่ายบัตรไปยังธนาคารผู้ออก ผู้ออกตรวจสอบ cryptogram และสถานะบัตร แล้วอนุมัติหรือปฏิเสธ

หลังจากนั้น ในขั้นตอน settlement จำนวนเงินที่อนุมัติจะถูก capture, บรรจุเป็นชุด และโอนจากธนาคารผู้ออกไปยังธนาคารผู้รับ (acquirer) ของผู้ค้า สำหรับแอปของคุณ นี่คือการบันทึกการชำระหรือการเสร็จสิ้นการขาย แต่เบื้องหลังคือการประสานงานระหว่าง acquirer, เครือข่ายบัตร และผู้ออกโดยใช้ DPAN — ไม่ใช่หมายเลขบัตรจริงของลูกค้า

ข้อกำหนดและสิ่งที่ต้องเตรียมก่อนใช้งาน Apple Pay

ก่อนเพิ่ม Apple Pay ในแอป คุณต้องเตรียมข้อกำหนดทางเทคนิค ธุรกิจ และภูมิภาค

บัญชีและตัวระบุของ Apple

ในฝั่งผู้ค้า คุณต้องมี:

• บัญชี Apple Developer Program ที่ใช้งาน (จ่ายเงิน)
• App ID ที่เปิดใช้งานความสามารถ Apple Pay ใน Xcode
• อย่างน้อยหนึ่ง Apple Pay Merchant ID
• ใบรับรอง Payment Processing ที่เชื่อมโยงกับ Merchant ID นั้น

หลายผู้ค้ายังสร้าง Merchant Identity certificate สำหรับการตรวจสอบผู้ค้าในฟลูว์แบบเว็บหรือไฮบริด

แพลตฟอร์มและเวอร์ชัน OS ที่รองรับ

Apple Pay ในแอปรองรับบน:

• อุปกรณ์ iOS และ iPadOS ที่มี Touch ID หรือ Face ID หรือการจับคู่กับ Apple Watch
• เวอร์ชัน OS ที่ค่อนข้างใหม่ (โดยทั่วไปควรตั้งเป้า iOS 12+ เว้นแต่มีเหตุผลพิเศษ)

ตรวจสอบเอกสารปัจจุบันของ Apple สำหรับการสนับสนุนเวอร์ชันขั้นต่ำ โดยเฉพาะเมื่อต้องพึ่งพา API ใหม่ๆ

ความพร้อมใช้งานเชิงภูมิภาคและธนาคาร

Apple Pay ไม่ได้เปิดให้บริการทุกประเทศหรือทุกธนาคาร คุณต้องตรวจสอบว่า:

• Apple Pay รองรับในภูมิภาคที่คุณขาย
• เครือข่ายบัตรหลักที่คุณรับ (Visa, Mastercard, Amex ฯลฯ) รองรับ Apple Pay ในพื้นที่นั้น
• ธนาคารผู้รับหรือ PSP ของคุณสามารถประมวลผลธุรกรรม Apple Pay ในตลาดเหล่านั้นได้

หมวดผู้ค้าและสินค้าที่อนุญาต

Apple อาจจำกัดบางหมวดผู้ค้าและบางกรณีการใช้งาน (เช่น สินค้ผิดกฎหมาย บริการดิจิทัลบางประเภท หรือธุรกิจความเสี่ยงสูง) ตรวจสอบว่า:

• Merchant Category Code (MCC) ของคุณได้รับอนุญาตสำหรับ Apple Pay
• สินค้าและบริการในแอปของคุณสอดคล้องกับ App Store Review Guidelines และข้อกำหนดของ Apple Pay

การสนับสนุนจาก PSP และเกตเวย์

สุดท้าย คุณต้องใช้ PSP หรือเกตเวย์ที่รองรับการโทเค็นของ Apple Pay และการถอดรหัส ยืนยันว่า

• ผู้ให้บริการออกกุญแจที่จำเป็นสำหรับการถอดรหัสโทเค็น (หรือถอดรหัสให้คุณ)
• รองรับสกุลเงินและภูมิภาคของคุณ
• มีเอกสารและ SDK ชัดเจนสำหรับการรวม Apple Pay

กระบวนการประสบการณ์ผู้ใช้ของ Apple Pay ในแอปมือถือ

ฟลว์ Apple Pay ที่ราบรื่นรู้สึกแทบมองไม่เห็นสำหรับผู้ใช้ ต่อไปนี้คือลำดับขั้นตอนทั่วไป

1. จากหน้าผลิตภัณฑ์ไปยังปุ่ม Apple Pay

การเดินทางมักเริ่มจากหน้าผลิตภัณฑ์หรือตะกร้า เมื่อผู้ใช้เลือกไอเท็มและตัวเลือก (ขนาด สี จำนวน) พวกเขาจะไปที่เช็คเอาต์

ในหน้าตะกร้าหรือเช็คเอาต์ ให้แสดงปุ่ม Apple Pay มาตรฐานที่ Apple กำหนด ปุ่มควร:

• ใช้เครื่องหมาย “Pay” อย่างเป็นทางการ (ไม่ใช้ข้อความที่ปรับแต่งเช่น “Pay with Apple”)
• มองเห็นได้ชัดเจนใกล้ปุ่มเช็คเอาต์หลัก
• ระบุว่าจ่ายทั้งตะกร้าหรือรายการเดียว

2. แผ่นระบบ Apple Pay

เมื่อผู้ใช้แตะปุ่ม แผ่นระบบ Apple Pay จะเลื่อนขึ้นจากด้านล่างหน้าจอ

แผ่นนี้มักรวมถึง:

• บัตรการชำระ: เลือกบัตรเริ่มต้นได้และเปลี่ยนบัตรได้
• รายละเอียดการจัดส่ง: เลือกหรือยืนยันที่อยู่หากเป็นสินค้าจริง
• ข้อมูลติดต่อ: ชื่อ อีเมล และหมายเลขโทรศัพท์ แก้ไขได้เมื่อจำเป็น
• สรุปค่าใช้จ่าย: รายการแสดงรายการ (ไม่บังคับ) และยอดรวมรวมภาษีและค่าส่ง

ผู้ใช้สามารถปรับเปลี่ยนรายละเอียด (บัตร การจัดส่ง ข้อมูลติดต่อ) ได้ในแผ่นก่อนยืนยัน

3. การยืนยันตัวตน

เพื่ออนุญาตการชำระ ผู้ใช้ยืนยันด้วย:

• Face ID (มองที่อุปกรณ์)
• Touch ID (นิ้วบนเซ็นเซอร์)
• รหัสผ่านอุปกรณ์ (สำรองหากไบโอเมตริกซ์ล้มเหลวหรือไม่พร้อมใช้งาน)

แผ่นระบบจะแจ้งชัดเจน เช่น “Double-click to pay” บนอุปกรณ์ที่ใช้ Face ID

4. สถานะสำเร็จ ล้มเหลว และยกเลิก

หลังการยืนยัน แผ่นจะแสดงความคืบหน้าแล้วหายไป ส่งผู้ใช้กลับมาในแอปของคุณ

แอปควรแสดงสถานะที่ชัดเจนทันที:

• สำเร็จ: “Payment confirmed” พร้อมหมายเลขคำสั่งซื้อ สรุป และขั้นตอนถัดไป (การติดตาม ดาวน์โหลด)
• ล้มเหลว: ข้อความข้อผิดพลาดสั้นๆ (เช่น “Payment was declined”) และตัวเลือกอื่น เช่น ลองใช้บัตรอื่นหรือวิธีการชำระอื่น
• ยกเลิก: ถ้าผู้ใช้ยกเลิกในแผ่น ให้แสดงข้อความเป็นกลาง (เช่น “Payment not completed”) และเก็บผู้ใช้ไว้ที่หน้าชำระเงินโดยไม่สูญเสียข้อมูลตะกร้า

การทำให้สถานะเหล่านี้ชัดเจนช่วยให้ผู้ใช้มั่นใจว่าสถานะการชำระเงินไม่กำกวมและพวกเขายังคงควบคุมกระบวนการอยู่

ขั้นตอนหลักในการติดตั้ง Apple Pay บน iOS

การติดตั้ง Apple Pay บน iOS มุ่งเน้นที่เฟรมเวิร์ก PassKit และคลาสสำคัญบางตัว ต่อไปนี้คือฟลว์ระดับแอปจากต้นจนจบ

1. เปิดใช้งาน Apple Pay ใน Xcode

1. ใน Xcode เปิด Signing & Capabilities ของ target ของคุณ
2. คลิก + Capability และเพิ่ม Apple Pay
3. เลือก Merchant ID ที่คุณสร้างไว้ใน Apple Developer portal (หรือสร้างใหม่ถ้าจำเป็น)

การตั้งค่านี้เชื่อม bundle ของแอปกับตัวตนผู้ค้า เพื่อให้ Apple Pay tokens สามารถสร้างให้กับเซิร์ฟเวอร์ของคุณได้

2. นำเข้า PassKit และสร้าง PKPaymentRequest

import 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

3. เพิ่มและวาง PKPaymentButton

ใช้ PKPaymentButton แทนปุ่มแบบกำหนดเองเพื่อปฏิบัติตามแนวทาง UI ของ Apple:

let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)

วางไว้ในตำแหน่งที่มีเจตนาซื้อสูงสุด: หน้าผลิตภัณฑ์ ตะกร้า และเช็คเอาต์สุดท้าย ปิดหรือซ่อนหาก PKPaymentAuthorizationController.canMakePayments() คืนค่าเป็น false

4. แสดง 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

ก่อนแสดงแผ่นระบบ แอปของคุณต้องขอ merchant session จาก Apple

1. แอปส่ง URL การยืนยัน merchant ที่ได้รับจาก PKPaymentAuthorizationController ไปยังแบ็กเอนด์ของคุณ
2. เซิร์ฟเวอร์ของคุณ โดยใช้ Merchant ID และใบรับรองของ Apple Pay เรียกจุดเชื่อมต่อยืนยัน merchant ของ Apple
3. Apple คืนวัตถุ merchant session ที่ลงนามแล้ว
4. แบ็กเอนด์ส่ง session นี้กลับไปยังแอป ซึ่งใช้เพื่อเริ่ม Apple Pay

ฟลว์นี้พิสูจน์ให้ Apple เห็นว่าแอปเชื่อมโยงกับตัวตนผู้ค้าของคุณและโดเมน

การจัดการโทเค็นการชำระเงิน

หลังจากผู้ใช้อนุญาตการชำระ แอปจะได้รับโทเค็นการชำระที่เข้ารหัส (PKPaymentToken) และส่งไปยังแบ็กเอนด์ผ่าน HTTPS

บนเซิร์ฟเวอร์:

• อย่าพยายามถอดรหัสโทเค็นด้วยตัวเอง
• ส่งต่อโทเค็นตามเดิมไปยังเกตเวย์หรือผู้ประมวลผลที่รองรับ Apple Pay (เช่น Stripe, Adyen, Braintree)

เกตเวย์จะถอดรหัสโทเค็น (โดยใช้ network tokens หรือ DPAN) และรันการอนุมัติผ่านเครือข่ายบัตร

Authorization กับ capture

เกตเวย์มักให้สองฟลว์:

• Authorize only: จองเงินไว้ แล้ว capture ภายหลัง (เช่น หลังการจัดส่ง) เหมาะสำหรับสินค้าจริงหรือยอดที่เปลี่ยนแปลงได้
• Authorize and capture: เรียกเก็บเงินทันที เหมาะสำหรับสินค้าดิจิทัลหรือการสมัครที่เริ่มทันที

แบ็กเอนด์ของคุณควรบันทึก transaction ID, จำนวน, สกุลเงิน และสถานะ — แต่ไม่ใช่ข้อมูลบัตรดิบหรือเนื้อหาโทเค็นที่ถอดรหัสแล้ว

การเก็บข้อมูลและความปลอดภัย

เก็บเฉพาะสิ่งที่จำเป็นสำหรับการกระทบยอด คืนเงิน และการสนับสนุนลูกค้า:

• หมายเลขคำสั่งซื้อและ transaction ID
• ข้อมูลบัตรที่มาสก์และยี่ห้อ (ถ้าเกตเวย์ให้มา)
• เวลาการอนุมัติ/การ capture และจำนวน

อย่าเก็บหมายเลขบัตรเต็ม CVV หรือโทเค็นการชำระที่ไม่ได้เข้ารหัสบนเซิร์ฟเวอร์ของคุณ โอนการจัดการที่ละเอียดอ่อนให้เกตเวย์ที่เป็นไปตาม PCI และมั่นใจว่าการสื่อสารทั้งหมดใช้ TLS พร้อมการล็อกและการควบคุมการเข้าถึงที่เข้มงวด

ข้อควรพิจารณาด้านความปลอดภัย ความเป็นส่วนตัว และการปฏิบัติตามข้อกำหนด

Apple Pay ถูกออกแบบให้แอปของคุณไม่สัมผัสหมายเลขบัตรดิบ แต่คุณยังต้องเข้าใจโมเดลความปลอดภัยและความรับผิดชอบของตน

การโทเค็น: ซ่อนหมายเลขบัตรจริง

เมื่อผู้ใช้เพิ่มบัตรลงใน Apple Pay ผู้ออกและเครือข่ายจะทดแทนหมายเลข PAN จริงด้วย Device Account Number (DAN)

ระหว่างการชำระ:

• DAN และ cryptogram แบบใช้ครั้งเดียวถูกส่งแทนหมายเลขบัตรจริง
• cryptogram เฉพาะธุรกรรมไม่สามารถใช้ซ้ำได้หากถูกดักจับ

แอปและแบ็กเอนด์ของคุณเห็นเพียงโทเค็นและเมตาดาต้าการทำธุรกรรม ไม่เห็นรายละเอียดบัตรจริง

การป้องกันระดับอุปกรณ์: Secure Enclave และไบโอเมตริกซ์

กุญแจและข้อมูลการชำระจะถูกเก็บและประมวลผลใน Secure Enclave ซึ่งเป็นคอปโรเซสเซอร์แยกฮาร์ดแวร์

การอนุญาตถูกผูกกับการตรวจสอบตัวตนของผู้ใช้:

• Face ID / Touch ID
• หรือรหัสผ่านอุปกรณ์

แอปของคุณจะได้รับเพียงสัญญาณสำเร็จหรือไม่สำเร็จจากแผ่นระบบ ไม่สามารถเข้าถึงข้อมูลไบโอเมตริกซ์หรือเนื้อหาใน Secure Enclave ได้

การป้องกันเครือข่ายและ cryptograms แบบใช้ครั้งเดียว

แต่ละธุรกรรม Apple Pay ใช้:

• cryptogram ต่อธุรกรรม
• ข้อมูลที่เฉพาะเจาะจงต่อผู้ค้าและอุปกรณ์

เครือข่ายและผู้ออกตรวจสอบค่าเหล่านี้ ช่วยป้องกันการโคลน การเล่นซ้ำ และการดัดแปลง

ขอบเขต PCI DSS (ภาพรวม ไม่ใช่คำแนะนำทางกฎหมาย)

Apple Pay สามารถลดขอบเขต PCI DSS ของแอปคุณได้มากเพราะ:

• คุณไม่ได้เก็บ ส่ง หรือเก็บหมายเลขบัญชีหลัก
• การจัดการที่ละเอียดอ่อนส่วนใหญ่ถูกย้ายไปให้ Apple, เครือข่าย และ PSP

อย่างไรก็ตาม:

• คุณยังรับผิดชอบต่อวิธีการประมวลผลโทเค็นและข้อมูลที่เกี่ยวข้อง
• PSP และเกตเวย์ของคุณต้องเป็นไปตาม PCI

สำหรับคำแนะนำทางการ ให้ปรึกษาธนาคารผู้ออกของคุณ PSP และผู้ประเมินความปลอดภัยที่ได้รับการรับรอง

ปกป้อง API, บันทึก และข้อความข้อผิดพลาด

Apple Pay ลดความเสี่ยง แต่การรวมอย่างประมาทสามารถนำความเสี่ยงกลับมาได้

คำแนะนำปฏิบัติ:

• อย่าบันทึกโทเค็นการชำระดิบ เนื้อหาที่ถอดรหัส หรือ PAN เต็ม (ถ้าคุณเคยได้รับผ่าน PSP)
• มาสก์ตัวเลขบัตรจนเหลือ 4 หลักสุดท้ายในบันทึกและวิเคราะห์
• ลบโทเค็นการชำระและตัวระบุผู้ใช้จากรายงานการแครช
• ใช้ TLS ทุกที่ (ใช้ HSTS บนเว็บแบ็กเอนด์, พินใบรับรองเมื่อเหมาะสม)
• ถือว่าโทเค็นเป็นความลับ: TTL สั้น เก็บเฉพาะถ้าจำเป็น เข้ารหัสเมื่อพัก และจำกัดการเข้าถึงตาม IAM
• ออกแบบข้อความข้อผิดพลาดสำหรับผู้ใช้และบันทึกสำหรับวิศวกร: แสดงข้อความทั่วไปใน UI ใส่รายละเอียดทางเทคนิคเฉพาะในบันทึกที่ปลอดภัย

โดยเคารพขอบเขตเหล่านี้ คุณจะใช้ประโยชน์จากการป้องกันที่ Apple Pay มีให้ในขณะที่ลดภาระการปฏิบัติตามของตัวเอง

การทดสอบ Apple Pay: sandbox, สถานการณ์, และการดีบัก

การทดสอบครบถ้วนคือหนทางเดียวที่จะมั่นใจว่าการรวม Apple Pay ทำงานถูกต้องสำหรับลูกค้าจริง นั่นเริ่มจากการตั้งค่า sandbox และแผนการทดสอบที่ชัดเจน

การตั้งค่า sandbox testers และบัตรทดสอบ

ในบัญชี Apple Developer / App Store Connect ของคุณ สร้างบัญชีทดสอบ sandbox ภายใต้ Users and Access → Sandbox บัญชี Apple ID พิเศษเหล่านี้ใช้บนอุปกรณ์ทดสอบเพื่อจำลองผู้ใช้จริงโดยไม่เรียกเก็บเงิน

บนอุปกรณ์ทดสอบ:

• ลงชื่อออกจาก Apple ID ปกติใน Settings
• ลงชื่อเข้าใช้ App Store ด้วย Apple ID sandbox
• เพิ่มบัตรทดสอบใน Wallet โดยใช้หมายเลขจากเอกสารของ Apple (รายละเอียดบัตรทดสอบจะแตกต่างตามภูมิภาคและเกตเวย์)

ใช้ tester หลายบัญชีสำหรับโปรไฟล์ผู้ใช้ต่างๆ (ภูมิภาค สกุลเงิน เครือข่ายบัตร) เพื่อทำซ้ำกรณีมุมได้ต่อเนื่อง

การทดสอบบน Simulator เทียบกับอุปกรณ์จริง

iOS Simulator รองรับการทดสอบ Apple Pay พื้นฐาน ซึ่งมีประโยชน์สำหรับการตรวจสอบ UI และพัฒนาเบื้องต้น คุณสามารถจำลองการอนุญาตและเช็คว่า PKPaymentAuthorizationController ทำงาน

อย่างไรก็ตาม ให้ยืนยันบนอุปกรณ์จริงเสมอเพราะอุปกรณ์จริงเท่านั้นที่ให้:

• ฟลว์การตั้งค่า Wallet ที่แท้จริง
• ประสบการณ์ Face ID / Touch ID / รหัสผ่านจริง
• พฤติกรรมเฉพาะอุปกรณ์ เช่น ความน่าเชื่อถือของเครือข่ายและคำเตือนของระบบ

ถือว่า Simulator เป็นความสะดวก ไม่ใช่ตัวแทนที่สมบูรณ์

สถานการณ์ทดสอบหลัก

ครอบคลุมฟลว์ต่อไปนี้อย่างน้อย (ทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์):

• การอนุมัติและการ capture ที่สำเร็จ
• การปฏิเสธบัตร (ยอดไม่พอ, ปฏิเสธทั่วไป, บัตรไม่ถูกต้อง)
• การหมดเวลา / ข้อผิดพลาดเครือข่าย (ฝั่งไคลเอนต์และเกตเวย์)
• การยกเลิกโดยผู้ใช้ ในขั้นตอนต่างๆ (แผ่นแสดง, ไพรอมท์ไบโอ, การเลือกการจัดส่งหรือข้อมูลติดต่อ)
• การอนุมัติบางส่วนหรือการเปลี่ยนแปลงยอด หากเกตเวย์รองรับ (เช่น ทิป การปรับยอด)

ใช้หมายเลขบัตรทดสอบและทริกเกอร์เฉพาะของเกตเวย์เพื่อบังคับการปฏิเสธและรหัสข้อผิดพลาด

การล็อกและการดีบักอย่างปลอดภัย

บันทึกพอให้ติดตามปัญหา แต่ไม่บันทึกข้อมูลการชำระที่ละเอียดอ่อน หลีกเลี่ยง:

• PANs, วันหมดอายุ, CVC
• ที่อยู่เรียกเก็บ/ที่อยู่จัดส่งครบถ้วน
• โทเค็นหรือ payload ที่ถอดรหัสของ Apple Pay

แทนที่จะบันทึก:

• หมายเลขคำสั่งภายในและตัวระบุธุรกรรมของ Apple Pay (แบบตัดตอน)
• รหัสตอบกลับและข้อความข้อผิดพลาดจากเกตเวย์
• วิธีการจัดส่งที่เลือก ประเทศ และสกุลเงิน (เมื่อจำเป็น)
• การเปลี่ยนสถานะการชำระเงินระดับสูง (เช่น created → authorized → captured → failed)

เชื่อมโยงบันทึกฝั่งไคลเอนต์และเซิร์ฟเวอร์ด้วย correlation ID ที่ส่งจากแอปไปยังแบ็กเอนด์

การมอนิเตอร์ระหว่างการทดสอบ

ระหว่างรันการทดสอบ ให้เฝ้าดู:

• แดชบอร์ดเกตเวย์สำหรับการชำระทดสอบ การปฏิเสธ และอัตราข้อผิดพลาด
• หน้า Apple System Status สำหรับบริการ Apple Pay และบริการที่เกี่ยวข้อง

ถ้าพบข้อผิดพลาดเป็นช่วงๆ หรือการอนุมัติช้า ให้ตรวจสอบทั้งสถานะของเกตเวย์และสถานะของ Apple ก่อนสรุปว่าเป็นบั๊กการรวมระบบ นี่จะช่วยประหยัดเวลา

การออกแบบและแนวทาง UX เพื่อเพิ่มอัตราการแปลง

การออกแบบ Apple Pay ที่คิดมาอย่างดีสามารถเปลี่ยนจาก "สิ่งที่น่ามี" เป็นตัวขับเคลื่อนการแปลงเล็กๆ การวางตำแหน่งและคำสั้นๆ มีผลมาก

วางปุ่ม Apple Pay ที่ไหน

ใช้ Apple Pay ในจุดที่เจตนาซื้อชัดเจนที่สุด:

• ตำแหน่งหลักในขั้นตอนการชำระเงิน ของเช็คเอาต์ จัดกลุ่มกับวิธีการชำระอื่นๆ แต่เน้นให้เห็นชัด
• อยู่เหนือกรอบหน้าจอ บนหน้าชำระเงินบนมือถือ เพื่อให้เห็นโดยไม่ต้องเลื่อน
• แถบการกระทำแบบติดหน้า (sticky) ด้านล่างเมื่อเหมาะสม: แถบล่างถาวรที่มี “Apple Pay” เคียงข้างปุ่ม “Continue” ปกติ

หลีกเลี่ยงการซ่อน Apple Pay ไว้หลังการแตะเพิ่มเติม เช่น "More payment options" เพราะทุกก้าวเพิ่มโอกาสให้ผู้ใช้ไม่ดำเนินการต่อ

ใช้ Apple Pay เป็น Express Checkout

เสนอ Apple Pay เป็น express checkout จาก:

• หน้าผลิตภัณฑ์: เหมาะกับการซื้อรายการเดียว ราคาต่ำและตัดสินใจเร็ว
• หน้าตะกร้า: แสดง Apple Pay ข้างปุ่ม "Checkout" เพื่อให้ผู้ใช้ข้ามขั้นตอนการสร้างบัญชีหรือฟอร์มได้

เมื่อใช้เป็น express checkout ให้ชัดว่าที่อยู่จัดส่งและข้อมูลติดต่อจะถูกจัดการระหว่างการอนุญาต Apple Pay

ภาษา ขนาด และแบรนดิ้งของปุ่ม

ปฏิบัติตาม Human Interface Guidelines ของ Apple:

• ใช้ เครื่องหมาย "Apple Pay" อย่างเป็นทางการ โดยไม่แก้ไข
• ให้มีช่องว่างเพียงพอและทำให้ปุ่ม มีขนาดที่นิ้วหัวแม่มือถึงได้ง่าย ปกติเต็มความกว้างหน้าบนมือถือ
• ใช้ คำอธิบายชัดเจนใกล้ปุ่ม เช่น “Pay instantly with Apple Pay”

หลีกเลี่ยงสีหรือไอคอนที่ปรับแต่งจนลดการจดจำหรือขัดกับกฎแบรนด์

ลดขั้นตอนด้วยข้อมูลที่กรอกอัตโนมัติ

ให้ Apple Pay ช่วย:

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

เป้าหมายคือ แตะเดียวที่ชัดเจน ไม่ใช่ช่องทางหลายหน้าที่ยาวนาน

จัดการข้อผิดพลาดและการกู้คืนอย่างนุ่มนวล

วิธีที่เร็วที่สุดที่จะเสียยอดขายคือสถานะล้มเหลวที่ทำให้ผู้ใช้สับสน วางแผนสำหรับข้อผิดพลาดด้วย:

• ข้อความภาษาง่าย: “We couldn’t complete your Apple Pay payment. Your card was not charged.”
• ขั้นตอนถัดไปที่ทำได้: “Try another card in Apple Pay or choose a different payment method.”
• การออกแบบที่ไม่ทำลายข้อมูล: เก็บเนื้อหาในตะกร้า โค้ดส่วนลด และที่อยู่ไว้ เพื่อให้ผู้ใช้ลองใหม่โดยไม่ต้องทำงานซ้ำ

บันทึกรายละเอียดข้อผิดพลาดอย่างเงียบๆ สำหรับทีม แต่แสดงเฉพาะสิ่งที่ผู้ใช้ต้องรู้และทำต่อได้

ปัญหาที่พบบ่อยและวิธีแก้ไข

ข้อผิดพลาดการตั้งค่า

ปัญหา Apple Pay ส่วนใหญ่เกิดจากการตั้งค่าผิด ตรวจสอบว่า merchant ID ในโค้ดตรงกับบัญชี Apple Developer และการตั้งค่าในเกตเวย์อีกรอบ ตัวอักษรผิดตัวเดียวหรือใช้ sandbox ID ใน production ก็ทำให้ล้มเหลวได้

ต่อมา ให้ยืนยัน entitlements และ capabilities:

• Apple Pay ถูกเปิดใน target ของแอปใน Xcode
• เพิ่ม Merchant IDs ที่ถูกต้องใน entitlements ของแอป
• ใบรับรอง Payment Processing ถูกสร้างและยังไม่หมดอายุ

ถ้าปุ่ม Apple Pay ไม่ปรากฏหรือแผ่นไม่ขึ้น การตั้งค่ามักเป็นต้นเหตุหลัก

ความเข้ากันได้ของภูมิภาค เครือข่ายบัตร และอุปกรณ์

Apple Pay อาจรองรับในบางประเทศ ธนาคาร หรืออุปกรณ์แต่ไม่ทั้งหมด

ใช้ PKPaymentAuthorizationController.canMakePayments() และ canMakePayments(usingNetworks:) ก่อนแสดงปุ่ม หากคืนค่าเป็น false ให้ซ่อนปุ่มและแสดงคำอธิบายสั้นๆ พร้อมตัวเลือกชำระอื่น

เมื่อผู้ใช้รายงานว่าบัตร "ไม่รองรับ" ให้ตรวจสอบ:

• ธนาคารผู้ออกบัตรรองรับ Apple Pay หรือไม่
• เครือข่ายบัตร (เช่น Amex, Discover) อยู่ในรายการที่คุณกำหนดไว้หรือไม่

ความล้มเหลวในการยืนยัน merchant

ความล้มเหลวในการยืนยัน merchant มักแสดงเป็นแผ่น Apple Pay หายไปอย่างรวดเร็วหรือไม่ปรากฏเลย ในแอปเนทีฟ มักเกิดจาก:

• ใช้ merchant ID ที่ไม่ได้เชื่อมกับ bundle ID ของแอป
• ใบรับรอง Payment Processing หมดอายุหรือขาด
• การตั้งค่า Apple Pay ในเกตเวย์ไม่ถูกต้อง

บนเซิร์ฟเวอร์ ให้บันทึก:

• merchant identifier ที่เข้ามา
• สภาพแวดล้อม (sandbox vs production)
• ข้อผิดพลาดที่ได้จาก Apple หรือเกตเวย์

บันทึกเหล่านี้มักชี้ไปยังองค์ประกอบที่ตั้งค่าผิดได้ทันที

การปฏิเสธการทำธุรกรรมและข้อความแสดงต่อผู้ใช้

ไม่ใช่ทุกความล้มเหลวเป็นปัญหาทางเทคนิค หลายครั้งเป็น การปฏิเสธจากผู้ออกบัตร

ตรวจสอบการตอบกลับจากเกตเวย์หรือผู้ประมวลผล แยกระหว่าง:

• ข้อผิดพลาดทางเทคนิค (การถอดรหัสโทเค็นล้มเหลว คำขอไม่ถูกต้อง)
• การปฏิเสธทางการเงิน (ยอดไม่พอ สงสัยการฉ้อโกง บัตรไม่รองรับ)

แมปหมวดเหล่านี้เป็นข้อความที่เป็นมิตรแก่ผู้ใช้ เช่น:

• “Your bank declined this payment. Try another card or contact your bank.”
• “Something went wrong processing your payment. Please try again.”

หลีกเลี่ยงการเปิดเผยรหัสข้อผิดพลาดดิบจากเกตเวย์หรือรายละเอียดทางเทคนิคเกินจำเป็น

มอนิเตอร์บันทึกและการตอบกลับจากเกตเวย์ใน production

เพื่อรักษา Apple Pay ให้เสถียรใน production ให้ลงทุนกับ structured logging รอบการพยายามชำระแต่ละครั้ง:

• เวลาที่เกิดเหตุ สภาพแวดล้อม merchant ID และข้อมูลอุปกรณ์
• ตัวระบุโทเค็นการชำระที่ถูกตัดทอน (ไม่ใช่ข้อมูล PAN เต็ม)
• request IDs ของเกตเวย์และรหัสตอบกลับ

ตั้งแดชบอร์ดและการแจ้งเตือนสำหรับการเพิ่มขึ้นของอัตราการปฏิเสธ ข้อผิดพลาดการยืนยัน merchant หรือการหมดเวลา เชื่อมเหตุการณ์ฝั่งไคลเอนต์กับบันทึกเซิร์ฟเวอร์เพื่อค้นหาตำแหน่งที่ล้มเหลวได้เร็วขึ้น

ระดับการสังเกตนี้จะลดเวลาดีบักเมื่อปัญหาเกิดในทราฟฟิกจริงอย่างมาก

วัดผลและผลกระทบของ Apple Pay

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

เหตุการณ์ที่ควรติดตามรอบ Apple Pay

เริ่มด้วยการนิยามช่องทางที่ชัดเจนและบันทึกเหตุการณ์ในแต่ละขั้นตอน:

• Apple Pay sheet shown – ผู้ใช้แตะปุ่มและแผ่นปรากฏ
• Sheet canceled – ผู้ใช้ปิดแผ่น
• Authorization failed – ไบโอเมตริกซ์ล้มเหลวหรือผู้ใช้ปฏิเสธ
• Payment authorized – Apple Pay ส่งโทเค็นการชำระกลับแอป
• Payment captured – เซิร์ฟเวอร์ของคุณเรียกเก็บเงินสำเร็จ

เชื่อมโยงเหตุการณ์เหล่านี้กับบริบท:

• ตำแหน่งที่แตะปุ่ม (หน้าผลิตภัณฑ์ ตะกร้า เช็คเอาต์)
• แพลตฟอร์มและเวอร์ชัน OS
• ลูกค้าใหม่เทียบกับลูกค้ากลับมา

สิ่งนี้ช่วยให้เห็นว่าผู้ใช้หลุดออกจุดไหน และเป็นปัญหา UX (ยกเลิก) ทางเทคนิค (authorization failures) หรือฝั่งแบ็กเอนด์ (capture failures)

เมตริกหลักที่ต้องมอนิเตอร์

ชุดเมตริกที่ชัดเจนช่วยให้ตัดสินผลได้ง่ายขึ้น:

• อัตราการนำ Apple Pay ไปใช้ – เช็คเอาต์ Apple Pay ÷ เช็คเอาต์ทั้งหมดที่มีสิทธิ์
• อัตราความสำเร็จของ Apple Pay – captures ที่สำเร็จ ÷ ความพยายาม Apple Pay
• เวลาจ่าย – เวลามัธยฐานจากแผ่นแสดงถึงการ capture
• มูลค่าการสั่งซื้อเฉลี่ย (AOV) – เปรียบเทียบ AOV สำหรับ Apple Pay กับช่องทางอื่น
• อัตราการสำเร็จเช็คเอาต์ – สำหรับผู้ที่เห็น Apple Pay เทียบกับผู้ที่ไม่เห็น

ติดตามเมตริกเหล่านี้ตามช่วงเวลาและตามเวอร์ชันแอปเพื่อดูว่าการเปลี่ยนแปลงส่งผลหรือไม่

A/B Testing ตำแหน่งและข้อความของ Apple Pay

รันทดลองเพื่อปรับแต่งผลกระทบ:

• ตำแหน่ง: ทดสอบ Apple Pay บนหน้าผลิตภัณฑ์ ตะกร้า และเช็คเอาต์หลัก
• ลำดับความสำคัญ: เปรียบเทียบการทำเป็น CTA หลักกับตัวเลือกการชำระอื่น
• ข้อความ: ลองป้ายสั้น ("Buy with Apple Pay") กับข้อความที่สื่อคุณค่า ("Fast checkout with Apple Pay")
• ค่าดีฟอลต์: ทดลองเลือก Apple Pay ล่วงหน้าสำหรับผู้ใช้ที่มีสิทธิ์ เทียบกับค่าเริ่มต้นเป็นกลาง

วัดผลความแตกต่างในอัตราการนำไปใช้ อัตราความสำเร็จ เวลาจ่าย และอัตราการแปลง การเปลี่ยนแปลงรูปแบบเพียงเล็กน้อยก็ให้ผลต่างที่มีนัยได้

การวิเคราะห์และข้อพิจารณาด้านความเป็นส่วนตัว

ผสานรวมการวิเคราะห์อย่างระมัดระวังเพื่อเคารพการรับประกันความเป็นส่วนตัวของ Apple Pay และกฎระเบียบ:

• บันทึก ประเภทเหตุการณ์และผลลัพธ์ ไม่ใช่ข้อมูลบัตรหรือหมายเลขบัญชี
• หลีกเลี่ยงการเก็บ โทเค็นการชำระ นานกว่าที่จำเป็น
• ใช้ตัวระบุแบบ pseudonymous (เช่น user ID ของแอป) แทนการใช้ตัวระบุตรง
• กำหนดเครื่องมือวิเคราะห์ให้มาสก์หรือไม่บันทึกฟิลด์ที่ละเอียดอ่อน และระบุข้อมูลที่เก็บในนโยบายความเป็นส่วนตัว

แพลตฟอร์มวิเคราะห์หลักสามารถจัดการเหตุการณ์ Apple Pay ได้ตราบใดที่ payload ปราศจากข้อมูลการชำระที่ละเอียดอ่อน

ใช้ข้อมูลจาก Apple Pay เพื่อปรับปรุงเช็คเอาต์โดยรวม

ข้อมูลจาก Apple Pay มีประโยชน์เกินกว่าปุ่มเดียว:

• ถ้าผู้ใช้ Apple Pay มีอัตราการสำเร็จสูงและเวลาจ่ายต่ำ ให้ใช้เป็นเกณฑ์มาตรฐานสำหรับฟลว์บัตรและวอลเล็ต
• ถ้า Apple Pay ได้รับความนิยมบนมือถือแต่ต่ำบนแท็บเล็ต ให้ทบทวนเลย์เอาต์และความโดดเด่นตามอุปกรณ์
• ถ้าการยกเลิกพุ่งที่แผ่น Apple Pay ให้ปรับหน้าก่อนแผ่น — ชัดเจนเรื่องราคา ข้อมูลจัดส่ง และยอดรวมจะลดความลังเล

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

พิจารณาข้ามแพลตฟอร์มและหลายช่องทาง

การรองรับ Apple Pay มักไม่จบแค่แอป iOS เดียว ผู้ใช้คาดหวังการจ่ายแบบเดียวกันข้ามอุปกรณ์และช่องทาง การเลือกการออกแบบควรสะท้อนสิ่งนั้น

Native iOS กับ Apple Pay บนเว็บ

แอปเนทีฟ ใช้ PKPaymentAuthorizationController และส่งโทเค็นการชำระตรงไปยังแบ็กเอนด์ ให้ข้อดีคือ:

• การควบคุม UI อย่างลึก
• การผสานกับสถานะของแอป (ตะกร้า ผู้ใช้ล็อกอิน ข้อเสนอ)

Apple Pay บนเว็บ (Safari) ใช้ JavaScript และ Payment Request API เหมาะเมื่อ:

• คุณมีเช็คเอาต์บนเว็บแล้ว
• ต้องการ Apple Pay บนทั้งเดสก์ท็อปและ Safari บนมือถือ

สำหรับหลายทีม จุดลงตัวคือ: Apple Pay เนทีฟในแอป และ Apple Pay บนเว็บใน Safari โดยใช้ backend การชำระเงินร่วมกัน

วอลเล็ตอื่นๆ และความสอดคล้อง

ถ้าคุณรองรับ Google Pay, PayPal หรือวอลเล็ตอื่น ให้จัดฟลว์ให้สอดคล้อง:

• แสดงวอลเล็ตทั้งหมดในจุดตัดสินใจเดียวกัน
• ใช้การตั้งชื่อ ตำแหน่งปุ่ม และรูปแบบข้อผิดพลาดที่สอดคล้องกัน
• กำหนดกฎธุรกิจเหมือนกัน (เช่น ประเทศที่รองรับ ค่าใช้จ่ายขั้นต่ำ)

แบบนี้การสลับอุปกรณ์หรือวิธีการชำระจะไม่ทำให้ผู้ใช้รู้สึกต้องเรียนรู้ระบบใหม่

เฟรมเวิร์กข้ามแพลตฟอร์มและอุปกรณ์

สำหรับ React Native, Flutter และเฟรมเวิร์กคล้ายกัน คุณมักจะพึ่งพา:

• ปลั๊กอินอย่างเป็นทางการหรือจากชุมชนที่ห่อ API ของ Apple Pay แบบเนทีฟ
• เลเยอร์ธุรกิจร่วมที่เรียกโมดูลเฉพาะแพลตฟอร์มเล็กๆ

ทดสอบบน iPhone, iPad, และ Apple Watch ที่เกี่ยวข้อง:

• ยืนยันว่าเครือข่ายที่รองรับและตัวเลือกการจัดส่งเหมือนกัน
• ตรวจสอบสไตล์ปุ่มและป้ายบนแต่ละอุปกรณ์ให้เป็นไปตามแนวทางของ Apple

ตั้งเป้าสำหรับระบบการออกแบบและตรรกะเช็คเอาต์เดียวที่ข้าม iOS, เว็บ และแพลตฟอร์มอื่นๆ โดยมีชั้นบูรณาการบางส่วนเฉพาะสำหรับแต่ละช่องทาง แทนการทำงานชิ้นเดียวหลายครั้ง

การดูแล อัปเดต และเตรียมความพร้อมสำหรับอนาคตของ Apple Pay

การดูแล Apple Pay ให้ดีไม่ใช่เรื่องการเขียนใหม่ใหญ่โต แต่เป็นการบำรุงรักษาอย่างมีระเบียบ

ใบรับรอง คีย์ และเวอร์ชัน OS

Apple Pay พึ่งพา merchant IDs และใบรับรอง Payment Processing ที่มีวันหมดอายุ

สร้างแผนความเป็นเจ้าของ: ใครเป็นเจ้าของบัญชี Apple Developer, ใบรับรองอยู่ที่ไหน, และถูกใช้ใน CI/CD และบนเซิร์ฟเวอร์อย่างไร

จากนั้น:

• ตั้งเตือนในปฏิทินล่วงหน้า 90/60/30 วันก่อนหมดอายุ
• สคริปต์เช็คใน CI ที่ล้มการ build เมื่อใบรับรองใกล้หมดอายุ

ทุกการออกเวอร์ชัน iOS สำคัญควรกระตุ้นรอบการทดสอบสำหรับฟลว์ Apple Pay บน beta และ build สุดท้าย ให้เน้นที่:

• ลักษณะและข้อความของแผ่นระบบ
• เครือข่ายบัตรที่รองรับ
• กรณีมุมเช่น 3D Secure และไพรอมท์ไบโอเมตริกซ์

ติดตามแนวทางของ Apple

เฝ้าดู:

• Human Interface Guidelines (HIG) ของ Apple สำหรับปุ่ม Apple Pay การตั้งชื่อ และข้อความ
• เอกสารนักพัฒนาและ WWDC สำหรับการเปลี่ยนแปลงฟิลด์ที่จำเป็น โทเค็น หรือความสามารถ

วางแผนการตรวจสอบการออกแบบอย่างน้อยปีละครั้งเพื่อให้ข้อความ ตำแหน่งปุ่ม และการเข้าถึงสอดคล้องกับแนวทางปัจจุบัน

เครือข่าย สกุลเงิน และภูมิภาคที่เปลี่ยนแปลง

เครือข่ายบัตร สกุลเงิน และภูมิภาคที่รองรับเปลี่ยนตามเวลา ทำให้การตั้งค่าเหล่านี้ยืดหยุ่นได้:

• ควบคุมเครือข่ายที่รองรับ ประเทศ และสกุลเงินจากการตั้งค่าฝั่งเซิร์ฟเวอร์
• บันทึกการปฏิเสธตามเครือข่าย/ภูมิภาคเพื่อดูว่าควรเปิดตัวเลือกใหม่หรือไม่

ประสานงานกับเกตเวย์เมื่อพวกเขาเพิ่มเครือข่ายหรือวิธีการท้องถิ่น แล้วอัปเดต PKPaymentRequest ตามความจำเป็น

การย้ายระบบและรีแฟกเตอร์อย่างปลอดภัย

สำหรับการเปลี่ยนเกตเวย์ โครงสร้างแอป หรือรูปแบบโทเค็น:

• ใช้ feature flags เพื่อรันเส้นทางเก่าและใหม่ควบคู่กัน
• ให้ API ฝั่งเซิร์ฟเวอร์เป็นแบบ idempotent เพื่อหลีกเลี่ยงการชาร์จซ้ำเมื่อ retry
• เปิดตัวเป็นขั้นตอนและมอนิเตอร์อัตราการอนุมัติ/การปฏิเสธและการหมดเวลา

จัดทำเอกสารฟลว์เหล่านี้เพื่อให้สมาชิกทีมใหม่สามารถดูแลได้โดยไม่ต้องย้อนรอยโค้ดมากเกินไป

แนวโน้มที่ควรจับตามอง

คาดหวังการโทเค็นที่ลึกขึ้นกับเครือข่าย ใบเสร็จและการอัปเดตคำสั่งที่สมบูรณ์ยิ่งขึ้นใน Wallet และการเชื่อมต่อที่แน่นขึ้นระหว่างในแอป เว็บ และในร้าน ฟีเจอร์เช่น Tap to Pay on iPhone และตัวเลือกการเงินในภูมิภาคจะขยายต่อไป ดังนั้นออกแบบการรวมให้เป็นแบบคอนฟิกได้และพร้อมรับฟีเจอร์ใหม่โดยไม่ต้องเขียนระบบแกนหลักใหม่