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

การพลาดการแจ้งเตือนการคืนเงินคือหนทางเงียบๆ ที่ทำให้นักพัฒนาเสียการตัดสินใจคืนเงินเพียงสองกรณีที่ตนมีสิทธิ์ออกความเห็น CONSUMPTION_REQUEST ของ Apple และคำขอพิจารณา chargeback ของ Google Play ล้วนเริ่มต้นด้วยการแจ้งเตือน และทั้งคู่ปิดลงภายในเวลาอันสั้น คือ 12 ชั่วโมงสำหรับ Apple และ 24 ชั่วโมงสำหรับ Google หากเซิร์ฟเวอร์ของคุณล่ม ช้า หรือตั้งค่าผิดตอนที่ข้อความมาถึง สโตร์จะไม่รอคุณ สโตร์จะตัดสินใจจากข้อมูลที่มีอยู่แล้ว

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

แต่ละสโตร์ส่งการแจ้งเตือนการคืนเงินอย่างไร

Apple ส่ง App Store Server Notifications ตรงไปยัง URL แบบ HTTPS ที่คุณตั้งไว้ใน App Store Connect ส่วน Google ไม่ได้เรียกเซิร์ฟเวอร์ของคุณโดยตรง Google เผยแพร่ Real-time developer notifications ไปยัง topic ของ Google Cloud Pub/Sub แล้ว subscription ของคุณบน topic นั้นจะ push ข้อความไปยัง endpoint ของคุณ หรือรอให้เซิร์ฟเวอร์ของคุณ pull ไป

สิ่งที่ Apple ถือว่าล้มเหลว

เอกสารของ Apple ระบุไว้ชัดเจน ส่งคืนสถานะใดก็ได้ตั้งแต่ 200 ถึง 206 แล้วการส่งถือว่าเสร็จสิ้น ส่งคืน 40x หรือ 50x แล้ว Apple จะส่งซ้ำ Apple ยังถือว่ารหัสอื่นทั้งหมดไม่สำเร็จด้วย ความพยายามแต่ละครั้งจะถูกบันทึกพร้อม sendAttemptResult และค่าต่างๆ อ่านแล้วเหมือนรายการตรวจสอบเหตุขัดข้องจริง ได้แก่ TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE และอีกบางค่า สำหรับ TIMED_OUT คำแนะนำของ Apple เองคือให้ตรวจสอบว่าเซิร์ฟเวอร์ของคุณไม่ได้ประมวลผลข้อความก่อนตอบกลับ

สิ่งที่ Google ถือว่าล้มเหลว

สำหรับ subscription แบบ push รหัสตอบกลับที่สำเร็จจาก endpoint ของคุณคือการ acknowledge สำหรับ subscription แบบ pull เซิร์ฟเวอร์ของคุณต้อง acknowledge ทุกข้อความที่ pull มา มิฉะนั้น Pub/Sub จะส่งข้อความนั้นอีกครั้ง กำหนดเวลา acknowledge เริ่มต้นคือ 10 วินาที และสูงสุดคือ 600 วินาที คู่มือ RTDN ของ Google เพิ่มกฎอีกข้อที่ควรย้ำ คือการแจ้งเตือนบอกเพียงว่ามีบางอย่างเปลี่ยนไป คุณจึงยังต้องเรียก Google Play Developer API เพื่อดูสถานะการซื้อแบบครบถ้วน

ทำไมตารางการส่งซ้ำของ Apple ไม่เข้ากับกรอบเวลา 12 ชั่วโมง

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

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

Apple ส่งซ้ำหลังได้รับ HTTP 400 หรือไม่

ส่งซ้ำ ตามที่เอกสารระบุ Apple ระบุว่า 40x และ 50x คือรหัสที่ทำให้เกิดการส่งซ้ำ ในเดือนมีนาคม 2026 นักพัฒนารายหนึ่งรายงานในฟอรัมของ Apple ว่าการส่งซ้ำหลังการตอบกลับ 400 ดูเหมือนจะหยุดไป จากนั้นบอกว่าการส่งกลับมาทำงานอีกครั้งในหนึ่งหรือสองวันต่อมา และ Apple ขอให้ส่งรายงานผ่าน Feedback Assistant ให้ถือพฤติกรรมตามเอกสารเป็นกฎ และให้การเฝ้าติดตามของคุณเองเป็นหลักฐาน

กู้คืนการแจ้งเตือน App Store ที่พลาดไปด้วย Get Notification History

Get Notification History ส่งคืนการแจ้งเตือนเวอร์ชัน 2 ที่ Apple พยายามส่งไปยังเซิร์ฟเวอร์ของคุณในช่วงเวลาที่คุณเลือก แต่ละรายการมี payload ที่มีลายเซ็นแบบเต็ม คุณจึงส่งเข้า handler ตัวเดียวกับการแจ้งเตือนสดได้ แต่ละรายการยังมีอาร์เรย์ sendAttempts สูงสุดหกรายการ หนึ่งรายการสำหรับการส่งครั้งแรก และอีกหนึ่งรายการสำหรับการส่งซ้ำแต่ละครั้งจากทั้งห้าครั้ง

• startDate และ endDate เป็นค่าที่ต้องระบุ และ startDate ต้องอยู่ภายใน 180 วันที่ผ่านมาใน production หรือ 30 วันที่ผ่านมาใน sandbox
• ตั้ง onlyFailures เป็น true เพื่อรับเฉพาะการแจ้งเตือนที่ยังไม่ถึงเซิร์ฟเวอร์ของคุณ รวมถึงรายการที่ Apple ยังส่งซ้ำอยู่
• กรองด้วย notificationType หนึ่งค่า เช่น CONSUMPTION_REQUEST หรือ REFUND หรือด้วย transactionId สำหรับลูกค้ารายเดียว แต่ใช้ทั้งสองอย่างในคำขอเดียวกันไม่ได้
• การเรียกแต่ละครั้งส่งคืนได้สูงสุด 20 รายการ ให้เรียกต่อด้วย paginationToken ตราบที่ hasMore ยังเป็น true และส่ง request body เดิมทุกครั้ง

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

การแจ้งเตือน V1 กู้คืนด้วยวิธีนี้ไม่ได้

Get Notification History ครอบคลุมเฉพาะเวอร์ชัน 2 Apple ส่งการแจ้งเตือน V1 ซ้ำสามครั้ง ที่ 6, 24 และ 48 ชั่วโมงหลังความพยายามครั้งก่อน และหากล้มเหลวทั้งหมดก็จะไม่มีประวัติให้เล่นซ้ำ นี่คืออีกเหตุผลหนึ่งที่ควรย้ายแอปที่ยังใช้ V1 ไปใช้ V2

กู้คืนการแจ้งเตือนการคืนเงินของ Google Play ที่พลาดไป

ตาข่ายนิรภัยของ Google ก็คือ Pub/Sub นั่นเอง ตราบใดที่ subscription ของคุณยังอยู่ ข้อความที่ยังไม่มีใคร acknowledge จะคงอยู่ตลอดระยะเวลาเก็บรักษา คือ 7 วันโดยค่าเริ่มต้น และสูงสุด 31 วันหากคุณเพิ่มค่า เมื่อ endpoint ของคุณกลับมาทำงาน การส่งก็จะดำเนินต่อ มีการตั้งค่าสองอย่างที่อาจทำให้กลไกนี้ล้มเหลวโดยไม่รู้ตัว

• dead-letter topic จะย้ายข้อความออกจาก subscription ของคุณหลังการส่งล้มเหลวครบตามจำนวนที่กำหนด ค่าเริ่มต้นคือ 5 และด้วยนโยบายการส่งซ้ำเริ่มต้นที่ส่งซ้ำทันที ห้าครั้งอาจผ่านไปอย่างรวดเร็ว หากคุณใช้ ให้เฝ้าดู dead-letter topic เหมือนเป็นกล่องจดหมายที่สอง
• subscription ที่ไม่มีกิจกรรมจาก subscriber เช่น การเชื่อมต่อที่เปิดอยู่ การ pull ที่ทำงานอยู่ หรือการ push ที่สำเร็จ จะหมดอายุหลัง 31 วันโดยค่าเริ่มต้น endpoint ที่เสียอยู่นานหนึ่งเดือนอาจทำให้เสีย subscription ไปด้วย พร้อมทุกอย่างที่รออยู่ในนั้น

การคืนเงินที่ถูกยกเลิกมีช่องทางสำรอง 30 วัน

สำหรับการคืนเงินที่เกิดขึ้นแล้ว Voided Purchases API คือช่องทางสำรองแบบ pull API นี้แสดงรายการการซื้อที่ถูกยกเลิกย้อนหลัง 30 วัน สูงสุดหน้าละ 1,000 รายการ ด้วยโควตา 6,000 คำค้นต่อวันและ 30 คำค้นในทุกช่วง 30 วินาทีต่อแอป ส่ง type 1 เพื่อรวมการสมัครสมาชิกเข้ากับผลิตภัณฑ์แบบซื้อครั้งเดียว การรันทุกวันจะจับการคืนเงินที่ไปป์ไลน์การแจ้งเตือนของคุณทำหล่นได้ทั้งหมด ทำให้สิทธิ์การใช้งานและตัวเลขรายได้ถูกต้องเสมอ

คำขอพิจารณา chargeback ไม่มีช่องทางสำรอง

PendingRefundReviewNotification ต่างออกไป การแจ้งเตือนนี้มี pendingRefundToken ที่คุณต้องส่งให้ orders.reviewrefund และคุณมีเวลา 24 ชั่วโมงหลังได้รับเพื่อส่งความต้องการเรื่องการคืนเงินและหลักฐานการใช้งาน Google บันทึกการเรียกครั้งแรกของคุณและไม่สนใจครั้งต่อๆ ไป เอกสารของ Google ไม่ได้ระบุ endpoint ใดที่แสดงรายการคำขอพิจารณาที่รอดำเนินการ ดังนั้นหากข้อความ Pub/Sub นั้นหายไป หลักฐานของคุณสำหรับ chargeback นั้นก็หายไปด้วย

การแจ้งเตือนการคืนเงินที่พลาดไปทำให้เสียเงินเท่าไร

การพลาดการแจ้งเตือนของการคืนเงินที่สิ้นสุดแล้วทำให้เสียแค่งานด้านบัญชี คุณจะพบมันภายหลังใน Voided Purchases API หรือ Get Notification History เพิกถอนสิทธิ์การเข้าถึงหากนโยบายของคุณกำหนดไว้ แล้วรายงานของคุณก็จะตามทัน น่ารำคาญ แต่ไม่แพง

การพลาดการแจ้งเตือนในหนึ่งในสองกระบวนการที่โต้แย้งได้ทำให้เสียเงินจริง เพราะสโตร์ตัดสินใจโดยไม่มีหลักฐานของคุณ สำหรับ Apple หมายความว่าการตัดสินใจคืนเงินเกิดขึ้นโดยไม่มีข้อมูลการใช้งานของคุณ สำหรับ Google Play คำสั่งซื้อที่เกิดขึ้นหลังวันที่ 3 สิงหาคม 2026 หากแพ้ chargeback คุณจะเสียราคาซื้อหักค่าบริการของ Play บวกค่าธรรมเนียม chargeback ที่ธนาคารของผู้ซื้อเรียกเก็บ Google รับผิดชอบเฉพาะค่าบริการของตัวเองเท่านั้น

และเงินที่คุณใช้ไปเพื่อส่งมอบการซื้อนั้นก็หมดไปตั้งแต่ก่อนข้อพิพาทจะเริ่ม

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

ไม่มีสิ่งใดในนั้นกลับคืนมาเมื่อการคืนเงินได้รับอนุมัติ หลักฐานที่คุณส่งภายใน 12 หรือ 24 ชั่วโมงนั้นคือเครื่องมือเดียวที่คุณมี และการแจ้งเตือนที่พลาดไปจะพรากมันไป

ขั้นตอนการกู้คืนที่ไว้ใจได้

• acknowledge ก่อน เก็บ payload ดิบ ส่งคืนรหัสสำเร็จ แล้วค่อยประมวลผลในคิว
• polling Get Notification History ของ Apple ด้วย onlyFailures ทุกไม่กี่นาทีสำหรับ CONSUMPTION_REQUEST เพื่อให้ระบบล่มกินเวลาในกรอบ 12 ชั่วโมงเพียงไม่กี่นาที
• รันการกวาด Get Notification History รายวันด้วย onlyFailures ย้อนหลังไม่กี่วันสำหรับทุกประเภท แล้วเล่นซ้ำสิ่งที่พบ
• เรียก Voided Purchases API ทุกวันด้วย type 1 สำหรับแต่ละแอปบน Google Play แล้วกระทบยอดกับการคืนเงินที่คุณบันทึกไว้แล้ว
• บน Pub/Sub ให้ตั้งการเก็บรักษาข้อความไว้ 7 วันขึ้นไป ตั้งการแจ้งเตือนสำหรับ dead-letter topic หากมี และแจ้งเตือนเมื่อข้อความที่ส่งไม่สำเร็จสะสมมากขึ้น
• ทดสอบเส้นทางทั้งหมดใน production ด้วย sandbox ของ Apple ส่งการแจ้งเตือนแต่ละรายการครั้งเดียวโดยไม่มีการส่งซ้ำ ส่วน Request a Test Notification ร่วมกับ Get Test Notification Status จะแสดงให้เห็นอย่างชัดเจนว่าเซิร์ฟเวอร์ของคุณตอบกลับอย่างไร

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