คู่มือฉบับสมบูรณ์สำหรับการอัปเดตและใช้งาน Google Play Billing Library เวอร์ชัน 7

หากคุณทำงานเกี่ยวกับการซื้อภายในแอปบน Android ไม่ช้าก็เร็วคุณจะต้องเจอกับปัญหานี้ Google Play Billing Library เวอร์ชัน 7นี่ไม่ใช่แค่การอัปเดตธรรมดา: มันมาพร้อมกับการเปลี่ยนแปลง API ฟีเจอร์การสมัครสมาชิกใหม่ ข้อกำหนดสำหรับคอนโซล และกำหนดเวลาที่ชัดเจนจาก Google การเพิกเฉยต่อการอัปเดตนี้จึงไม่ใช่ทางเลือกอีกต่อไป หากคุณต้องการเผยแพร่หรืออัปเดตแอปของคุณบน Google Play โดยไม่มีปัญหาใดๆ เกิดขึ้น

ตลอดบทความนี้คุณจะเห็นว่า อัปเดตและใช้งาน Google Play Billing Library เวอร์ชัน 7 ทีละขั้นตอน: ตั้งแต่ความแตกต่างระหว่าง PBL 5 และ 6 ไปจนถึงวิธีการผสานรวมการสมัครสมาชิก การซื้อครั้งเดียว RTDN การทดสอบด้วย Play Billing Lab และวิธีการเอาตัวรอดในระบบนิเวศอย่าง .NET MAUI ที่การสนับสนุนอย่างเป็นทางการยังไม่ดีพอ แนวคิดก็คือ เมื่อคุณอ่านจบ คุณจะสามารถเตรียมการย้ายระบบได้อย่างมั่นใจและไม่ต้องเสียเงินสักบาท

ภาพรวมของ Google Play Billing Library เวอร์ชัน 7

Google Play Billing Library เวอร์ชัน 7 นำเสนอการปรับปรุงที่สำคัญในการจัดการบิลต่างๆ การชำระเงิน การสมัครสมาชิก และแพ็กเกจพิเศษอย่างไรก็ตาม ระบบนี้ถูกออกแบบมาเพื่อให้การย้ายระบบเป็นไปอย่างราบรื่น ข่าวดีก็คือ API ใหม่หลายตัวเป็นตัวเลือกเสริม: คุณสามารถอัปเดตการพึ่งพา ปรับแต่งการอ้างอิงเล็กน้อย และการทำงานร่วมกันพื้นฐานของคุณจะยังคงใช้งานได้

เวอร์ชันนี้เน้นในสามประเด็นหลัก: ตัวเลือกการสมัครสมาชิกใหม่ (เช่น โควต้าเสมือน) การสนับสนุนที่ดีขึ้นสำหรับ การซื้อที่รอดำเนินการในแพ็กเกจแบบเติมเงินและมีการเปลี่ยนแปลง API ที่แก้ไขสิ่งที่ล้าสมัยไปแล้วในเวอร์ชันก่อนหน้า (PBL 5 และ 6) นอกจากนี้ Google ยังปรับการจัดการข้อผิดพลาดและวิธีการจัดการธุรกรรมที่รอดดำเนินการเพื่อหลีกเลี่ยงความไม่สอดคล้องกัน

ขั้นแรก ในโมดูลแอปของคุณ คุณต้องอัปเดตการพึ่งพาในไฟล์ของคุณ build.gradle:

dependencies {
    def billingVersion = "7.0.0"
    implementation "com.android.billingclient:billing:$billingVersion"
}

เมื่อทำขั้นตอนนี้เสร็จแล้ว ก็ถึงเวลาตรวจสอบโค้ดที่ใช้ API รุ่นเก่า มีการเรียกใช้งานหลายอย่างที่เกี่ยวข้องกับ... การคิดค่าบริการตามสัดส่วนการสมัครสมาชิกและการเรียกเก็บเงินแบบอื่น ไฟล์เหล่านั้นถูกเปลี่ยนชื่อหรือลบออกไปแล้ว ดังนั้นจึงควรตรวจสอบการอ้างอิงถึง BillingClient และ BillingFlowParams อย่างละเอียดก่อนที่จะคอมไพล์และอัปโหลดอะไรก็ตามไปยัง Play Console

กลยุทธ์การสร้างรายได้ด้วยการซื้อครั้งเดียวและการสมัครสมาชิก

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

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

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

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

การผสานรวมเข้ากับแอปพลิเคชันเป็นเพียงครึ่งหนึ่งของงานเท่านั้น: เซิร์ฟเวอร์ของคุณต้องดูแลรักษาข้อมูลด้วย บันทึกที่เชื่อถือได้เกี่ยวกับสิทธิ์และสถานะการซื้อสิ่งนี้สำคัญอย่างยิ่งหากคุณให้บริการเข้าถึงข้ามแพลตฟอร์ม หรือต้องการสถิติโดยละเอียดเกี่ยวกับรายได้ การรักษาฐานลูกค้า และอัตราการเลิกใช้บริการ นี่คือจุดที่การแจ้งเตือนแบบเรียลไทม์สำหรับนักพัฒนา (RTDN) เข้ามามีบทบาท โดยทำหน้าที่เป็น "กล่องดำ" ของวงจรการซื้อ

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

การแจ้งเตือนนักพัฒนาแบบเรียลไทม์ (RTDN) และ Google Cloud Pub/Sub

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

ขั้นตอนพื้นฐานนั้นง่ายมาก: Google Play ส่งข้อความที่เข้ารหัสแบบ base64 ไปยังหัวข้อ Pub/Sub ผู้รับข้อมูลของคุณจะดึงข้อความนั้นออกมา ถอดรหัส และประมวลผลการแจ้งเตือน ภายในฟิลด์นั้น data ภายในข้อความนั้น คุณจะพบออบเจ็กต์ JSON การแจ้งเตือนนักพัฒนาซึ่งรวมถึงข้อมูลต่างๆ เช่น เวอร์ชันของข้อความ ชื่อแพ็กเกจ เวลาของเหตุการณ์ และข้อมูลเฉพาะเกี่ยวกับการซื้อครั้งเดียว การสมัครสมาชิก การยกเลิกการซื้อ หรือการทดลองใช้

{
  "version": string,
  "packageName": string,
  "eventTimeMillis": long,
  "oneTimeProductNotification": OneTimeProductNotification,
  "subscriptionNotification": SubscriptionNotification,
  "voidedPurchaseNotification": VoidedPurchaseNotification,
  "testNotification": TestNotification
}

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

การกำหนดค่า Cloud Pub/Sub สำหรับ RTDN

ก่อนที่จะเปิดใช้งาน RTDN ใน Google Play Console คุณต้องเตรียมโปรเจ็กต์ไว้ก่อน Google คลาวด์แพลตฟอร์ม (GCP) และกำหนดค่า Pub/Sub ที่นั่น กระบวนการค่อนข้างตรงไปตรงมา แต่ควรปฏิบัติตามอย่างระมัดระวังเพื่อหลีกเลี่ยงปัญหาเรื่องสิทธิ์หรือชื่อทรัพยากรที่ไม่คาดคิด

การสร้างหัวข้อ

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

projects/{project_id}/topics/{topic_name}

ชื่อเต็มนั้นคือชื่อที่คุณจะต้องคัดลอกไปวางใน Play Console เมื่อคุณเปิดใช้งานการแจ้งเตือน

การสร้างการสมัครสมาชิก

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

คุณควรตรวจสอบตัวเลือกต่างๆ ในคู่มือผู้สมัครรับข้อมูล Cloud Pub/Sub เพื่อตัดสินใจว่าการส่งข้อมูลแบบ Push หรือ Pull เหมาะสมกับสถาปัตยกรรมของคุณมากกว่ากัน เมื่อคุณตัดสินใจแล้ว ให้ทำตามเอกสาร "เพิ่มการสมัครรับข้อมูล" และเชื่อมโยงเข้ากับหัวข้อที่คุณสร้างไว้ก่อนหน้านี้ จากนั้นเป็นต้นไป ข้อความใดๆ ที่ Google Play เผยแพร่ในหัวข้อดังกล่าวจะสามารถเข้าถึงได้โดยผู้สมัครรับข้อมูลของคุณ

การอนุญาตให้ Google Play เผยแพร่ไปยังธีมของคุณ

Pub/Sub จะไม่อนุญาตให้ Google Play เผยแพร่สิ่งใดๆ เว้นแต่คุณจะให้การอนุญาตอย่างชัดเจน บัญชีบริการในคอนโซล Google Cloud คุณต้องไปที่การตั้งค่าสิทธิ์ของหัวข้อ และเพิ่มสิทธิ์หลัก:

google-play-developer-notifications@system.gserviceaccount.com

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

เปิดใช้งาน RTDN ใน Google Play Console

เมื่อตั้งค่า Pub/Sub เสร็จแล้ว คุณต้องบอก Play Console ว่าจะส่งการแจ้งเตือนไปที่ใด ในแอปของคุณใน Google Play Console ให้ไปที่ สร้างรายได้ด้วย Play > การตั้งค่าการสร้างรายได้ และค้นหาส่วนการแจ้งเตือนสำหรับนักพัฒนาแบบเรียลไทม์

ที่นั่นคุณจะต้องทำสิ่งต่อไปนี้:

• ทำเครื่องหมายในช่องเพื่อเปิดใช้งานการแจ้งเตือนแบบเรียลไทม์
• กรอกชื่อหัวข้อ Pub/Sub แบบเต็มในช่องที่เกี่ยวข้อง โดยต้องเป็นไปตามรูปแบบที่กำหนด projects/{project_id}/topics/{topic_name}.
• ส่งข้อความทดสอบโดยใช้ปุ่มทดสอบ

ข้อความทดสอบมีความสำคัญอย่างยิ่งในการตรวจสอบว่า การบูรณาการได้รับการดำเนินการอย่างดีหากคุณมีการสมัครรับข้อมูลแบบดึงข้อมูล (pull subscription) คุณสามารถไปที่คอนโซล Cloud เลือกการสมัครรับข้อมูล คลิก "ดูข้อความ" และดึงข้อความทดสอบออกมาได้ อย่าลืมทำตามขั้นตอนต่อไปนี้ แอ๊ เพื่อป้องกันการรับข้อความซ้ำซ้อนทุกครั้งที่คุณอ่าน

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

บทความที่เกี่ยวข้อง:

คู่มือฉบับสมบูรณ์ในการสมัครทดลองใช้งานแอปบน Google Play Store และการเข้าถึงเวอร์ชันเบต้า การเข้าใช้งานล่วงหน้า และการทดลองใช้ฟรี

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

สร้างตัวรับข้อมูลแบบ Pub/Sub ในส่วนแบ็กเอนด์ของคุณ

เมื่อเตรียมธีมและการสมัครสมาชิกเรียบร้อยแล้ว ก็ถึงเวลาลงมือใช้งาน สมาชิกที่อ่านและประมวลผล RTDNGoogle มีตัวอย่างในหลายภาษา ตัวอย่างทั่วไปในภาษา Java คือการใช้ไลบรารีไคลเอ็นต์ Cloud Pub/Sub เพื่อเริ่มต้นการทำงาน Subscriber ผู้ที่ฟังข้อความและโทรออก MessageReceiver.

รูปแบบโดยทั่วไปจะเหมือนกันเสมอ: คุณดึงข้อความออกมา แล้วถอดรหัสฟิลด์นั้น data คุณแปลง base64 เป็นข้อความ วิเคราะห์ JSON และแยกฟิลด์ที่เกี่ยวข้องออกมา (เช่น packageName, oneTimeProductNotification o subscriptionNotification) และตัดสินใจว่าจะดำเนินการอย่างไรในระบบของคุณ หลังจากประมวลผลการแจ้งเตือนสำเร็จแล้ว คุณต้อง ยืนยันข้อความด้วยการกด ack เพื่อไม่ให้ Pub/Sub ส่งข้อความนั้นซ้ำอีก

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

เชื่อมโยงการแจ้งเตือนไปยังผู้ใช้: โดยใช้ obfuscatedAccountId

ปัญหาทั่วไปในการจัดการการซื้อจากเซิร์ฟเวอร์คือ การทราบว่าการแจ้งเตือน RTDN นั้นเป็นของผู้ใช้รายใด สำหรับเรื่องนี้ API ของ Billing Client อนุญาตให้คุณแนบข้อมูลได้ ตัวระบุบัญชีที่ถูกปกปิด เมื่อคุณเริ่มขั้นตอนการสั่งซื้อ: obfuscatedAccountId.

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

ในส่วนของลูกค้า เมื่อเตรียมการ BillingFlowParamsคุณแค่ต้องสร้างรายการของ ProductDetailsParams และโทร setObfuscatedAccountId(obfuscatedAccountId) ก่อนเริ่มกระบวนการทำงาน วิธีนี้ไม่ได้เปลี่ยนแปลงประสบการณ์การใช้งานของผู้ใช้ แต่ช่วยให้กระบวนการง่ายขึ้นมาก ตรรกะการจัดสรรการซื้อในส่วนแบ็กเอนด์ และช่วยให้ Google ตรวจจับการฉ้อโกงได้

ตรวจสอบการซื้อโดยใช้ Google Play Developer API

ก่อนที่จะอนุญาตสิทธิ์ใดๆ บนเซิร์ฟเวอร์ของคุณ จำเป็นต้องตรวจสอบให้แน่ใจว่าการซื้อนั้นถูกต้องตามกฎหมายโดยการโทรติดต่อ Google Play Developer APIการพึ่งพาข้อมูลที่ลูกค้าหรือแม้แต่ RTDN บอกนั้นไม่เพียงพอ คุณต้องตรวจสอบความถูกต้องของข้อมูลด้วย purchaseToken โดยตรงกับจุดสิ้นสุดอย่างเป็นทางการ และหากจำเป็น จัดการการคืนเงิน.

ในกรณีของผลิตภัณฑ์ที่มีเอกลักษณ์เฉพาะ คุณจะใช้เอนด์พอยต์ purchases.products:getสำหรับการสมัครสมาชิก เส้นทางจะนำไปสู่... purchases.subscriptionsv2:getอัตราการไหลที่แนะนำคือ:

• แยกส่วน purchaseToken จากข้อความ Pub/Sub
• ตรวจสอบฐานข้อมูลของคุณเพื่อดูว่าคุณได้ประมวลผลไปแล้วหรือไม่ โทเค็นแต่ละรายการคือ มีเอกลักษณ์เฉพาะตัวในระดับโลกดังนั้นจึงเหมาะอย่างยิ่งที่จะใช้เป็นคีย์หลักเพื่อหลีกเลี่ยงข้อมูลซ้ำซ้อน
• ถ้าเป็นแอปใหม่ ให้เรียกใช้ Google Play Developer API โดยระบุแพ็กเกจ, SKU และข้อมูลอื่นๆ purchaseToken.
• ตรวจสอบว่าการตอบกลับระบุสถานะการซื้อหรือไม่ ซื้อแล้ว (ไม่ใช่สถานะรอดำเนินการหรือถูกยกเลิก)
• หากทุกอย่างตรงกัน ให้ลงทะเบียนโทเค็นและมอบสิทธิ์ที่เกี่ยวข้องให้กับผู้ใช้ที่เชื่อมโยง

ในการสื่อสารกับ Play Developer API จาก Java คุณสามารถใช้ แอนดรอยด์พับลิชเชอร์โดยเริ่มต้นใช้งานด้วยข้อมูลประจำตัวบัญชีบริการในรูปแบบ JSON คุณสามารถกำหนดขอบเขตได้ AndroidPublisherScopes.ANDROIDPUBLISHERคุณสร้างไคลเอนต์และเรียกใช้เมธอด purchases().products().get(...)หากการโทรล้มเหลวเนื่องจากปัญหาเครือข่ายหรือบริการชั่วคราว ขอแนะนำให้ดำเนินการดังนี้ ใช้การลองใหม่ซ้ำด้วยการหน่วงเวลาแบบเลขชี้กำลัง เพื่อไม่ให้พลาดกิจกรรมนี้

ยืนยันหรือดำเนินการซื้อให้เสร็จสมบูรณ์จากเซิร์ฟเวอร์

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

สินค้าอุปโภคบริโภค (เช่น สกุลเงินดิจิทัล ชีวิต ฯลฯ) ต้องผ่านจุดเชื่อมต่อ (endpoint) purchases.products:consumeการดำเนินการนี้จะทำเครื่องหมายว่าโทเค็นถูกใช้งานแล้ว และอนุญาตให้ผู้ใช้ซื้อสินค้าชิ้นเดิมซ้ำได้โดยไม่มีข้อขัดแย้ง สำหรับสินค้าที่ไม่ใช่สินค้าอุปโภคบริโภค (เช่น การปลดล็อกเวอร์ชันพรีเมียมตลอดชีพ) คุณต้องโทรติดต่อฝ่ายบริการลูกค้า purchases.products:acknowledgeซึ่งจะแจ้งให้ Google ทราบว่าผู้ใช้มีสิทธิ์ที่เกี่ยวข้องอยู่แล้ว

มีการใช้การสมัครสมาชิก purchases.subscriptions:acknowledgeซึ่งแสดงว่าการสมัครสมาชิกได้รับการประมวลผลและกำหนดให้กับผู้ใช้เรียบร้อยแล้ว หากคุณไม่ยืนยันการซื้อภายในระยะเวลาที่เหมาะสม Google อาจสันนิษฐานว่ามีปัญหาและยกเลิกธุรกรรม ดังนั้นจึงเป็นสิ่งสำคัญที่คุณต้องยืนยันการซื้อของคุณ การดำเนินการย้อนกลับจะทำทันทีหลังจากให้สิทธิ์แล้ว.

ใน AndroidPublisher helper ของคุณ คุณสามารถเพิ่มเมธอดต่างๆ ได้ เช่น executeProductPurchasesConsume y executeProductPurchasesAcknowledge ซึ่งจะเรียกใช้เอนด์พอยต์ที่เกี่ยวข้อง ขอแนะนำให้ทำการลองใหม่ในกรณีที่เกิดความล้มเหลวเป็นครั้งคราว เพื่อให้แน่ใจว่าไม่มีโทเค็นใดอยู่ในสถานะกลางที่เป็นอันตราย

การทดสอบขั้นสูงด้วย Play Billing Lab

สิ่งหนึ่งที่นักพัฒนาหลายคนมองข้ามคือขั้นตอนการทดสอบ เพื่อให้การเปิดตัวผลิตภัณฑ์เป็นไปอย่างมั่นใจ คุณจำเป็นต้องสามารถจำลองสถานการณ์ต่างๆ ได้ ข้อผิดพลาดของเครือข่าย การตอบสนองที่ไม่เป็นไปตามมาตรฐาน และกรณีพิเศษนั่นคือจุดที่ Play Billing Lab เข้ามามีบทบาท แอปฟรีบน Google Play ที่ออกแบบมาโดยเฉพาะสำหรับการทดสอบการผสานรวม Play Billing Library

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

เพื่อให้แอปของคุณสามารถสื่อสารกับโปรแกรมจำลองได้ คุณต้องเปิดใช้งานการทดสอบ "การกำหนดค่าเรียกเก็บเงินแบบกำหนดเอง" โดยใช้เมตาเดต้าในไฟล์ AndroidManifest.xml:

<manifest ... >
  <application ... >
    ...
    <meta-data
        android:name="com.google.android.play.largest_release_audience.NONPRODUCTION"
        android:value="" />
    <meta-data
        android:name="com.google.android.play.billingclient.enableBillingOverridesTesting"
        android:value="true" />
  </application>
</manifest>

ฉลาก เปิดใช้งานการทดสอบการแทนที่การเรียกเก็บเงิน เปิดใช้งานการทดสอบการตอบสนองจำลองในไลบรารีการเรียกเก็บเงิน แท็ก NONPRODUCTION เป็นเหมือนการเตือนว่าเวอร์ชันนี้ไม่ควรนำไปใช้งานจริงโดยที่การตั้งค่าพิเศษยังคงเปิดใช้งานอยู่ เมื่อเตรียมเวอร์ชันสุดท้ายสำหรับผู้ใช้ โปรดตรวจสอบให้แน่ใจว่าได้... ลบข้อมูลเมตาเหล่านี้ออก หรือใช้ไฟล์ manifest แยกต่างหาก.

เมื่อตั้งค่าเสร็จแล้ว ให้ล็อกอินด้วยบัญชีผู้ทดสอบใบอนุญาตจากแอป Play Billing Lab เปิดใช้งานตัวเลือก "จำลองการตอบสนองของ Play Billing Library" และเลือกโค้ดข้อผิดพลาดที่คุณต้องการให้ส่งคืนสำหรับแต่ละ API (ตัวอย่างเช่น ข้อผิดพลาดเฉพาะใน consumeAsyncจากนั้นเพียงแค่เปิดแอปของคุณและเรียกใช้ขั้นตอนที่คุณต้องการทดสอบ โปรแกรมจำลองจะส่งคืนการตอบสนองที่กำหนดค่าไว้ และคุณสามารถตรวจสอบได้ว่าตรรกะการลองใหม่ การจัดการข้อผิดพลาด และ RTDN ทำงานได้ตามที่คาดหวัง

การเปลี่ยนแปลง API ที่สำคัญเมื่อย้ายไปใช้ Play Billing Library 7

นอกเหนือจาก RTDN และการทดสอบแล้ว การย้ายไปใช้ PBL 7 ยังเกี่ยวข้องกับการจัดการ API บางจุดโดยเฉพาะ สำหรับผู้ที่มาจาก PBL 5 หรือ 6 ควรตรวจสอบการเปลี่ยนแปลงที่เกี่ยวข้องมากที่สุดเพื่อให้แน่ใจว่าโปรเจ็กต์คอมไพล์ได้อย่างราบรื่นและตรรกะทางธุรกิจยังคงสอดคล้องกัน

อันดับแรก API ที่เกี่ยวข้องกับ โหมดการคิดค่าส่วนเพิ่ม ตัวเลือกการเปลี่ยนแปลงการสมัครสมาชิกถูกลบออกแล้ว ขณะนี้ใช้ตัวเลือกต่อไปนี้แทน: โหมดการเปลี่ยนทดแทน เพื่อจัดการกับการเปลี่ยนแปลงแผน (การอัปเกรด การดาวน์เกรด ฯลฯ) หากคุณยังคงใช้วิธีการเช่นนี้อยู่ setReplaceProrationMode o setReplaceSkusProrationModeคุณจะต้องย้ายข้อมูลเหล่านั้นไปยังเวอร์ชันใหม่ของ setSubscriptionReplacementMode และปรับตรรกะให้สอดคล้องกับเอกสารที่อัปเดตแล้ว

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

จุดสำคัญอีกประการหนึ่งคือ API การเรียกเก็บเงินทางเลือกวิธีการ BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails ได้หายไปแล้วและแทนที่ด้วยระบบการตั้งชื่อที่สอดคล้องกันมากขึ้น: ตอนนี้คุณต้องใช้ BillingClient.Builder.enableUserChoiceBilling() ข้างๆ UserChoiceBillingListener y UserChoiceDetailsตามที่ Google ระบุไว้เอง การเปลี่ยนแปลงนี้โดยพื้นฐานแล้วเป็นการเปลี่ยนชื่อโดยไม่มีการเปลี่ยนแปลงพฤติกรรมใดๆ ในบริบทที่ระบุด้วยข้อตกลงต่างๆ เช่น... Google และ Epic Games ตกลงที่จะเปิดระบบ Android ให้ใช้งานได้อย่างเสรี.

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

รายการธุรกรรมที่รอดำเนินการและการไม่มีหมายเลขคำสั่งซื้อจนกว่าจะมีการซื้อเสร็จสิ้น

การเปลี่ยนแปลงเล็กน้อยใน PBL 7 คือห้องสมุดจะไม่สร้างไฟล์อีกต่อไป รหัสคำสั่งซื้อสำหรับการซื้อที่รอดำเนินการ- ในกรณีเหล่านี้ orderId ฟังก์ชันนี้จะใช้งานได้ก็ต่อเมื่อการสั่งซื้อเสร็จสมบูรณ์และอยู่ในสถานะ "ซื้อแล้ว" เท่านั้น โดยเฉพาะอย่างยิ่งในขั้นตอนการทำงานที่คุณใช้รหัสคำสั่งซื้อเป็นข้อมูลอ้างอิงหลักตั้งแต่เริ่มต้น

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

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

ฟังก์ชันเสริมใหม่ใน PBL 7: การผ่อนชำระเสมือนจริงและการชำระเงินล่วงหน้า

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

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

ในขณะนี้ ค่าธรรมเนียมการสมัครสมาชิกเหล่านี้มีให้บริการเฉพาะใน บราซิล ฝรั่งเศส อิตาลี และสเปนGoogle แนะนำให้คอยตรวจสอบ Play Console เพื่อดูว่าประเทศใดบ้างที่ได้รับการสนับสนุนเพิ่มเติม การตั้งค่าทำได้ผ่านทาง ProductDetails.InstallmentPlanDetails และปฏิบัติตามคำแนะนำเฉพาะเพื่อผสานรวมเข้ากับแอปของคุณ

ในขณะเดียวกัน การสนับสนุนก็กำลังขยายวงกว้างขึ้น การซื้อที่รอดำเนินการสำหรับการสมัครสมาชิกแบบชำระเงินล่วงหน้าตอนนี้คุณสามารถนำเสนอโมเดลที่ผู้ใช้เริ่มต้นการซื้อในแอปและชำระเงินในภายหลังผ่านช่องทางอื่นได้แล้ว และ Billing Library ก็รู้วิธีจัดการขั้นตอนดังกล่าวอย่างถูกต้อง การเปิดใช้งานทำได้โดยการเรียกใช้ฟังก์ชัน enablePendingPurchases() เมื่อเริ่มต้นใช้งาน BillingClient และโดยเฉพาะอย่างยิ่งสำหรับแผนแบบชำระเงินล่วงหน้า ให้ใช้ PendingPurchasesParams.Builder.enablePrepaidPlans().

ระยะเวลาการคิดค่าเสื่อมราคาสำหรับ Play Billing Library 5 และ 6

ด้วยการเปิดตัว PBL 7 กูเกิลได้กำหนดวันเวลาที่ชัดเจนสำหรับ... ยกเลิกการสนับสนุนสำหรับเวอร์ชัน 5 และ 6หากคุณยังอยู่ในช่วงเวลาใดเวลาหนึ่งเหล่านี้ คุณต้องทำเครื่องหมายสีแดงบนปฏิทิน:

• Google Play Billing Library 5 จะถูกยกเลิกการใช้งานอย่างเป็นทางการในวันที่ 31 สิงหาคม 2024 สำหรับแอปใหม่และการอัปเดตต่างๆ สามารถขอขยายเวลาได้จนถึงวันที่ 1 พฤศจิกายน 2024 แต่ไม่ควรพึ่งพาการขยายเวลานี้ในระยะยาว
• Google Play Billing Library 6 สามารถใช้เพื่อเผยแพร่แอปใหม่ได้จนถึงวันที่ 1 สิงหาคม 2025 และเพื่ออัปเดตแอปที่มีอยู่แล้วได้จนถึงวันที่ 1 พฤศจิกายน 2025

หลังจากวันที่ดังกล่าว หากคุณยังไม่ได้อัปเกรดเป็นเวอร์ชัน 6 หรือเวอร์ชัน 7 (ถ้าเป็นไปได้) คุณจะต้องอัปเดตเป็นเวอร์ชันล่าสุด 7 รุ่นการอัปเดตแอปของคุณจะถูกบล็อกใน Play Console แม้ว่าแอปของคุณจะยังคงทำงานได้บนอุปกรณ์ของผู้ใช้ แต่คุณจะไม่สามารถแก้ไขข้อบกพร่องหรือเพิ่มฟีเจอร์ใหม่ที่ขึ้นอยู่กับการเผยแพร่ในร้านค้าได้

กรณีของ .NET MAUI และข้อจำกัดในปัจจุบัน

หากคุณกำลังใช้งาน .NET MAUI และการสมัครรับข้อมูลบน Android คุณอาจเคยอ่านหรือประสบมาแล้วว่ามันไม่ง่ายอย่างที่คิด โครงการจำนวนมากใช้... ปลั๊กอิน.การเรียกเก็บเงินในแอป พัฒนาโดย James Montemagno แต่ปลั๊กอินนี้ถูกเก็บถาวรและไม่มีการบำรุงรักษา ดังนั้นจึงจะไม่มีการอัปเดตเพื่อรองรับ Billing Library 7 ในขณะเดียวกัน แพ็กเกจอย่างเป็นทางการก็มีให้ใช้งานเช่นกัน Xamarin.Android.Google.BillingClient มันยังคงยึดโยงอยู่กับระบบนิเวศของ Xamarin.Android และไม่สามารถใช้งานร่วมกับ .NET MAUI ได้โดยตรง

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

ในบริบทนี้ หลายทีมกำลังพิจารณาทางเลือกอื่น ๆ เช่น SDK ของบุคคลที่สาม บริการเหล่านี้รองรับ PBL 7 อยู่แล้ว และเปิดเผย API ที่เสถียรและใช้งานได้หลายแพลตฟอร์ม (ตัวอย่างเช่น โซลูชันแบ็กเอนด์สำหรับการสมัครสมาชิกพร้อม SDK สำหรับ Android, iOS และแพลตฟอร์มอื่นๆ) โดยทั่วไปแล้ว บริการเหล่านี้จะจัดการการย้ายเวอร์ชันของ Billing Library และเปิดเผย wrapper ที่เสถียร ซึ่งช่วยลดภาระลงอย่างมากเมื่อมีการยกเลิกการใช้งาน Google แต่ละครั้ง

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

บทความที่เกี่ยวข้อง:

ขั้นตอนวิธีการขอคืนเงินสำหรับการซื้อสินค้าบน Google Play ทีละขั้นตอน

โดยรวมแล้ว การอัปเดต Google Play Billing Library เวอร์ชัน 7 เกี่ยวข้องกับการตรวจสอบความสัมพันธ์ระหว่างส่วนประกอบต่างๆ การลบ API ที่ล้าสมัย การเสริมความแข็งแกร่งของตรรกะเบื้องหลังด้วยการตรวจสอบการซื้อและ RTDN และการใช้เครื่องมือทดสอบ เช่น Play Billing Lab เพื่อค้นหาข้อบกพร่องทั้งหมดก่อนเปิดใช้งานจริง ผู้ที่ใช้เวลาในการปรับแต่งการย้ายระบบนี้จะสามารถจัดการกับแผนแบบชำระเงินล่วงหน้า ค่าธรรมเนียมเสมือน ข้อผิดพลาดของเครือข่าย และการเปลี่ยนแปลงวงจรชีวิตการสมัครสมาชิกได้ดียิ่งขึ้น และจะมีโอกาสที่ดีกว่าในการรักษารายได้ที่มั่นคงและประสบการณ์การใช้งานที่ราบรื่นบน Google Play แบ่งปันข้อมูลเพื่อให้ผู้ใช้เพิ่มเติมสามารถเรียนรู้เกี่ยวกับหัวข้อนั้นๆ