การใช้การคืนเงินในทางที่ผิดซ้ำ ๆ ทำให้คุณเสียสองต่อ นี่คือวิธีที่สโตร์เปิดทางให้คุณตอบโต้

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

ทำไมการใช้การคืนเงินในทางที่ผิดจึงเป็นปัญหาเรื่องตัวตน ไม่ใช่ปัญหาเรื่องการคืนเงิน

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

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

สองหน้าต่างเวลาที่หลักฐานเปลี่ยนผลลัพธ์ได้

มีเพียงสอง flow เท่านั้นที่สิ่งที่คุณส่งไปสามารถเขย่าคำตัดสินได้ CONSUMPTION_REQUEST ของ Apple จะถูกทริกเกอร์เมื่อลูกค้าขอคืนเงินสำหรับสินค้าที่บริโภคได้ (consumable) หรือ subscription แบบต่ออายุอัตโนมัติ และคุณมีเวลา 12 ชั่วโมงในการตอบ การตรวจสอบ chargeback ของ Google Play จะถูกทริกเกอร์เมื่อผู้ใช้โต้แย้งรายการเรียกเก็บเงินกับธนาคาร และคุณมีเวลา 24 ชั่วโมงในการตอบผ่าน Review Refund API ส่วนการคืนเงินอื่นทุกแบบ ไม่ว่าจะเป็นการคืนเงินแบบบริการตนเองของ Play ภายใน 48 ชั่วโมง การคืนเงินที่ฝ่ายสนับสนุนอนุมัติ หรือการคืนเงินอัตโนมัติของการซื้อที่ไม่ได้ยืนยัน ล้วนถูกตัดสินโดยไม่มีคุณ

ช่องทางหลักฐานทั้งสองนี้จะแข็งแกร่งกว่ามากเมื่อ transaction พกพาตัวระบุของคุณไว้แล้ว consumption information ของ Apple สามารถรวม appAccountToken เข้าไว้พร้อมกับประวัติและยอดใช้จ่ายของบัญชี และการตรวจสอบของ Google สามารถอาศัย obfuscated account ID ที่มันเฝ้าดูมาตั้งแต่การซื้อ บัญชีที่ไม่มีตัวระบุคือบัญชีที่ไม่มีประวัติให้ส่ง

สองฟิลด์ระบุตัวตน เทียบเคียงกัน

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

Apple: appAccountToken

appAccountToken คือ UUID ที่คุณสร้างและส่งเข้าไปเมื่อการซื้อเริ่มต้น StoreKit จะเชื่อมโยงมันเข้ากับ transaction ที่เกิดขึ้น และมันจะปรากฏในข้อมูล transaction ที่เซิร์ฟเวอร์ของคุณตรวจสอบ และใน consumption information ที่คุณส่งกลับระหว่าง CONSUMPTION_REQUEST เนื่องจากมันเป็นค่าของคุณ มันจึงแมป transaction ของสโตร์เข้ากับบัญชีในฐานข้อมูลของคุณโดยตรง โดยไม่มีอีเมลหรือชื่อเข้ามาเกี่ยวข้อง มันต้องเป็น UUID จริง ๆ และอย่างอื่นจะถูกปฏิเสธ ภายหลัง Apple ได้เพิ่ม endpoint ที่ชื่อ Set App Account Token ซึ่งสามารถแนบหรืออัปเดต token บน transaction ในอดีตได้ รวมถึงการซื้อที่ทำนอกแอปของคุณ เช่น การแลกโค้ดข้อเสนอ

Google Play: obfuscated account ID

สิ่งที่เทียบเท่าของ Google คือ setObfuscatedAccountId ซึ่งเป็นสตริงเสริมที่ผูกกับบัญชีผู้ซื้อ เอกสารของ Google เองพูดตรง ๆ ถึงวัตถุประสงค์ของมัน นั่นคือ Google Play ใช้มันเพื่อตรวจจับกิจกรรมผิดปกติ เช่น อุปกรณ์จำนวนมากทำการซื้อบนบัญชีเดียวกันภายในช่วงเวลาสั้น ๆ และเพื่อบล็อกธุรกรรมฉ้อโกงบางส่วนก่อนที่มันจะเสร็จสมบูรณ์ มันจำกัดไม่เกิน 64 ตัวอักษร และต้องไม่พกพาข้อมูลส่วนบุคคลแบบข้อความธรรมดา (cleartext) หากคุณเก็บอีเมลดิบไว้ตรงนั้น Google จะบล็อกการซื้อทันที เพราะฟิลด์นี้คาดหวังค่าที่ถูกเข้ารหัสหรือ hash แบบทางเดียว ยังมีฟิลด์พี่น้องคือ setObfuscatedProfileId สำหรับแอปที่บัญชีหนึ่งถือหลายโปรไฟล์

การคืนเงินจากผู้ใช้ในทางที่ผิดซ้ำ ๆ มีต้นทุนจริงเท่าใด

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

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

จากนั้นก็มีการโยกย้ายต้นทุนของสโตร์เอง ตั้งแต่ August 3, 2026 เป็นต้นไป Google Play จะโยกราคาซื้อและค่าธรรมเนียม chargeback ของธนาคารมาให้นักพัฒนาสำหรับคำสั่งซื้อที่วางหลังวันดังกล่าว chargeback ที่เคยเป็นปัญหาของ Google เป็นส่วนใหญ่จะกลายเป็นรายได้ของคุณบวกค่าธรรมเนียม และผู้โต้แย้งซ้ำ ๆ จะเพิ่มตัวเลขนั้นทุกครั้ง ฟิลด์ระบุตัวตนคือสิ่งที่ยอมให้คุณป้อนหลักฐานให้ Review Refund API เพื่อโต้แย้งข้อพิพาทที่ไม่ชอบด้วยกฎภายในหน้าต่างเวลา 24 ชั่วโมง

Google อธิบายขนาดของมันอย่างตรงไปตรงมา โดยระบุว่าได้บล็อกธุรกรรมฉ้อโกงและใช้ในทางที่ผิดไปกว่า $2 billion ในปี 2022 ตัวเลขนั้นมีอยู่ได้เพราะสัญญาณต่าง ๆ ซึ่งรวมถึง obfuscated account ID ถูกกรอกไว้ แอปที่ส่งการซื้อออกไปพร้อมฟิลด์ระบุตัวตนที่ว่างเปล่าก็เท่ากับเลือกที่จะไม่รับการป้องกันนั้น

วิธีจับผู้คืนเงินซ้ำ ๆ ก่อนที่สโตร์จะตัดสิน

ติดแท็กทุกการซื้อด้วยตัวตนที่คุณเป็นเจ้าของ

ตั้งค่า appAccountToken บนทุกการซื้อผ่าน StoreKit และ setObfuscatedAccountId บนทุกการซื้อผ่าน Play Billing โดยทั้งคู่สร้างขึ้นจากบันทึกผู้ใช้ของคุณเอง บน Apple ให้ใช้ UUID จริงที่แมปกับบัญชี บน Google ให้ hash คีย์บัญชีเพื่อไม่ให้ข้อมูลส่วนบุคคลเดินทางในรูปข้อความธรรมดา ทำสิ่งนี้ตอนซื้อ เพราะบน Google มันเป็นขั้นตอนเดียวที่คุณกู้คืนภายหลังไม่ได้

เก็บบัญชีแยกประเภทที่ใช้ตัวตนนั้นเป็นคีย์

จัดเก็บทุกการซื้อ การส่งมอบ เหตุการณ์การบริโภค และการคืนเงินไว้เทียบกับตัวระบุ เมื่อ CONSUMPTION_REQUEST หรือการตรวจสอบ chargeback มาถึง ประวัติทั้งหมดของบัญชี รวมถึงการคืนเงินก่อนหน้า ก็อยู่ห่างเพียงการค้นหาครั้งเดียว consumption information ของ Apple มีฟิลด์ที่ชัดเจนสำหรับสิ่งนี้โดยเฉพาะ ได้แก่ consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased และ refundPreference ของคุณ

อ่าน voidedReason และจัดเส้นทางผู้ใช้ในทางที่ผิดให้ต่างออกไป

เมื่อการซื้อของ Google ถูกยกเลิก (voided) ฟิลด์ voidedReason จะบอกคุณว่าทำไม และ friendly_fraud กับ fraud เป็นค่าที่แยกจากการคืนเงินเพราะเสียดาย (remorse) ทั่วไป ให้ส่งพวกนั้นไปยังคิวตรวจสอบและนโยบายที่เข้มงวดกว่า ไม่ใช่เส้นทางอัตโนมัติเดียวกับการคืนเงินครั้งแรก แนวทางของ Google เองเป็นโมเดลแบบเตือนหลายครั้ง นั่นคือ เตือนผู้กระทำผิดครั้งแรก ดำเนินการเด็ดขาดขึ้นกับผู้ที่ทำซ้ำ และปิดการซื้อสำหรับบัญชีที่ยังทำต่อไปเรื่อย ๆ

ตอบภายในหน้าต่างเวลาทุกครั้ง

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

สิ่งที่สโตร์จะทำและจะไม่ทำให้คุณ

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

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