Send Consumption Information ของ Apple ตอนนี้ขอ 5 ฟิลด์ ไม่ใช่ 12 และนี่คือแต่ละฟิลด์

รายการข้อเท็จจริงที่ Apple ขอจากคุณเมื่อลูกค้าต้องการเงินคืนสั้นลงมาก payload ของ Send Consumption Information ซึ่งเป็นคำตอบเดียวที่นักพัฒนาได้ส่งเข้าไปในการตัดสินใจคืนเงินของ App Store เคยมี 12 ฟิลด์ ตอนนี้เหลือ 5 Apple ตัดทอนมันราวช่วง WWDC24 และยุบคำถามเกี่ยวกับการทำโปรไฟล์บัญชีแบบเดิมส่วนใหญ่ให้เหลือคำถามง่าย ๆ สองข้อกับตัวเลขหนึ่งตัว ฟิลด์ที่น้อยลงไม่ใช่การแก้ไขเล็ก ๆ มันเปลี่ยนหลักฐานที่ Apple ชั่งน้ำหนัก และเปลี่ยนฟิลด์ที่คุณกรอกผิดไม่ได้

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

Send Consumption Information คืออะไร

Send Consumption Information คือ endpoint ของ App Store Server API ที่คุณเรียกหลังจาก Apple ส่งการแจ้งเตือน CONSUMPTION_REQUEST มายังเซิร์ฟเวอร์ของคุณ การแจ้งเตือนนั้นหมายความว่าลูกค้าขอเงินคืนสำหรับการซื้อในแอปจาก Apple และ Apple ต้องการความเห็นของคุณก่อนตัดสินใจ คุณตอบด้วยการ PUT body JSON ขนาดเล็ก คือ ConsumptionRequest ไปยัง endpoint นั้น Apple อ่านมัน ชั่งน้ำหนักกับประวัติของลูกค้า แล้วตัดสินใจ คุณไม่เคยเป็นผู้ตัดสินการคืนเงิน คุณเป็นผู้ให้ข้อเท็จจริง

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

ห้าฟิลด์ที่ Apple ขอในตอนนี้

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

customerConsented คือประตูด่านแรก

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

deliveryStatus คือฟิลด์ที่ขับเคลื่อนการคืนเงิน

deliveryStatus เป็น enum แบบ string และเป็นคานงัดที่หนักแน่นที่สุดที่คุณมี มันบอก Apple ว่าแอปของคุณได้ส่งมอบการซื้อในแอปที่ใช้งานได้จริงหรือไม่ ค่าหนึ่งบอกว่าใช่ อีกสี่ค่าบอกว่าไม่ แต่ละค่าด้วยเหตุผลต่างกัน และแต่ละค่าบอก Apple ว่าลูกค้ามีข้อร้องเรียนที่ชอบธรรม

sampleContentProvided ตอบคำถามเรื่องความเป็นธรรม

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

consumptionPercentage ตอนนี้เป็นตัวเลข ไม่ใช่สถานะ

นี่คือฟิลด์ที่เปลี่ยนแปลงมากที่สุด payload เดิมมี consumptionStatus ซึ่งเป็น enum สี่ขั้น ได้แก่ UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED payload ใหม่แทนที่มันด้วย consumptionPercentage ซึ่งเป็นจำนวนเต็ม integer วัดในหน่วย milliunits 100,000 milliunits หมายถึงใช้สินค้าไปจนหมด ดังนั้น 50,000 คือครึ่งหนึ่งและ 0 คือยังไม่แตะต้อง ตัวเลขที่แม่นยำดีกว่าการแบ่งเป็นสี่ช่อง เพราะมันให้คุณบอกได้ว่าลูกค้าใช้เครดิตแพ็กไป 90 เปอร์เซ็นต์ แทนที่จะปัดลงเป็น partially consumed

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

refundPreference บอกความต้องการ ไม่ใช่คำพิพากษา

refundPreference เป็น string ที่ไม่บังคับ และเป็นที่ที่คุณบอก Apple ว่าคุณต้องการผลลัพธ์แบบใด มันเปลี่ยนรูปแบบด้วยเช่นกัน ฟิลด์เดิมเป็นตัวเลขที่มีค่าอย่าง prefer-grant, prefer-decline และ no-preference ฟิลด์ใหม่เป็น string ที่มีชื่อพร้อมสามค่า

Apple ตัดอะไรออก และทำไมจึงสำคัญ

ConsumptionRequest เดิมมี 12 ฟิลด์ เจ็ดในนั้นหายไปจากสิ่งที่คุณส่ง accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform และ appAccountToken คือครึ่งหนึ่งของ payload ที่เป็นการทำโปรไฟล์บัญชี ฟิลด์ที่ขอให้คุณจัดกลุ่มลูกค้าตามระยะเวลาที่มีบัญชี ใช้จ่ายไปเท่าใด ได้รับเงินคืนไปเท่าใด และใช้แอปมานานเท่าใด

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

endpoint และนาฬิกา

คุณส่ง payload ด้วย HTTP PUT ไปยัง endpoint ของ Send Consumption Information โดยอ้างอิงตาม transaction id ของการซื้อที่เป็นข้อพิพาท PUT /inApps/v1/transactions/consumption/{transactionId} เมื่อสำเร็จจะได้ 202 Accepted และ body ของการตอบกลับว่างเปล่า คำตอบว่างนั้นเป็นสิ่งที่คาดไว้ ไม่ใช่บั๊ก มันยืนยันว่า Apple เข้าคิวข้อมูลของคุณแล้ว และไม่ได้บอกอะไรเกี่ยวกับผลลัพธ์สุดท้าย ซึ่งจะมาถึงในภายหลังเป็นการแจ้งเตือน REFUND หรือ REFUND_DECLINED

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

ฟิลด์ที่จัดการผิดพลาดทำให้คุณเสียอะไร

เงินออกจากบ้านไปก่อนที่การคืนเงินจะเกิดขึ้น

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

ห้าฟิลด์คือวิธีที่คุณเลี่ยงการจ่ายสองครั้ง

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

chargeback คือประตูที่แย่กว่า และความเงียบชี้ไปที่มัน

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

RefundHalt จัดการเรื่องนี้อย่างไร

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