การแจ้งเตือนการคืนเงินของ App Store สามรายการจะมาถึงหลังจาก Apple ตัดสิน และ REFUND_REVERSED จะคืนยอดขายกลับมาให้

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

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

การแจ้งเตือนการคืนเงินสี่รายการ และรายการใดที่ต้องการการตอบกลับ

App Store Server Notifications V2 เป็นฟีดเดียว คุณชี้มันไปที่ URL เดียวและ Apple ส่งการแจ้งเตือนทุกประเภทไปที่นั่น ดังนั้นคุณจึงได้รับข้อความคืนเงินทั้งสี่รายการอยู่แล้วไม่ว่าคุณจะจัดการหรือไม่ก็ตาม สี่ประเภทเกี่ยวข้องกับการคืนเงิน และมีเพียงหนึ่งเดียวที่เป็นคำถาม

การแจ้งเตือน REFUND บอกอะไรคุณจริง ๆ

REFUND ทำงานเมื่อ App Store คืนเงินธุรกรรมให้ลูกค้าสำเร็จ มันใช้กับทุกประเภทการซื้อ: consumable, non-consumable, การสมัครสมาชิกแบบ auto-renewable และการสมัครสมาชิกแบบ non-renewing ธุรกรรมที่ลงนามภายในการแจ้งเตือนตอนนี้มีสองฟิลด์ที่ไม่มีมาก่อนการคืนเงิน และสองฟิลด์นั้นคือเรื่องราวทั้งหมด

revocationDate และ revocationReason บรรจุข้อเท็จจริง

revocationDate คือเวลา UNIX ในหน่วยมิลลิวินาที ที่ App Store คืนเงินธุรกรรมหรือเพิกถอนมัน revocationReason บอกหมวดหมู่ของการคืนเงินแก่คุณ และมีค่าเพียงสองค่าเท่านั้น

การมี revocationDate อยู่บนธุรกรรมก็เป็นธงในตัวเอง หากคุณดึงธุรกรรมมาในภายหลังและมันมี revocationDate การซื้อนั้นได้ถูกคืนเงินแล้ว ไม่ว่าจะมีการแจ้งเตือนหรือไม่ อ่านเหตุผลควบคู่ไปด้วยเพื่อไม่ให้คลื่นการคืนเงินค่า 1 บนรีลีสเดียวเล็ดลอดผ่านคุณไปในฐานะเสียงรบกวน

เพิกถอนตามธุรกรรม ไม่ใช่ตามผลิตภัณฑ์

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

REFUND_DECLINED หมายความว่าคุณชนะแล้ว ดังนั้นอย่าย้อนกลับ

REFUND_DECLINED มาถึงเมื่อ App Store ปฏิเสธคำขอคืนเงินของลูกค้า ลูกค้าขอ Apple ปฏิเสธ และคุณเก็บยอดขายไว้ เมื่อดูผิวเผินไม่มีอะไรต้องทำ และนั่นคือประเด็น ความผิดพลาดที่การแจ้งเตือนนี้เปิดเผยเป็นอีกเรื่องหนึ่ง: การเพิกถอนการเข้าถึงเร็วเกินไป

หากโค้ดของคุณตอบสนองต่อ CONSUMPTION_REQUEST ด้วยการดึงการเข้าถึงของลูกค้าก่อนที่ Apple จะตัดสิน REFUND_DECLINED คือช่วงเวลาที่การตัดสินใจนั้นระเบิด Apple เก็บเงินของคุณไว้ และคุณล็อกลูกค้าที่การคืนเงินถูกปฏิเสธออกไป ลูกค้ารายนั้นตอนนี้จ่ายเงินสำหรับผลิตภัณฑ์ที่ใช้ไม่ได้ เปิดตั๋วสนับสนุน และจดจำมันไว้ วิธีแก้คือกฎ ไม่ใช่ฟีเจอร์: เพิกถอนที่ REFUND ไม่ใช่ที่คำขอ REFUND_DECLINED เป็นเพียงการยืนยันของ Apple ว่าการเพิกถอนเร็วเกินไปคงเป็นการตัดสินใจที่ผิด

REFUND_REVERSED คือการแจ้งเตือนที่จ่ายเงินคืนให้คุณ

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

ปัญหาหลายสัปดาห์ต่อมา

คำถามจริงที่นักพัฒนายกขึ้น บนฟอรัมของ Apple เอง คือเรื่องเวลา REFUND_REVERSED อาจมาถึงหลายสัปดาห์หลังจาก REFUND เดิม นานหลังจากรอบการสมัครสมาชิกหมดอายุ คุณจะคืนการเข้าถึงตอนนั้นหรือไม่ คืนสิ่งที่ธุรกรรมมอบให้จริง โดยจำกัดขอบเขตไว้ที่สิ่งที่ธุรกรรมนั้นครอบคลุม สำหรับ consumable หรือ non-consumable ให้เปิดการปลดล็อกกลับ สำหรับรอบการสมัครสมาชิกที่ผ่านไปแล้ว คุณไม่ได้แจกเวลาใหม่ คุณกำลังแก้ไขบันทึกเพื่อให้ประวัติของลูกค้าถูกต้องและสิทธิ์ใด ๆ ที่ยังใช้ได้กลับมาทำงานอีกครั้ง คืนธุรกรรมเฉพาะรายการ และตรรกะการทับซ้อนของคุณจะตัดสินว่าอะไรใช้งานอยู่ในปัจจุบัน

เงินอยู่ตรงไหนในการทำเรื่องนี้ให้ถูกต้อง

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

REFUND: หยุดจ่ายเพื่อให้บริการลูกค้าที่ได้รับเงินคืนแล้ว

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

REFUND_DECLINED: อย่าเปลี่ยนชัยชนะให้กลายเป็นการคืนเงินด้วยความปรารถนาดี

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

REFUND_REVERSED: การจับคู่ที่แย่ที่สุดคือทั้งเงินและการเข้าถึงของพวกเขาหายไปทั้งคู่

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

สิ่งที่ต้องตั้งค่า

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

สำหรับช่องว่างที่การแจ้งเตือนทิ้งไว้ ให้ใช้จุดสิ้นสุด Get Refund History หากเซิร์ฟเวอร์ของคุณล่มระหว่างการหยุดทำงานและพลาด REFUND ไป ให้เรียกการค้นหาการคืนเงินของ App Store Server API สำหรับ transaction id ที่ /inApps/v2/refund/lookup/{transactionId} และอ่านธุรกรรมที่ลงนามพร้อม revocationDate และ revocationReason ของมันกลับมา มันกระทบยอดทีละธุรกรรมและไล่หน้าไปตามการซื้อที่คืนเงินแล้วของลูกค้า ดังนั้น webhook ที่พลาดไปจะไม่กลายเป็นสิทธิ์ที่ตั้งค่าผิดอย่างถาวร

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