ตรวจสอบการแจ้งเตือนจากเซิร์ฟเวอร์ App Store ก่อนดำเนินการกับการคืนเงิน เพราะใครก็ส่งคำขอมายัง URL webhook ของคุณได้

ใครก็ตามที่รู้ URL webhook ของคุณสามารถส่งการคืนเงินไปที่นั่นได้ นี่คือข้อเท็จจริงที่น่าอึดอัดเบื้องหลังการแจ้งเตือนจากเซิร์ฟเวอร์ App Store และ Real-time developer notification ของ Google Play ทุกรายการ จนกว่าคุณจะตรวจสอบ ข้อความนั้นเป็นเพียง HTTPS POST ที่มี JSON อยู่ข้างใน หากเซิร์ฟเวอร์ของคุณยกเลิกการสมัครสมาชิก เรียกคืนเครดิต หรือแบนบัญชีเพียงเพราะคำขอระบุว่า REFUND คุณก็ได้มอบอำนาจนั้นให้กับใครก็ได้ที่เขียนคำสั่ง curl เป็น

ทั้งสองสโตร์มีวิธีให้คุณตรวจสอบ Apple ลงนามในตัวการแจ้งเตือนเอง คุณจึงตรวจสอบการแจ้งเตือนจากเซิร์ฟเวอร์ App Store ได้โดยใช้เพียงใบรับรองรากของ Apple ส่วน Google Play ใช้แนวทางที่ต่างออกไป ตัวข้อความไม่ได้ถูกลงนาม แต่การส่งผ่าน Pub/Sub สามารถลงนามได้ และ Google ก็ยังกำหนดให้คุณยืนยันทุกการเปลี่ยนแปลงผ่าน API ของตนอยู่ดี ต่อไปนี้คือสิ่งที่แต่ละฝั่งพิสูจน์ได้ และความเสียหายที่เกิดขึ้นเมื่อคุณผิดพลาดไปทางใดทางหนึ่ง

แต่ละสโตร์ลงนามอะไรจริงๆ

วิธีตรวจสอบการแจ้งเตือนจากเซิร์ฟเวอร์ App Store

เอกสารของ Apple อธิบายว่า signedPayload เป็นสตริงที่ประกอบด้วยสามส่วนซึ่งเข้ารหัสแบบ Base64URL และคั่นด้วยจุด ได้แก่ header, payload และลายเซ็น โดยลงนามตามข้อกำหนด JSON Web Signature การถอดรหัส payload นั้นง่าย แต่การจะเชื่อถือมันได้ต้องผ่านการตรวจสอบสี่ขั้น

• อ่านอาร์เรย์ x5c จาก header ที่ถอดรหัสแล้ว Apple ระบุลำดับไว้ชัดเจน คือใบรับรองที่มีคีย์สำหรับลงนามมาก่อน ตามด้วยใบรับรองตัวกลางของ Apple แล้วจึงเป็นใบรับรองรากของ Apple
• ตรวจสอบห่วงโซ่นั้นกับใบรับรองรากของ Apple ที่คุณดาวน์โหลดเองจากเว็บไซต์ PKI ของ Apple ซึ่งในทางปฏิบัติคือ Apple Root CA - G3 อย่าเชื่อถือใบรับรองรากที่แนบมากับข้อความเด็ดขาด เพราะผู้ปลอมแปลงสามารถใส่ใบรับรองใดก็ได้ไว้ตรงนั้น
• ยืนยันว่าใบรับรองตัวกลางมีส่วนขยาย Apple Worldwide Developer Relations คือ 1.2.840.113635.100.6.2.1 จากนั้นตรวจสอบลายเซ็น JWS ด้วยกุญแจสาธารณะของใบรับรองปลายทาง
• ตรวจข้อมูลที่ถอดรหัสแล้วเทียบกับแอปของคุณ ได้แก่ bundleId, appAppleId ใน production และ environment ลายเซ็น Apple ที่ถูกต้องบนแอปของนักพัฒนารายอื่น หรือบนการซื้อใน sandbox ที่ส่งมายัง endpoint production ของคุณ ก็ยังไม่ใช่การคืนเงินของคุณ

จากนั้นทำซ้ำอีกครั้งกับสิ่งที่อยู่ข้างใน ออบเจ็กต์ data มี signedTransactionInfo และ signedRenewalInfo ซึ่งแต่ละตัวเป็น JWS แยกกันพร้อมห่วงโซ่ x5c ของตัวเอง handler สำหรับ REFUND ที่ตรวจสอบซองชั้นนอกแต่อ่านธุรกรรมโดยไม่ตรวจสอบ ได้ทิ้งช่องโหว่ไว้ตรงกลาง

ใช้ไลบรารีของ Apple แทนการเขียนเอง

Apple เผยแพร่ App Store Server Library สำหรับ Swift, Java, Python และ Node โดย SignedDataVerifier ของไลบรารีนี้รับใบรับรองรากของคุณ แฟล็กสำหรับการตรวจสอบออนไลน์ environment, bundle ID ของคุณ และสำหรับ production ก็รับ appAppleId ของคุณด้วย ซอร์สโค้ดฝั่ง Node แสดงให้เห็นสิ่งที่มันบังคับใช้ ได้แก่ ใบรับรองในห่วงโซ่ต้องมีสามใบพอดี ส่วนขยายของใบรับรองปลายทางของ Apple 1.2.840.113635.100.6.11.1 และส่วนขยายของใบรับรองตัวกลาง วันที่ใช้งานได้ของใบรับรอง และ bundle ID, app ID และ environment ที่ตรงกัน เมื่อเปิดการตรวจสอบออนไลน์ ไลบรารียังสอบถาม OCSP responder ด้วยว่าใบรับรองปลายทางและใบรับรองตัวกลางถูกเพิกถอนหรือไม่

รายการอนุญาต IP เพียงพอหรือไม่

ไม่เพียงพอ Apple ระบุว่าหากเซิร์ฟเวอร์ของคุณจำเป็นต้องใช้รายการอนุญาต คุณควรเพิ่ม subnet 17.0.0.0/8 ซึ่งใช้ได้ทั้ง sandbox และ production วิธีนี้ช่วยลดสัญญาณรบกวน แต่ไม่ได้พิสูจน์ว่าข้อความเป็นของจริง และจะใช้การไม่ได้ทันทีที่เครือข่ายของ Apple เปลี่ยนไปโดยที่คุณไม่ทราบ ให้การตรวจลายเซ็นเป็นด่านคัดกรองที่แท้จริงต่อไป

วิธีตรวจสอบการแจ้งเตือนการคืนเงินของ Google Play

Google Play เผยแพร่ข้อความ RTDN ไปยัง topic ของ Pub/Sub ที่คุณเป็นเจ้าของ และควรมีเพียง service account google-play-developer-notifications@system.gserviceaccount.com เท่านั้นที่ถือบทบาท Pub/Sub Publisher บน topic นั้น จากนั้น subscription ของคุณจะส่งข้อความด้วยวิธีใดวิธีหนึ่งจากสองวิธี และแต่ละวิธีมีหลักฐานของตัวเอง

• Pull subscription: เซิร์ฟเวอร์ของคุณเปิดการเชื่อมต่อที่ยืนยันตัวตนไปยัง Pub/Sub และดึงข้อความมาเอง ไม่มี endpoint สาธารณะ คนแปลกหน้าจึงไม่มีที่ให้ส่งข้อความเข้ามา
• Push subscription ที่เปิดการยืนยันตัวตน: Pub/Sub ลงนาม JSON Web Token และส่งมาใน header Authorization ในรูปแบบโทเค็น Bearer คู่มือของ Google กำหนดให้ตรวจสอบลายเซ็นของโทเค็น และตรวจว่า claim อีเมลและ audience ตรงกับค่าที่คุณตั้งค่าไว้ และโค้ดตัวอย่างของ Google ยังกำหนดให้ email_verified ต้องเป็น true ด้วย โทเค็นอาจมีอายุได้สูงสุดหนึ่งชั่วโมง
• Push subscription ที่ไม่มีการยืนยันตัวตน: อะไรก็ตามที่เข้าถึง URL ได้สามารถส่งข้อความที่มีหน้าตาเหมือน RTDN เข้ามาได้

ทำไม Google จึงต้องการให้คุณยืนยันผ่าน API

แม้แต่ RTDN ที่ยืนยันตัวตนได้อย่างสมบูรณ์ก็ไม่ได้บอกเรื่องราวทั้งหมด คู่มือการตั้งค่าของ Google ระบุไว้ชัดเจนว่าการแจ้งเตือนเหล่านี้บอกคุณเพียงว่าสถานะการซื้อเปลี่ยนไป และคุณต้องเรียก Google Play Developer API เพื่อรับสถานะที่สมบูรณ์ สำหรับ voidedPurchaseNotification หมายความว่าต้องค้นหาการซื้อนั้นใน Voided Purchases API หรือดึงสถานะปัจจุบันของมันก่อนที่จะเพิกถอนสิ่งใด การเรียก API ยืนยันตัวตนด้วย service account ของคุณเอง คำตอบที่ได้จึงเป็นสิ่งที่ผู้ปลอมแปลงไม่สามารถปลอมได้

การคืนเงินที่ถูกปลอมแปลงหรือถูกปฏิเสธทำให้คุณเสียเงินเท่าใด

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

ความล้มเหลวในทางตรงข้ามนั้นเงียบกว่าและมักใหญ่กว่า ตัวตรวจสอบที่ปฏิเสธข้อความจริง เพราะ appAppleId ผิด การตั้งค่า sandbox ใน production หรือใบรับรองรากที่ล้าสมัย จะทำให้สองกระบวนการคืนเงินที่หลักฐานของคุณมีน้ำหนักหลุดหายไป Apple ขอข้อมูลการใช้งานภายใน 12 ชั่วโมงหลังจาก CONSUMPTION_REQUEST ส่วน Google ให้เวลาคุณ 24 ชั่วโมงในการตอบการพิจารณา chargeback ผ่าน orders.reviewrefund และสำหรับคำสั่งซื้อที่เกิดขึ้นหลังวันที่ 3 สิงหาคม 2026 การแพ้ chargeback ของ Google Play จะทำให้คุณเสียราคาซื้อหักค่าบริการของ Play บวกค่าธรรมเนียมที่ธนาคารของผู้ซื้อเรียกเก็บ

อย่าปล่อยให้บั๊กในการตรวจสอบกินเวลาจนเลยกำหนด

• จัดเก็บคำขอดิบก่อนตรวจสอบ เพื่อให้ข้อความที่ถูกปฏิเสธไม่สูญหายไปจริงๆ
• ตั้งการแจ้งเตือนสำหรับการตรวจสอบที่ล้มเหลวทุกครั้ง ข้อความปลอมหนึ่งรายการเป็นเพียงสัญญาณรบกวน แต่หากทุกข้อความล้มเหลวพร้อมกัน นั่นคือบั๊กของคุณเอง
• ฝั่ง Apple คุณสามารถเล่นซ้ำสิ่งที่ปฏิเสธไปได้ Get Notification History ส่งคืน signedPayload ต้นฉบับย้อนหลัง 180 วัน ดังนั้นให้แก้ไขตัวตรวจสอบแล้วนำ payload ที่จัดเก็บไว้หรือกู้คืนมาผ่านตัวตรวจสอบอีกครั้ง
• ฝั่ง Google การพิจารณา chargeback ที่รอดำเนินการมีอยู่เฉพาะในการแจ้งเตือนเท่านั้น audience ของ push ที่ตั้งค่าผิดจึงหมายถึงการพิจารณาที่พลาดไป ให้ทดสอบด้วย Send Test Message ใน Play Console ทุกครั้งที่มีการเปลี่ยนแปลง

RefundHalt ตรวจสอบการแจ้งเตือนจากทั้งสองสโตร์ ยืนยันการคืนเงินกับ API ของสโตร์ก่อนที่จะมีสิ่งใดเปลี่ยนแปลง และตอบ CONSUMPTION_REQUEST รวมถึงการพิจารณา chargeback ภายในกรอบเวลา เพื่อไม่ให้ข้อความปลอมทำให้คุณเสียลูกค้า และไม่ให้ข้อความจริงหลุดรอดไป