ทำไมเซิร์ฟเวอร์ของฉันจึงได้รับการแจ้งเตือนการคืนเงินของ App Store เดียวกันมากกว่าหนึ่งครั้ง?

เพราะ Apple ส่ง App Store Server Notification V2 ซ้ำได้สูงสุดห้าครั้ง ที่ 1, 12, 24, 48 และ 72 ชั่วโมงหลังความพยายามครั้งล่าสุด เมื่อใดก็ตามที่เซิร์ฟเวอร์ของคุณไม่ตอบด้วยสถานะ HTTP ระหว่าง 200 ถึง 206 การส่งซ้ำทุกครั้งมี notificationUUID เดียวกัน คุณจึงจดจำและข้ามมันได้

ฉันควรใช้ฟิลด์ใดเพื่อกำจัดรายการซ้ำของ App Store Server Notifications?

ใช้ notificationUUID การส่งซ้ำจริงจะทำซ้ำ notificationUUID เดียวกันเสมอ ในขณะที่ทุกเหตุการณ์ที่ใหม่จริง ๆ รวมถึง CONSUMPTION_REQUEST ใหม่แต่ละรายการ จะได้ค่าที่ต่างกัน ดังนั้นการกำจัดรายการซ้ำโดยใช้ notificationUUID จึงข้ามการซ้ำโดยไม่ทิ้งเหตุการณ์ที่แตกต่าง

การแจ้งเตือน CONSUMPTION_REQUEST ที่เกิดซ้ำเป็นรายการซ้ำที่ฉันควรเพิกเฉยหรือไม่?

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

ฉันจะกำจัดรายการซ้ำของ Google Play Real-time Developer Notifications อย่างไร?

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

บทความทั้งหมด

Deep dive13 สิงหาคม 2569ใช้เวลาอ่าน 8 นาที

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

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

ซองกระดาษที่เหมือนกันจำนวนมากวางซ้อนกันบนโต๊ะสีเข้มโดยมีหนึ่งซองถูกดึงแยกออกมา แทนการแจ้งเตือนการคืนเงินที่ซ้ำกันซึ่งมาถึงเซิร์ฟเวอร์ของคุณ

ประเด็นสำคัญ

Apple ส่ง App Store Server Notification V2 ซ้ำห้าครั้ง ที่ 1, 12, 24, 48 และ 72 ชั่วโมงหลังความพยายามครั้งล่าสุด เมื่อใดก็ตามที่เซิร์ฟเวอร์ของคุณไม่ตอบด้วยสถานะ HTTP ระหว่าง 200 ถึง 206 เมื่อนับความพยายามครั้งแรกด้วย การคืนเงินหนึ่งรายการอาจมาถึงได้สูงสุดหกครั้ง
การส่งซ้ำจริงทุกครั้งของ Apple มี notificationUUID เดียวกัน ดังนั้นฟิลด์นั้น ไม่ใช่ transaction id คือคีย์สำหรับกำจัดรายการซ้ำของคุณ
Real-time Developer Notifications ของ Google Play ทำงานบน Cloud Pub/Sub ซึ่งรับประกันการส่งอย่างน้อยหนึ่งครั้งและไม่รับประกันลำดับ ดังนั้นข้อความเดียวกันจึงมาถึงได้สองครั้งหรือมาผิดลำดับ Google บอกให้คุณตรวจสอบ messageId เพื่อความไม่ซ้ำกันก่อนประมวลผลสิ่งใด
การแจ้งเตือน CONSUMPTION_REQUEST เป็นระยะของ Apple ไม่ใช่การส่งซ้ำ Apple ส่งรายการใหม่ต่อเนื่องตลอดหน้าต่างการคืนเงินที่เปิดอยู่ แต่ละรายการมี notificationUUID ต่างกัน ดังนั้นการกำจัดรายการซ้ำโดยใช้ notificationUUID จึงเก็บทุกรายการไว้อย่างถูกต้อง
transactionId เดียวกันของ Apple สามารถนำพาการตัดสินได้มากกว่าหนึ่งครั้ง เช่น REFUND_DECLINED ตามด้วย REFUND ในภายหลัง ดังนั้นการกำจัดรายการซ้ำโดยใช้ transaction id เพียงอย่างเดียวจึงทิ้งเหตุการณ์ที่แตกต่างซึ่งคุณต้องการไป
การปฏิเสธรายการซ้ำด้วยการคืนค่า 4xx หรือ 5xx มีแต่จะทำให้สโตร์ส่งซ้ำ จงกำจัดรายการซ้ำภายในฐานข้อมูลของคุณเองและคืนค่าสถานะสำเร็จเสมอ
ตัวจัดการการคืนเงินที่ไม่เป็น idempotent จะดำเนินการซ้ำเมื่อมีการส่งครั้งที่สอง มันหักยอดคงเหลือสองครั้ง กลับรายการจ่ายเงินสองครั้ง หรือเผาโควตา Play Developer และ App Store Server API ที่คิดค่าใช้จ่ายด้วยการตรวจสอบการคืนเงินที่ปิดไปแล้วซ้ำ

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

การแจ้งเตือนการคืนเงินถูกส่งอย่างน้อยหนึ่งครั้ง ซึ่งไม่เหมือนกับส่งเพียงหนึ่งครั้งพอดี

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

Apple ส่งซ้ำห้าครั้งภายในสามวัน

เมื่อ Apple ส่ง App Store Server Notification V2 มันคาดหวังให้เซิร์ฟเวอร์ของคุณตอบด้วยสถานะ HTTP ในช่วง 200 ถึง 206 อย่างอื่นใด ไม่ว่าจะเป็น 4xx หรือ 5xx บอก Apple ว่าการส่งล้มเหลว และ Apple จะส่งซ้ำ ตารางเวลาคงที่: ส่งซ้ำห้าครั้ง ที่ 1, 12, 24, 48 และ 72 ชั่วโมงหลังความพยายามครั้งก่อน เมื่อนับความพยายามครั้งแรกด้วย เหตุการณ์การคืนเงินหนึ่งรายการอาจมาถึงได้สูงสุดหกครั้ง กระจายอยู่ราวหนึ่งสัปดาห์ การส่งซ้ำทุกครั้งนั้นมี notificationUUID เดียวกัน ฟิลด์นั้นคือคีย์สำหรับกำจัดรายการซ้ำของคุณ หากคุณได้บันทึก notificationUUID ไว้แล้ว การส่งที่คุณถืออยู่คือการซ้ำ และการตอบสนองที่ถูกต้องคือไม่จัดเก็บสิ่งใหม่และยังคงคืนค่า 200

Google Play ทำงานบน Pub/Sub ซึ่งสัญญาว่าอย่างน้อยหนึ่งครั้งและไม่พูดอะไรเกี่ยวกับลำดับ

Real-time Developer Notifications ของ Google Play ถูกเผยแพร่ไปยัง topic ของ Cloud Pub/Sub การรับประกันการส่งของ Pub/Sub คืออย่างน้อยหนึ่งครั้ง และไม่รับประกันลำดับเลย นั่นหมายความว่าข้อความเดียวกันอาจถูกส่งไปยัง endpoint ของคุณมากกว่าหนึ่งครั้ง และข้อความสองข้อความสำหรับการซื้อเดียวกันอาจมาถึงผิดลำดับ คำแนะนำของ Google เองชัดเจน: แกะฟิลด์ data แบบ base64 อ่าน messageId และตรวจสอบว่าคุณไม่เคยเห็นมันมาก่อนก่อนประมวลผลสิ่งใด messageId ที่ซ้ำคือการซ้ำที่คุณข้าม การแจ้งเตือนสองรายการที่ต่างกันเกี่ยวกับการซื้อเดียวควรลงบนเรกคอร์ดเดียวกัน ดังนั้นจงตั้งคีย์สถานะที่จัดเก็บของคุณบน purchaseToken ด้วย และปล่อยให้เหตุการณ์ที่มาทีหลังอัปเดตแถวที่เหตุการณ์ก่อนหน้าสร้างไว้

แพลตฟอร์ม	โมเดลการส่ง	กำจัดรายการซ้ำโดยใช้	สัญญาณความสำเร็จ	หากคุณไม่ยืนยันการรับ
App Store Server Notifications V2	สูงสุด 6 ครั้ง: ครั้งแรก บวกกับส่งซ้ำ 5 ครั้งที่ 1, 12, 24, 48, 72 ชั่วโมง	notificationUUID	HTTP 200 ถึง 206	Apple ส่งซ้ำตามตารางที่คงที่ แล้วหยุด
Google Play RTDN ผ่าน Pub/Sub	อย่างน้อยหนึ่งครั้ง ไม่รับประกันลำดับ	Pub/Sub messageId, ตั้งคีย์เอนทิตีบน purchaseToken	HTTP 200 ต่อการ push หรือ ack ที่ชัดเจน	Pub/Sub ส่งใหม่หลังหมดเวลา ack

สัญชาตญาณที่ทำลายการจัดการการคืนเงินคือการปฏิเสธรายการซ้ำด้วยการคืนค่าข้อผิดพลาด หากคุณตอบการส่งซ้ำของ Apple ด้วย 4xx เพราะคุณจัดการมันไปแล้ว Apple จะถือว่านั่นเป็นการส่งที่ล้มเหลวและยังคงส่งซ้ำต่อไปอยู่ดี จงกำจัดรายการซ้ำภายในฐานข้อมูลของคุณเองและคืนค่าสถานะสำเร็จเสมอ สโตร์ไม่ได้ถามว่าเหตุการณ์นั้นใหม่หรือไม่ มันถามว่าคุณได้รับมันหรือไม่

การซ้ำที่ไม่ใช่รายการซ้ำ

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

Apple ส่ง CONSUMPTION_REQUEST ใหม่ ไม่ใช่การส่งซ้ำ

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

ธุรกรรมเดียวสามารถนำพาการตัดสินได้มากกว่าหนึ่งครั้ง

transactionId เดียวสามารถสร้างผลลัพธ์การคืนเงินได้มากกว่าหนึ่งครั้งตลอดอายุของมัน Apple สามารถส่ง REFUND_DECLINED แล้วในภายหลังส่ง REFUND สำหรับธุรกรรมเดียวกัน และนักพัฒนารายงานว่าได้รับการแจ้งเตือนที่เกี่ยวข้องกับการคืนเงินสามรายการหรือมากกว่าสำหรับ transaction id เดียว แต่ละรายการเป็นเหตุการณ์ที่แตกต่างซึ่งมี notificationUUID ของตัวเอง หากคีย์กำจัดรายการซ้ำของคุณคือ transaction id การตัดสินครั้งที่สองจะดูเหมือนรายการซ้ำของครั้งแรกและคุณจะไม่มีวันรู้ว่าการคืนเงินได้รับการอนุมัติในที่สุด transaction id จัดกลุ่มเหตุการณ์ มันไม่ได้ระบุตัวตนของพวกมัน

แขนกลหุ่นยนต์หยิบพัสดุที่ซ้ำกันหนึ่งชิ้นออกจากสายพานลำเลียงไปยังถังด้านข้าง ภาพที่แทนการกำจัดรายการซ้ำของการแจ้งเตือนการคืนเงินที่เกิดซ้ำ

รายการซ้ำทำให้คุณเสียหายอะไรจริง ๆ

การแจ้งเตือนการคืนเงินไม่ใช่ไฟแสดงสถานะ มันกระตุ้นการกระทำจริง: คุณเพิกถอนการเข้าถึง คุณหักยอดคงเหลือแบบสิ้นเปลือง คุณกลับรายการจ่ายเงินให้ครีเอเตอร์ คุณเรียก App Store Server API หรือ Play Developer API เพื่อยืนยันสถานะ รันสิ่งใดในนั้นครั้งที่สองบนรายการซ้ำแล้วต้นทุนนั้นเป็นของจริง

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

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

รูปแบบความล้มเหลว	อะไรผิดพลาด	มันเสียค่าอะไร
หักยอดคงเหลือซ้ำบน REFUND ที่ซ้ำ	ยอดคงเหลือแบบสิ้นเปลืองของผู้ใช้ติดลบ	เวลาสนับสนุนด้วยมือเพื่อกระทบยอด และประสบการณ์ลูกค้าที่ไม่ดี
กลับรายการจ่ายเงินสองครั้ง	คุณดึงเงินที่คุณคืนไปแล้วครั้งหนึ่งกลับมา	การแก้ไขให้ครีเอเตอร์และการทำความสะอาดทางบัญชี
ประมวลผลกับ API ของสโตร์ซ้ำ	การเรียกซ้ำเผาโควตา Play Developer หรือ App Store Server API	การจำกัดอัตราระหว่างการหยุดทำงานที่ทำให้เกิดการส่งซ้ำ
กำจัดรายการซ้ำ CONSUMPTION_REQUEST มากเกินไป	คุณทิ้ง prompt การคืนเงินที่แตกต่างในฐานะรายการซ้ำปลอม	หน้าต่าง 12 ชั่วโมงที่พลาดไป ดังนั้น Apple จึงอนุมัติการคืนเงินโดยปริยาย

วิธีจัดการการแจ้งเตือนการคืนเงินที่ซ้ำกันโดยไม่ดำเนินการซ้ำ

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

กำจัดรายการซ้ำโดยใช้ delivery id ของสโตร์ ไม่ใช่ธุรกรรม ใช้ notificationUUID สำหรับ Apple และ Pub/Sub messageId สำหรับ Google Play จัดเก็บมันด้วย unique constraint เพื่อให้รายการซ้ำที่เกิดพร้อมกันแพ้การแข่งขันแทนที่จะดำเนินการซ้ำ
ทำให้การกระทำปลายทางเป็น idempotent ในเงื่อนไขของตัวเอง การตั้งคีย์บน delivery id หยุดการประมวลผลซ้ำ แต่จงเขียนผลกระทบด้วยเพื่อให้การเพิกถอน การหัก หรือการกลับรายการตรวจสอบสถานะปัจจุบันก่อนและปลอดภัยที่จะรันสองครั้ง
บันทึกก่อน แล้วจึงยืนยันการรับ เขียนเหตุการณ์ลงฐานข้อมูลของคุณก่อนที่คุณจะคืนค่า 200 หรือ ack ข้อความ Pub/Sub หากคุณ ack ก่อนแล้วการเขียนล้มเหลว สโตร์จะถือว่าข้อความถูกส่งแล้วและไม่ส่งมันอีกเลย และตอนนี้คุณสูญเสียมันไปตลอดกาล
คืนค่าสถานะสำเร็จเสมอ แม้แต่สำหรับรายการซ้ำ 200 ถึง 206 สำหรับ Apple, 200 ต่อการ push ของ Pub/Sub สำหรับ Google การปฏิเสธการซ้ำด้วยข้อผิดพลาดมีแต่จะทำให้สโตร์ส่งซ้ำ
จัดกลุ่มบนเอนทิตี ระบุตัวตนบนเหตุการณ์ ตั้งคีย์สถานะการซื้อที่จัดเก็บของคุณบน purchaseToken หรือ originalTransactionId เพื่อให้การส่งที่ผิดลำดับอัปเดตหนึ่งแถว แต่ปฏิบัติต่อ notificationUUID หรือ messageId แต่ละตัวในฐานะเหตุการณ์ของตัวเอง เพราะการซื้อหนึ่งครั้งสร้างหลายรายการได้โดยชอบธรรม

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

รายการตรวจสอบสั้น ๆ ก่อนที่คุณจะไว้ใจ webhook การคืนเงินของคุณ

การส่งของ Apple ถูกกำจัดรายการซ้ำโดยใช้ notificationUUID และการซ้ำจะไม่เขียนสิ่งใหม่แต่ยังคงคืนค่า 200
การส่งของ Google Play ถูกกำจัดรายการซ้ำโดยใช้ Pub/Sub messageId ตรวจสอบก่อนการประมวลผลใด ๆ
สถานะการซื้อตั้งคีย์บน purchaseToken หรือ originalTransactionId เพื่อให้เหตุการณ์ที่ผิดลำดับลงบนเรกคอร์ดเดียว
ผลข้างเคียงการคืนเงินทุกอย่าง ทั้งเพิกถอน หัก หรือกลับรายการ ปลอดภัยที่จะรันมากกว่าหนึ่งครั้ง
ตัวจัดการของคุณเขียนเหตุการณ์ก่อนที่มันจะยืนยันการรับ ไม่เคยหลังจากนั้น
CONSUMPTION_REQUEST ที่เกิดซ้ำถูกปฏิบัติในฐานะ prompt ที่แตกต่าง ไม่ใช่รายการซ้ำ เพื่อให้ไม่มีหน้าต่างการคืนเงินที่เปิดอยู่ถูกทิ้ง

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

คำถามที่พบบ่อย

ทำไมเซิร์ฟเวอร์ของฉันจึงได้รับการแจ้งเตือนการคืนเงินของ App Store เดียวกันมากกว่าหนึ่งครั้ง?: เพราะ Apple ส่ง App Store Server Notification V2 ซ้ำได้สูงสุดห้าครั้ง ที่ 1, 12, 24, 48 และ 72 ชั่วโมงหลังความพยายามครั้งล่าสุด เมื่อใดก็ตามที่เซิร์ฟเวอร์ของคุณไม่ตอบด้วยสถานะ HTTP ระหว่าง 200 ถึง 206 การส่งซ้ำทุกครั้งมี notificationUUID เดียวกัน คุณจึงจดจำและข้ามมันได้
ฉันควรใช้ฟิลด์ใดเพื่อกำจัดรายการซ้ำของ App Store Server Notifications?: ใช้ notificationUUID การส่งซ้ำจริงจะทำซ้ำ notificationUUID เดียวกันเสมอ ในขณะที่ทุกเหตุการณ์ที่ใหม่จริง ๆ รวมถึง CONSUMPTION_REQUEST ใหม่แต่ละรายการ จะได้ค่าที่ต่างกัน ดังนั้นการกำจัดรายการซ้ำโดยใช้ notificationUUID จึงข้ามการซ้ำโดยไม่ทิ้งเหตุการณ์ที่แตกต่าง
การแจ้งเตือน CONSUMPTION_REQUEST ที่เกิดซ้ำเป็นรายการซ้ำที่ฉันควรเพิกเฉยหรือไม่?: ไม่ Apple ส่งการแจ้งเตือน CONSUMPTION_REQUEST ใหม่เป็นระยะตลอดหน้าต่างการคืนเงินที่เปิดอยู่ และเจ้าหน้าที่ของ Apple ยืนยันว่าสิ่งเหล่านี้ไม่ใช่การส่งซ้ำ แต่ละรายการมี notificationUUID ของตัวเอง ดังนั้นจงประมวลผลทุกรายการ การทิ้งพวกมันเสี่ยงต่อการพลาดหน้าต่าง 12 ชั่วโมงที่ Apple ให้คุณเพื่อตอบ
ฉันจะกำจัดรายการซ้ำของ Google Play Real-time Developer Notifications อย่างไร?: อ่าน Pub/Sub messageId จากการแจ้งเตือนแต่ละรายการและตรวจสอบกับรายการที่คุณประมวลผลไปแล้วก่อนดำเนินการ เพราะ Pub/Sub ส่งอย่างน้อยหนึ่งครั้งและสามารถส่งข้อความเดียวกันได้มากกว่าหนึ่งครั้ง Google แนะนำสิ่งนี้อย่างชัดเจนเพื่อหลีกเลี่ยงการประมวลผลซ้ำและการสิ้นเปลืองโควตา API
ฉันควรคืนค่าข้อผิดพลาดเพื่อปฏิเสธการแจ้งเตือนการคืนเงินที่ซ้ำหรือไม่?: ไม่ การคืนค่า 4xx หรือ 5xx บอกสโตร์ว่าการส่งล้มเหลว มันจึงส่งซ้ำอยู่ดี จงกำจัดรายการซ้ำภายในฐานข้อมูลของคุณเองและคืนค่าสถานะสำเร็จเสมอ HTTP 200 ถึง 206 สำหรับ Apple หรือการยืนยัน 200 สำหรับการ push ของ Google Play

แหล่งข้อมูลและเนื้อหาเพิ่มเติม

RefundHalt

ระบบอัตโนมัติสำหรับการคืนเงินบน App Store และ Google Play

อ่านต่อ

Deep diveใช้เวลาอ่าน 8 นาที

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

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

Playbookใช้เวลาอ่าน 8 นาที

การจัดการคืนเงินพังอย่างเงียบๆ ดังนั้นจงทดสอบการคืนเงินการซื้อในแอปในแซนด์บ็อกซ์ก่อนที่ลูกค้าจริงจะทำ

การจัดการคืนเงินของคุณทำงานหลังจากลูกค้าจากไปแล้วเท่านั้น ดังนั้นบั๊กในนั้นจึงมองไม่เห็นจนกว่าจะทำให้เสียเงินจริง ทั้งสองสโตร์ให้คุณกระตุ้นการคืนเงินในสภาพแวดล้อมทดสอบก่อนได้ นี่คือวิธีทดสอบการคืนเงินการซื้อในแอปบน App Store และ Google Play ก่อนที่ครั้งใดครั้งหนึ่งจะเป็นเรื่องจริง