درباره اشتراک ها

با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

این مبحث نحوه مدیریت رویدادهای چرخه عمر اشتراک، مانند تمدید و انقضا را شرح می دهد. همچنین ویژگی های اشتراک اضافی مانند ارائه تبلیغات و اجازه دادن به کاربران شما برای مدیریت اشتراک های خود را شرح می دهد.

اگر محصولات اشتراک را برای برنامه خود پیکربندی نکرده‌اید، به ایجاد و پیکربندی محصولات خود مراجعه کنید.

نمای کلی اشتراک ها

اشتراک مجموعه‌ای از مزایایی است که کاربران می‌توانند در طول یک دوره زمانی مشخص به آن‌ها دسترسی داشته باشند. برای مثال، یک اشتراک ممکن است به کاربر حق دسترسی به یک سرویس پخش موسیقی را بدهد.

می‌توانید چندین اشتراک در یک برنامه داشته باشید، یا برای نشان دادن مجموعه‌های مختلف مزایا، یا سطوح مختلف از یک مجموعه مزایا (مثلاً طبقات «نقره‌ای» و «طلا»).

از طریق طرح‌ها و پیشنهادات پایه ، می‌توانید چندین پیکربندی را برای یک محصول اشتراک ایجاد کنید. به عنوان مثال، می توانید یک پیشنهاد مقدماتی برای کاربرانی که هرگز در برنامه شما مشترک نشده اند ایجاد کنید. به طور مشابه، می توانید یک پیشنهاد ارتقاء برای کاربرانی که قبلا مشترک شده اند ایجاد کنید.

برای یک نمای کلی از محصولات اشتراک، طرح‌های پایه و پیشنهادات، به مستندات موجود در مرکز راهنمای کنسول Play مراجعه کنید.

ادغام طرح های پیش پرداخت

طرح های پیش پرداخت به صورت خودکار پس از انقضا تمدید نمی شوند. برای تمدید حق اشتراک خود بدون وقفه، کاربر باید یک طرح پیش پرداخت را برای همان اشتراک شارژ کند .

برای شارژ، جریان صورت‌حساب را مانند خرید اصلی راه‌اندازی کنید. نیازی نیست نشان دهید که خرید یک شارژ است.

شارژهای طرح پیش‌پرداخت همیشه از حالت جایگزینی CHARGE_FULL_PRICE استفاده می‌کنند و نیازی به تنظیم صریح این حالت ندارید. کاربر بلافاصله برای یک دوره صورت‌حساب کامل هزینه دریافت می‌کند و استحقاق او با مدت زمان مشخص‌شده در شارژ تمدید می‌شود.

پس از تکمیل، فیلدهای زیر در شیء نتیجه Purchase به‌روزرسانی می‌شوند تا جدیدترین خرید شارژ را منعکس کنند:

• شناسه سفارش
• زمان خرید
• امضا
• خرید توکن
• تصدیق کرد

فیلدهای Purchase زیر همیشه حاوی همان داده‌های موجود در خرید اصلی هستند:

• نام بسته
• وضعیت خرید
• محصولات
• تمدید خودکار

تاییدیه خرید پیش پرداخت

مشابه اشتراک‌های تمدید خودکار، پس از خرید باید طرح‌های پیش‌پرداخت را تأیید کنید. هم خرید اولیه و هم هرگونه شارژ باید تایید شود. برای اطلاعات بیشتر، به پردازش خریدها مراجعه کنید.

با توجه به احتمال کوتاه مدت طرح پیش پرداخت، مهم است که خرید را در اسرع وقت تایید کنید.

طرح های پیش پرداخت با مدت زمان یک هفته یا بیشتر باید ظرف سه روز تایید شوند.

طرح های پیش پرداخت با مدت زمان کمتر از یک هفته باید در نیمی از مدت زمان طرح تایید شوند. به عنوان مثال، توسعه دهندگان 1.5 روز فرصت دارند تا یک طرح پیش پرداخت سه روزه را تایید کنند.

ادغام اشتراک های اقساطی

اشتراک اقساطی نوعی از اشتراک است که در آن کاربران به جای پرداخت کل هزینه اشتراک، هزینه اشتراک را در یک دوره زمانی چند قسطی پرداخت می کنند.

ملاحظات اضافی برای اشتراک اقساطی:

• در دسترس بودن کشور : ویژگی اشتراک اقساطی فقط در برزیل، فرانسه، ایتالیا و اسپانیا در دسترس است (برای آخرین در دسترس بودن کنسول را بررسی کنید).
• تنظیم قیمت : هنگام تعیین قیمت اشتراک اقساطی در کنسول، قیمت نشان دهنده مبلغ پرداخت ماهانه است. این، همراه با دوره تعهد تنظیم شده، کل مبلغ اشتراک را در صفحه خرید ایجاد می کند.
• دوره تعهد : کل مدت تعهد اشتراک اولیه که طی آن پرداخت های ماهانه مورد نیاز است. به عنوان مثال، اگر یک طرح پایه دارای یک دوره تعهد 15 ماهه باشد، کاربر در این مدت 15 پرداخت ماهانه انجام خواهد داد.
• تمدید : در زمینه اشتراک اقساط، "تجدید" به معنای پایان یک دوره تعهد است، یا دوره تعهد اولیه یا دوره تعهد بعدی. پس از ثبت نام اولیه، اولین تمدید پس از اتمام کل دوره تعهد اولیه رخ می دهد. تمدیدهای بعدی پس از انجام هر دوره تعهد بعدی انجام می شود. انواع تمدید برای اشتراک های اقساطی می تواند "تمدید خودکار ماهانه" یا "تمدید خودکار برای مدت زمان مشابه" باشد. برای "تمدید خودکار ماهانه"، هیچ تعهد بعدی وجود ندارد و این طرح مانند یک اشتراک ماهانه عمل می کند که در آن هر هزینه اشتراک ماهانه یک تمدید است.
• دوره صورت‌حساب : در زمینه اشتراک‌های اقساطی، این به بازه زمانی تکراری اطلاق می‌شود که در آن پرداخت‌های فردی، همانطور که در طرح پایه مشخص شده است، انجام می‌شود.
• تغییر برنامه در مقابل رفتارهای تغییر قیمت : برای تغییرات قیمت و لغو، تعهد قطعی است. این بدان معناست که اگر کاربری بخواهد لغو کند یا توسعه‌دهنده بخواهد قیمت را تغییر دهد، این تغییر در پایان یک دوره تعهد اعمال می‌شود. برای تغییرات طرح، تعهد قطعی نیست. این بدان معنی است که تغییر طرح نیازی به صبر کردن تا پایان دوره تعهد ندارد، یا بلافاصله یا در تاریخ پرداخت بعدی بر اساس حالت جایگزینی تنظیم شده اعمال می شود.
• تغییر طرح اشتراکی یکسان : تغییر طرح از طرح پایه اقساطی به طرح پایه غیر اقساطی همان محصول اشتراکی مجاز نیست.

• اعلان‌های بی‌درنگ برنامه‌نویس (RTDN) : یک SUBSCRIPTION_CANCELLATION_SCHEDULED RTDN بلافاصله پس از لغو شروع‌شده توسط کاربر، زمانی که پرداخت‌ها برای دوره تعهد باقی می‌ماند، ارسال می‌شود. لغو در انتظار است و فقط در پایان دوره تعهد اعمال می شود. سپس، اگر توسط کاربر بازیابی نشود، RTDN های SUBSCRIPTION_CANCELED و SUBSCRIPTION_EXPIRED در پایان دوره تعهد ارسال می شوند.

• پرداخت‌ها / تحقق درآمد : پرداخت‌های برنامه‌نویس زمانی اتفاق می‌افتد که کاربران پرداخت‌های ماهانه خود را مشروط به شرایطی مشابه با سایر اشتراک‌ها انجام می‌دهند. زمانی که کاربر برای اشتراک اقساطی ثبت‌نام می‌کند، به برنامه‌نویسان پرداختی پرداخت نمی‌شود.

• جمع‌آوری‌های پرداخت از دست رفته : اگر کاربر نتواند هیچ گونه پرداخت اشتراک اقساطی را انجام دهد، نه Google و نه توسعه‌دهنده تلاشی برای دریافت چنین پرداخت‌های از دست رفته یا معوقی از کاربر نخواهند داشت، به جز اینکه Google ممکن است به‌طور دوره‌ای پرداخت را در طول هر دوره مهلت قابل اعمال یا دوره توقف حساب، مطابق با روش‌های عادی تکرار پرداخت، تکرار کند. Google در قبال پرداخت‌های اقساطی پرداخت نشده باقیمانده در قبال برنامه‌نویس مسئولیتی نخواهد داشت.

• در دسترس بودن کتابخانه صورت‌حساب Play : قسمت installmentDetails فقط برای PBL 7 یا بالاتر در دسترس است. برای PBL 5 و نسخه های جدیدتر، اشتراک اقساط با استفاده از queryProductDetails() برگردانده می شود، اما اشتراک شامل اطلاعات دقیق اقساط مانند تعداد پرداخت های تعهد شده طرح نمی شود.

از پیوندهای عمیق استفاده کنید تا کاربران بتوانند اشتراک را مدیریت کنند

برنامه شما باید دارای پیوندی در صفحه تنظیمات یا تنظیمات برگزیده باشد که به کاربران امکان می دهد اشتراک های خود را مدیریت کنند، که می توانید آن را در ظاهر و احساس طبیعی برنامه خود بگنجانید.

می‌توانید یک پیوند عمیق از برنامه خود به مرکز اشتراک‌های Google Play برای اشتراک‌های منقضی نشده اضافه کنید، که می‌توانید با استفاده از قسمت subscriptionState منبع اشتراک تعیین کنید. بر این اساس، راه‌های مختلفی وجود دارد که می‌توانید به مرکز اشتراک‌های فروشگاه Play پیوند عمیق بدهید.

پیوند به مرکز اشتراک

همانطور که در شکل های 1 و 2 نشان داده شده است، از URL زیر برای هدایت کاربران به صفحه ای که همه اشتراک های آنها را نشان می دهد استفاده کنید:

https://play.google.com/store/account/subscriptions

این پیوند عمیق می‌تواند برای کمک به کاربر برای بازیابی اشتراک لغو شده از مرکز اشتراک‌های فروشگاه Play مفید باشد.

پیوند به یک صفحه مدیریت اشتراک خاص (توصیه می شود)

برای پیوند مستقیم به صفحه مدیریت برای اشتراکی که منقضی نشده است، نام بسته و productId مرتبط با اشتراک خریداری شده را مشخص کنید. برای تعیین برنامه‌نویسی productId برای یک اشتراک موجود، باطن برنامه خود را پرس و جو کنید یا با BillingClient.queryPurchasesAsync() برای فهرستی از اشتراک‌های مرتبط با یک کاربر خاص تماس بگیرید. هر اشتراک حاوی productId مربوطه به عنوان بخشی از اطلاعات وضعیت اشتراک است. هر شیء SubscriptionPurchaseLineItem مرتبط با خرید اشتراک حاوی مقدار productId مرتبط با اشتراکی است که کاربر در آن آیتم خط خریداری کرده است.

از URL زیر برای هدایت کاربران به یک صفحه مدیریت اشتراک خاص استفاده کنید و به ترتیب نام بسته productId و برنامه را جایگزین «شماره محصول فرعی» و «بسته برنامه شما» کنید:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

سپس کاربر می‌تواند روش‌های پرداخت خود را مدیریت کند و به ویژگی‌هایی از جمله لغو، اشتراک مجدد و توقف دسترسی داشته باشد.

به کاربران امکان ارتقا، کاهش یا تغییر اشتراک خود را بدهید

می‌توانید گزینه‌های مختلفی را در اختیار مشترکین فعلی قرار دهید تا طرح اشتراک خود را تغییر دهند تا نیازهایشان را بهتر برآورده کنند:

• اگر چندین سطح اشتراک مانند اشتراک‌های «پایه» و «حق بیمه» را می‌فروشید، می‌توانید به کاربران اجازه دهید با خرید طرح یا پیشنهاد پایه اشتراک دیگری، ردیف‌ها را تغییر دهند.
• می‌توانید به کاربران اجازه دهید دوره صورت‌حساب فعلی خود را تغییر دهند، مانند تغییر از برنامه ماهانه به سالانه.
• همچنین می‌توانید به کاربران اجازه دهید بین برنامه‌های تمدید خودکار و طرح‌های پیش‌پرداخت جابجا شوند.

شما می توانید با ارائه پیشنهادهای اشتراک برای ارائه تخفیف به کاربران واجد شرایط، هر یک از این تغییرات را تشویق کنید. به‌عنوان مثال، می‌توانید پیشنهادی ایجاد کنید که در سال اول هنگام تغییر از طرح ماهانه به سالانه، 50 درصد تخفیف ایجاد کنید، و این پیشنهاد را به کاربران مشترک طرح ماهانه که این پیشنهاد را خریداری نکرده‌اند محدود کنید. اطلاعات بیشتر در مورد معیارهای واجد شرایط بودن پیشنهاد در مرکز راهنمایی موجود است

شکل 3 یک برنامه نمونه را با سه طرح مختلف نشان می دهد:

برنامه شما می تواند صفحه ای شبیه به شکل 3 نشان دهد و به کاربران گزینه هایی برای تغییر اشتراک خود بدهد. در همه موارد، باید برای کاربران مشخص باشد که طرح اشتراک فعلی آنها چیست و چه گزینه هایی برای تغییر آن دارند.

هنگامی که کاربران تصمیم به ارتقا، کاهش یا تغییر اشتراک خود می‌گیرند، حالت جایگزینی را مشخص می‌کنید که تعیین می‌کند ارزش تناسبی دوره صورت‌حساب فعلی پرداخت‌شده چگونه اعمال شود، و چه زمانی هر تغییر حقی رخ می‌دهد.

حالت های جایگزین

جدول زیر حالت‌های جایگزین موجود و نمونه استفاده و تعداد پرداخت‌های پرداختی در نظر گرفته شده را فهرست می‌کند.

برای کسب اطلاعات بیشتر در مورد برنامه های مختلف upsell و winback پیشنهادات ارتقا یا کاهش، راهنمای پیشنهادات و تبلیغات را بخوانید.

حالت جایگزینی را برای خرید تنظیم کنید

بر اساس ترجیحات و منطق تجاری خود، می‌توانید از حالت‌های جایگزین مختلفی برای انواع مختلف انتقال اشتراک استفاده کنید. این بخش نحوه تنظیم حالت جایگزینی برای تغییر در اشتراک و محدودیت های اعمال شده را توضیح می دهد.

مجدداً مشترک شوید یا طرح‌ها را در همان اشتراک تغییر دهید

می توانید حالت جایگزینی پیش فرض را در کنسول Google Play تعیین کنید. این تنظیم به شما امکان می‌دهد انتخاب کنید که چه زمانی از مشترکین فعلی در صورت خرید طرح پایه یا پیشنهاد متفاوت برای اشتراک مشابه یا اشتراک مجدد پس از لغو، هزینه دریافت کنید. گزینه های موجود عبارتند از شارژ فوری , معادل CHARGE_FULL_PRICE , و شارژ در تاریخ صورتحساب بعدی , معادل WITHOUT_PRORATION . اینها تنها حالت‌های جایگزین مربوط به هنگام تعویض طرح‌های پایه در همان اشتراک هستند.

برای مثال، اگر پس از لغو کاربر، اما قبل از پایان اشتراک، یک پیشنهاد winback را برای همان طرح پیاده‌سازی می‌کنید، می‌توانید خرید جدید را به‌عنوان یک خرید معمولی بدون نشان دادن هیچ مقداری در SubscriptionUpdateParams پردازش کنید. سیستم از حالت جایگزینی پیش‌فرض که در اشتراک پیکربندی کرده‌اید استفاده می‌کند و به طور خودکار انتقال طرح از خرید قدیمی به خرید جدید را مدیریت می‌کند.

برنامه‌ها را بین اشتراک‌ها تغییر دهید یا حالت جایگزینی پیش‌فرض را لغو کنید

اگر کاربر در حال تغییر محصولات اشتراک است - خرید اشتراک دیگری - یا اگر می‌خواهید به هر دلیلی حالت جایگزینی پیش‌فرض را لغو کنید، نرخ تناسب در زمان اجرا را به عنوان بخشی از پارامترهای جریان خرید مشخص می‌کنید.

برای ارائه صحیح SubscriptionUpdateParams به عنوان بخشی از پیکربندی جریان خرید زمان اجرا، به محدودیت‌های زیر توجه کنید:

• هنگام ارتقاء، ارتقاء، یا شروع انجام یک تغییر اشتراک به یک طرح پیش‌پرداخت از یک طرح پیش‌پرداخت، طرح تمدید خودکار یا طرح اقساطی، تنها حالت جایگزین مجاز CHARGE_FULL_PRICE است. اگر حالت جایگزین دیگری را مشخص کنید، خرید با شکست مواجه می شود و خطایی به کاربر نشان داده می شود.
• هنگام تعویض طرح‌ها در همان اشتراک به یک طرح تمدید خودکار از یک طرح پیش‌پرداخت یا یک طرح تمدید خودکار، حالت‌های تقسیم بندی معتبر CHARGE_FULL_PRICE و WITHOUT_PRORATION هستند. اگر حالت proration دیگری را مشخص کنید، خرید با شکست مواجه می شود و یک خطا به کاربر نشان داده می شود.
• تغییر طرح های درون یک محصول اشتراکی از طرح پایه اقساطی به طرح پایه غیر اقساطی مجاز نیست.

مثال ها و رفتارهای جایگزین

برای درک نحوه عملکرد هر حالت proration، سناریوی زیر را در نظر بگیرید:

Samwise دارای اشتراک محتوای آنلاین از برنامه Country Gardener است. او اشتراک ماهانه نسخه Tier 1 محتوا را دارد که فقط متنی است. این اشتراک 2 دلار در ماه برای او هزینه دارد و در اول ماه تمدید می شود.

در 15 آوریل، Samwise تصمیم گرفت تا به نسخه سالانه اشتراک Tier 2 ارتقا یابد، که شامل به‌روزرسانی‌های ویدیویی است و هزینه آن 36 دلار در سال است.

هنگام ارتقاء اشتراک، توسعه‌دهنده حالت proration را انتخاب می‌کند. فهرست زیر نحوه تأثیر هر حالت proration را بر اشتراک Samwise توضیح می دهد:

WITH_TIME_PRORATION

اشتراک Tier 1 Samwise بلافاصله پایان می یابد. از آنجایی که او برای یک ماه کامل (1 تا 30 آوریل) پرداخت کرد اما در نیمه دوره اشتراک ارتقا یافت، نیمی از اشتراک یک ماهه (1 دلار) برای اشتراک جدید او اعمال می شود. با این حال، از آنجا که هزینه اشتراک جدید 36 دلار در سال است، موجودی اعتباری 1 دلاری تنها برای 10 روز پرداخت می شود (16-25 آوریل). بنابراین در 26 آوریل، 36 دلار برای اشتراک جدید و 36 دلار دیگر در 26 آوریل هر سال از او دریافت می شود.

شما باید در لحظه ای که خرید موفق شد PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از تماس queryPurchasesAsync() بازیابی کنید. باطن شما بلافاصله یک اعلان برنامه‌نویس SUBSCRIPTION_PURCHASED بلادرنگ دریافت می‌کند.

CHARGE_PRORATED_PRICE

این حالت را می توان استفاده کرد زیرا قیمت اشتراک ردیف 2 در هر واحد زمانی (36 دلار در سال = 3 دلار در ماه) بیشتر از قیمت اشتراک ردیف 1 در واحد زمانی (2 دلار در ماه) است. اشتراک Tier 1 Samwise بلافاصله پایان می یابد. از آنجایی که او یک ماه کامل را پرداخت کرد اما فقط نیمی از آن را استفاده کرد، نیمی از اشتراک یک ماهه (1 دلار) برای اشتراک جدید او اعمال می شود. با این حال، از آنجایی که هزینه اشتراک جدید 36 دلار در سال است، 15 روز باقی مانده 1.50 دلار هزینه دارد. بنابراین مابه التفاوت 0.50 دلار برای اشتراک جدیدش دریافت می شود. در 1 می، Samwise 36 دلار برای ردیف اشتراک جدید خود و 36 دلار دیگر در 1 می هر سال بعد از آن دریافت می‌کند.

شما باید در لحظه ای که خرید موفق شد PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از تماس queryPurchasesAsync() بازیابی کنید. باطن شما بلافاصله یک اعلان برنامه‌نویس SUBSCRIPTION_PURCHASED بلادرنگ دریافت می‌کند.

WITHOUT_PRORATION

اشتراک Tier 1 Samwise بلافاصله بدون هیچ هزینه اضافی به Tier 2 ارتقا می یابد و در 1 می 36 دلار برای ردیف اشتراک جدید خود و 36 دلار دیگر در 1 می هر سال بعد از آن دریافت می شود.

شما باید در لحظه ای که خرید موفق شد PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از تماس queryPurchasesAsync() بازیابی کنید. باطن شما بلافاصله یک اعلان برنامه‌نویس SUBSCRIPTION_PURCHASED بلادرنگ دریافت می‌کند.

DEFERRED

اشتراک Tier 1 Samwise ادامه دارد تا اینکه در 30 آوریل منقضی شود. در 1 مه، اشتراک Tier 2 اعمال می شود و Samwise برای ردیف اشتراک جدید خود 36 دلار دریافت می کند.

شما باید در لحظه ای که خرید موفق شد PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از تماس queryPurchasesAsync() بازیابی کنید. باطن شما بلافاصله یک اعلان برنامه‌نویس SUBSCRIPTION_PURCHASED بلادرنگ دریافت می‌کند. شما باید خرید را به همان روشی پردازش کنید که هر خرید جدید دیگری را در آن مرحله پردازش می کنید. به ویژه، مطمئن شوید که خرید جدید را تایید می کنید. توجه داشته باشید که startTime اشتراک جدید در لحظه ای که جایگزینی موثر است پر می شود، که زمانی اتفاق می افتد که اشتراک قدیمی منقضی شود. در آن مرحله، یک SUBSCRIPTION_RENEWED RTDN برای طرح اشتراک جدید دریافت می‌کنید. درباره رفتار ReplacementMode.DEFERRED در Handle deferred تعویض بیشتر بخوانید.

CHARGE_FULL_PRICE

اشتراک Tier 1 Samwise بلافاصله پایان می یابد. اشتراک Tier 2 او از امروز شروع می شود و 36 دلار از او دریافت می شود. از آنجایی که او یک ماه کامل را پرداخت کرد اما فقط نیمی از آن را استفاده کرد، نیمی از اشتراک یک ماهه (1 دلار) برای اشتراک جدید او اعمال می شود. از آنجا که هزینه اشتراک جدید 36 دلار در سال است، او 1/36 سال به دوره اشتراک خود اضافه می کند (10 روز). بنابراین، شارژ بعدی Samwise یک سال و 10 روز از امروز با قیمت 36 دلار خواهد بود. پس از آن، هر سال 36 دلار از او دریافت می شود.

هنگام انتخاب حالت تناسب، حتماً توصیه‌های جایگزین ما را مرور کنید.

ایجاد تغییرات اشتراک در برنامه

برنامه شما می‌تواند با استفاده از مراحل مشابه با راه‌اندازی جریان خرید، ارتقا یا تنزل را به کاربران ارائه دهد. با این حال، هنگام ارتقا یا ارتقاء، باید جزئیات اشتراک فعلی، اشتراک آینده (ارتقا یا کاهش یافته) و حالت جایگزینی برای استفاده را ارائه دهید، همانطور که در مثال زیر نشان داده شده است:

val offerToken = productDetails
        .getSubscriptionOfferDetails(selectedOfferIndex)
        .getOfferToken()

val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList(
       listOf(
           BillingFlowParams.ProductDetailsParams.newBuilder()
               .setProductDetails(productDetails)
               .setOfferToken(offerToken)
               .build()
       )
       ).setSubscriptionUpdateParams(
           BillingFlowParams.SubscriptionUpdateParams.newBuilder()
               .setOldPurchaseToken("old_purchase_token")
               .setSubscriptionReplacementMode(
                 BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE
               )
               .build()
       ).build()

billingClient.launchBillingFlow(
    activity,
    billingParams
   )
// ...

String offerToken = productDetails
    .getSubscriptionOfferDetails(selectedOfferIndex)
    .getOfferToken();

BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        ImmuableList.of(
            ProductDetailsParams.newBuilder()
                // fetched via queryProductDetailsAsync
                .setProductDetails(productDetails)
                // offerToken can be found in
                // ProductDetails=>SubscriptionOfferDetails
                .setOfferToken(offerToken)
                .build()))
    .setSubscriptionUpdateParams(
        SubscriptionUpdateParams.newBuilder()
            // purchaseToken can be found in Purchase#getPurchaseToken
            .setOldPurchaseToken("old_purchase_token")
            .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE)
            .build())
    .build();

BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
// ...

توصیه های جایگزین

جدول زیر سناریوهای تناسب مختلف را به همراه آنچه ما برای هر سناریو توصیه می کنیم نشان می دهد:

خریدهای تغییر اشتراک را مدیریت کنید

تغییرات طرح، خریدهای جدیدی برای همه شرایط و اهداف هستند و باید پس از تکمیل موفقیت آمیز جریان صورتحساب، پردازش شده و به عنوان چنین موردی تصدیق شوند. علاوه بر پردازش مناسب خرید جدید، باید خریدی را که در حال جایگزینی است بازنشسته کنید.

رفتار درون برنامه ای مانند هر خرید جدیدی است. برنامه شما نتیجه خرید جدید را در PurchasesUpdatedListener شما دریافت می کند و خرید جدید در queryPurchasesAsync موجود است.

Google Play Developer API یک linkedPurchaseToken در منبع اشتراک برمی‌گرداند که خریدی جایگزین یک موجود شود. حتماً توکن ارائه شده در linkedPurchaseToken را باطل کنید تا مطمئن شوید که رمز قدیمی برای دسترسی به خدمات شما استفاده نمی شود. برای اطلاعات در مورد مدیریت خریدهای ارتقاء و تنزل رتبه به ارتقاء، تنزل رتبه و استعفا مراجعه کنید.

هنگامی که رمز خرید جدید را دریافت می‌کنید، همان فرآیند تأیید صحت را که با تأیید یک نشانه خرید جدید انجام می‌دهید، دنبال کنید. مطمئن شوید که این خریدها را با BillingClient.acknowledgePurchase() از کتابخانه صورت‌حساب Google Play یا Purchases.subscriptions:acknowledge از Google Play Developer API تأیید کنید.

تعویض معوق را کنترل کنید

حالت تعویض معوق به شما اجازه می دهد تا قبل از شروع طرح جدید، به کاربر اجازه دهید از حق باقی مانده در طرح قدیمی خود استفاده کند.

هنگامی که از ReplacementMode.DEFERRED برای خرید جدیدی استفاده می کنید، queryPurchasesAsync() یک نشانه خرید جدید را پس از جریان خرید بازمی گرداند که با محصول قدیمی مرتبط می ماند تا زمانی که تعویض به تعویق افتاده در تاریخ تمدید بعدی انجام شود، پس از آن محصول جدید برگردانده می شود.

در گذشته می‌توانستید این تجربه کاربری را با ProrationMode.DEFERRED منسوخ شده به دست آورید، اما ProrationMode.DEFERRED با Play Billing Library 6 منسوخ شده است. جدول زیر را ببینید تا متوجه شوید این رفتار در کجا متفاوت است:

ReplacementMode.DEFERRED باید از این پس به جای ProrationMode.DEFERRED منسوخ شده استفاده شود، زیرا رفتار مشابهی را در مورد تغییرات حق ارائه می دهد، اما راهی برای مدیریت خرید ارائه می دهد که با رفتارهای سایر خریدهای جدید سازگارتر است.

مدیریت مشتری

با استفاده از اعلان‌های برنامه‌نویس بلادرنگ، می‌توانید در زمان واقعی تشخیص دهید که کاربر تصمیم به لغو آن دارد. وقتی کاربری لغو می‌کند، اما قبل از اینکه اشتراکش منقضی شود، می‌توانید برای او اعلان‌های فشاری یا پیام‌های درون‌برنامه بفرستید تا از او بخواهید دوباره اشتراک کند.

پس از اینکه کاربر اشتراک خود را لغو کرد، می توانید سعی کنید او را در برنامه خود یا از طریق فروشگاه Play برگردانید. جدول زیر سناریوهای مختلف اشتراک را به همراه اقدامات winback مرتبط و الزامات برنامه توضیح می دهد.

قبل از انقضای اشتراک - درون برنامه

برای اشتراک‌هایی که لغو شده‌اند اما هنوز منقضی نشده‌اند، می‌توانید با اعمال همان جریان خرید محصول درون‌برنامه‌ای که برای مشترکین جدید انجام می‌شود، به مشترکان اجازه دهید اشتراک خود را در برنامه شما بازیابی کنند. اطمینان حاصل کنید که رابط کاربری شما نشان می دهد که کاربر یک اشتراک موجود دارد. به عنوان مثال، ممکن است بخواهید تاریخ انقضای فعلی و قیمت تکراری کاربر را با یک دکمه فعال سازی مجدد نمایش دهید.

در بیشتر مواقع، می خواهید همان قیمت و SKU را به کاربر ارائه دهید که قبلاً مشترک آن بوده است، به شرح زیر:

• خرید اشتراک جدیدی را با همان SKU آغاز کنید.
• اشتراک جدید جایگزین اشتراک قبلی می شود و در همان تاریخ انقضا تمدید می شود. اشتراک قدیمی بلافاصله به عنوان منقضی شده علامت گذاری می شود.
• به عنوان مثال، آشیل یک اشتراک در Example Music App دارد و قرار است اشتراک در 1 آگوست به پایان برسد. در 10 ژوئیه، او مجدداً اشتراک یک ماهه را با همان قیمت در ماه مشترک می کند. اشتراک جدید با اعتبار باقیمانده تقسیم می شود، بلافاصله فعال است و همچنان در 1 آگوست تمدید می شود.

اگر می‌خواهید قیمت متفاوتی ارائه دهید - به عنوان مثال یک آزمایش رایگان جدید یا یک تخفیف winback - می‌توانید در عوض یک SKU متفاوت به کاربر ارائه دهید:

• با استفاده از حالت جایگزینی WITHOUT_PRORATION ، ارتقا یا تنزل را با SKU های مختلف آغاز کنید.
• اشتراک جدید جایگزین اشتراک قبلی می شود و در همان تاریخ انقضا تمدید می شود. قیمت SKU جدید، از جمله قیمت‌های اولیه، در تاریخ انقضای اصلی از کاربر دریافت می‌شود. اگر اشتراک قدیمی با استفاده از شناسه حساب مبهم ایجاد شده باشد، همان شناسه باید برای ارتقا و تنزل به BillingFlowParams ارسال شود.
• به عنوان مثال، آشیل اشتراکی در Example Music App دارد و قرار است اشتراک در 1 اوت به پایان برسد. در 10 ژوئیه، او مجدداً برای اشتراک سالانه با قیمت مقدماتی مشترک می شود. اشتراک جدید بلافاصله فعال می شود و قیمت اولیه در تاریخ 1 آگوست از کاربر دریافت می شود.
• اگر تصمیم دارید یک نسخه آزمایشی رایگان یا قیمت مقدماتی را در SKU winback خود لحاظ کنید، با برداشتن علامت Allow one trial free per app در کنسول Google Play، اطمینان حاصل کنید که کاربر واجد شرایط است.

هنگامی که رمز خرید را دریافت کردید، خرید را همانطور که با یک اشتراک جدید انجام می دهید پردازش کنید . علاوه بر این، Google Play Developer API یک linkedPurchaseToken در منبع اشتراک برمی‌گرداند. حتماً نشانه های ارائه شده در linkedPurchaseToken را باطل کنید تا اطمینان حاصل کنید که از نشانه قدیمی برای دستیابی به خدمات شما استفاده نمی شود.

قبل از انقضاء اشتراک - در فروشگاه بازی

در حالی که اشتراک لغو شده اما هنوز هم فعال است ، کاربران می توانند با کلیک بر روی Respection (که قبلاً بازیابی شده بودند ) اشتراک را در مرکز اشتراک Google Play بازیابی کنند. این همان اشتراک و نشانه خرید را حفظ می کند.

برای کسب اطلاعات بیشتر در مورد بازیابی اشتراک ها ، به ترمیم ها مراجعه کنید.

پس از انقضاء اشتراک - در برنامه

شما می توانید مشترکین منقضی شده را با استفاده از همان جریان خرید محصول درون برنامه ای برای مشترکین جدید ، در برنامه خود دوباره ثبت کنند. به موارد زیر توجه کنید:

• برای ارائه تخفیف به کاربران ، ممکن است بخواهید شناسه محصول را با قیمت گذاری ویژه برای اشتراک خود ارائه دهید ، همچنین به عنوان SKU Winback نامیده می شود. شما می توانید پیشنهاد را در برنامه خود ارائه دهید ، یا می توانید کاربر را در خارج از برنامه مانند ایمیل به کاربر اطلاع دهید.
• برای شروع اشتراک Winback ، با استفاده از کتابخانه صورتحساب Google Play ، جریان خرید را در برنامه Android خود راه اندازی کنید. این همان فرآیند با اشتراک جدید است ، اما می توانید SKU را که در دسترس کاربر است تعیین کنید.
• اگر تصمیم دارید یک آزمایش رایگان یا قیمت مقدماتی را در Winback SKU خود درج کنید ، اطمینان حاصل کنید که کاربر واجد شرایط با بررسی عدم بررسی اجازه یک آزمایش رایگان برای هر کادر برنامه در کنسول Google Play است ، که کاربر را برای دریافت یک آزمایش رایگان در هر برنامه محدود می کند.
• اگر کاربر به همان SKU بپردازد ، آنها دیگر واجد شرایط آزمایش رایگان یا قیمت مقدماتی نیستند. اطمینان حاصل کنید که UI شما این را منعکس می کند.

هنگامی که نشانه خرید را دریافت می کنید ، خرید را دقیقاً همانطور که می خواهید با یک اشتراک جدید پردازش کنید . شما یک linkedPurchaseToken در منبع اشتراک دریافت نخواهید کرد.

پس از انقضاء اشتراک - در فروشگاه بازی

در صورت فعال بودن ، کاربران می توانند پس از انقضا با کلیک بر روی Respection در مرکز اشتراک Google Play ، تا یک سال پس از انقضا دوباره به همان SKU بپیوندند. این یک اشتراک و خرید جدید ایجاد می کند.

Respection یک خرید خارج از برنامه محسوب می شود ، بنابراین حتماً بهترین روش های انجام خرید خریداری شده از خارج از برنامه خود را دنبال کنید.

اشتراک خود را ارتقا دهید

شما می توانید کدهای تبلیغاتی ایجاد کنید تا به کاربران منتخب یک آزمایش رایگان گسترده در یک اشتراک موجود ارائه دهید. برای کسب اطلاعات بیشتر ، به کدهای تبلیغاتی مراجعه کنید.

برای آزمایش های رایگان ، Google Play تأیید می کند که کاربر قبل از شروع آزمایش رایگان از روش پرداخت معتبر برخوردار است. برخی از کاربران ممکن است این تأیید را به عنوان نگه داشتن یا هزینه روش پرداخت خود مشاهده کنند. این نگهدارنده یا شارژ موقتی است و بعداً معکوس یا بازپرداخت می شود.

پس از پایان دوره آزمایش ، روش پرداخت کاربر برای مبلغ اشتراک کامل شارژ می شود.

اگر کاربر در هر زمان در طول آزمایش رایگان ، اشتراک را لغو کند ، اشتراک تا پایان آزمایش فعال است و با پایان دوره آزمایش رایگان ، آنها شارژ نمی شوند.

لغو ، بازپرداخت یا ابطال

می توانید از API توسعه دهنده Google Play برای لغو ، بازپرداخت یا ابطال اشتراک استفاده کنید. این قابلیت در کنسول Google Play نیز موجود است.

• لغو : کاربران می توانند اشتراک در Google Play را لغو کنند. همچنین می توانید گزینه ای را برای کاربران فراهم کنید تا در برنامه یا وب سایت خود لغو کنند. برنامه شما باید این لغو ها را همانطور که در لغو توضیح داده شده است ، کنترل کنند.
• بازپرداخت : هنگام بازپرداخت ، کاربر می تواند به استفاده از اشتراک ادامه دهد. بازپرداخت می تواند مورد استفاده قرار گیرد اگر به عنوان مثال ، خطای فنی وجود داشته باشد که مانع از دسترسی کاربر به محصول شما شود ، اما خطا برطرف شده است. توجه داشته باشید که برای بازپرداخت بیش از جدیدترین پرداخت ، یا اگر می خواهید بازپرداخت جزئی صادر کنید ، باید از کنسول Google Play استفاده کنید.
• ابطال : هنگامی که شما را ابطال می کنید ، کاربر بلافاصله دسترسی به اشتراک را از دست می دهد. این می تواند مورد استفاده قرار گیرد ، به عنوان مثال ، یک خطای فنی وجود دارد که مانع از دسترسی کاربر به محصول شما می شود و کاربر نمی خواهد استفاده از محصول را ادامه دهد. برنامه شما باید این لغو ها را همانطور که در Revocations توضیح داده شده است ، کنترل کنند.

در جدول زیر تفاوت بین لغو ، بازپرداخت و ابطال نشان داده شده است.

صورتحساب را برای مشترک به تعویق بیندازید

شما می توانید تاریخ صورتحساب بعدی را برای مشترکین تمدید خودکار با استفاده از Purchases.subscriptions:defer . در دوره تعویق ، کاربر با دسترسی کامل در محتوای شما مشترک می شود اما شارژ نمی شود. تاریخ تجدید اشتراک به روز شده است تا تاریخ جدید را منعکس کند.

برای برنامه های پیش پرداخت ، می توانید از API Offer Billing برای تعویق زمان انقضا استفاده کنید.

صورتحساب معوق به شما امکان می دهد موارد زیر را انجام دهید:

• به کاربران دسترسی رایگان به عنوان یک پیشنهاد ویژه ، مانند دادن یک هفته رایگان برای خرید فیلم ، دسترسی رایگان کنید.
• به عنوان یک ژست حسن نیت به مشتریان دسترسی رایگان داشته باشید.

صورتحساب را می توان به اندازه یک روز و تا زمانی که یک سال در هر تماس API به تعویق افتاد ، تعویق کرد. برای به تعویق انداختن صورتحساب حتی بیشتر ، می توانید قبل از رسیدن تاریخ جدید صورتحساب ، دوباره با API تماس بگیرید.

به عنوان نمونه ، دارسی اشتراک ماهانه به محتوای آنلاین برای برنامه فصلنامه ماهیگیری دارد. او به طور معمول در هر ماه 1.25 پوند صورتحساب می شود. در ماه مارس ، وی در یک نظرسنجی آنلاین برای ناشر برنامه شرکت کرد. ناشر با شش هفته رایگان با تعویق پرداخت بعدی تا 15 ماه مه ، که شش هفته پس از تاریخ صدور صورتحساب قبلی او در تاریخ 1 آوریل است ، به او پاداش می دهد. دارسی برای ماه آوریل یا آغاز ماه مه هزینه ای ندارد و هنوز به محتوا دسترسی دارد. در تاریخ 15 ماه مه ، هزینه اشتراک 1.25 پوند معمولی را برای ماه متهم می کند. تاریخ تجدید بعدی وی اکنون 15 ژوئن است.

هنگام تعویق ، ممکن است بخواهید از طریق ایمیل یا در داخل برنامه به کاربر اطلاع دهید تا به آنها اطلاع دهید که تاریخ صورتحساب آنها تغییر کرده است.

رسیدگی به پرداخت پرداخت

اگر مشکلات پرداخت با تمدید اشتراک وجود داشته باشد ، Google به طور دوره ای قبل از لغو تلاش برای تمدید اشتراک برای مدتی است. این دوره بهبودی می تواند شامل یک دوره فضل باشد و به دنبال آن یک دوره نگه داشتن حساب انجام شود. در این مدت ، Google ایمیل ها و اعلان های کاربر را به آنها ارسال می کند و باعث می شود که آنها روش پرداخت خود را به روز کنند.

پس از کاهش پرداخت ، اشتراک در صورت پیکربندی یک دوره فضل وارد می شود. در طول دوره GRACE ، شما باید اطمینان حاصل کنید که کاربر هنوز به حق اشتراک دسترسی دارد.

پس از پایان هر دوره فضل ، اشتراک وارد یک دوره نگه داشتن حساب می شود. در حین نگه داشتن حساب ، باید اطمینان حاصل کنید که کاربر به حق اشتراک دسترسی ندارد.

می توانید طول هر دوره GRACE و نگهدارنده حساب Base Plan Base را در کنسول Google Play مشخص کنید. مشخص کردن طول کمتر از مقادیر پیش فرض ممکن است تعداد اشتراک های دریافت شده از کاهش پرداخت را کاهش دهد.

برای به حداکثر رساندن احتمال بازیابی اشتراک در طی کاهش پرداخت ، می توانید کاربر خود را از مسئله پرداخت مطلع کنید و از آنها بخواهید که آن را برطرف کنند.

شما می توانید این کار را خودتان انجام دهید ، همانطور که در بخش های GRACE و بخش نگهدارنده حساب توضیح داده شده است ، یا می توانید API پیام رسانی درون برنامه را پیاده سازی کنید ، جایی که Google پیامی را برای کاربران در برنامه شما نشان می دهد.

پیام رسانی درون برنامه ای

اگر پیام های درون برنامه ای را با InAppMessageCategoryId.TRANSACTIONAL فعال کرده اید ، Google Play به کاربران پیام رسانی را در طول دوره فضل و نگه داشتن حساب یک بار در روز نشان می دهد و فرصتی را برای آنها فراهم می کند تا بدون ترک برنامه ، پرداخت خود را برطرف کنند.

توصیه می کنیم هر زمان که کاربر برنامه را باز کند ، با این API تماس بگیرید تا مشخص شود که آیا پیام باید نشان داده شود.

اگر کاربر اشتراک خود را با موفقیت بازیابی کند ، شما یک کد پاسخ از SUBSCRIPTION_STATUS_UPDATED به همراه یک نشانه خرید دریافت خواهید کرد. سپس باید از این نشانه خرید استفاده کنید تا با API توسعه دهنده Google Play تماس بگیرید و وضعیت اشتراک را در برنامه خود تازه کنید.

پیام های درون برنامه را ادغام کنید

برای نشان دادن پیام رسانی درون برنامه به کاربر ، از BillingClient.showInAppMessages() استفاده کنید.

در اینجا نمونه ای از تحریک جریان پیام رسانی در برنامه وجود دارد:

val inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build()

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        object : InAppMessageResponseListener() {
            override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
                if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        })

InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build();

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        new InAppMessageResponseListener() {
            @Override
            public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) {
                if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        });

اشتراک معاملات را در انتظار انجام دهید

معاملات در انتظار می تواند در خرید اولیه ، بالا به بالا ، به روزرسانی یا پایین آمدن اتفاق بیفتد. خرید اشتراک قبل از انتقال به SUBSCRIPTION_STATE_ACTIVE با وضعیت SUBSCRIPTION_STATE_PENDING شروع می شود. اگر معامله توسط کاربر منقضی شده یا لغو شود ، به SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED می رود. شما باید و فقط باید پس از اتمام معامله ، حق کاربر را به روز کنید.

تغییر وضعیت اشتراک برای خرید اولیه با معاملات در انتظار ساده است. برنامه شما وقتی کاربر معامله معلق را آغاز می کند ، Purchase با حالت PENDING دریافت می کند. پس از اتمام معامله ، برنامه شما دوباره Purchase با دولت به روز شده برای PURCHASED دریافت می کند. یک پیام SubscriptionNotification با Type SUBSCRIPTION_PURCHASED به مشتری RTDN شما ارسال می شود. برای تأیید خرید ، فرآیند عادی را دنبال کنید ، به کاربر دسترسی پیدا کنید و به محتوا دسترسی پیدا کنید و خرید را تصدیق کنید. اگر معامله منقضی شود یا لغو شود ، یک پیام SubscriptionNotification با نوع SUBSCRIPTION_PENDING_PURCHASE_CANCELED به مشتری RTDN شما ارسال می شود. در چنین مواردی ، کاربر هرگز نباید به محتوا دسترسی پیدا کند.

بالا به بالا ، ارتقا یا پایین آمدن با معاملات در انتظار ، تغییرات حالت را برای اشتراک های قدیمی و جدید شامل می شود. هنگامی که کاربر یک معامله در انتظار بالا ، ارتقاء یا کاهش معاملات را آغاز می کند ، برنامه شما با یک شیء PendingPurchaseUpdate Purchase برای اشتراک قدیمی دریافت می کند. در این زمان ، کاربر هنوز صاحب اشتراک قدیمی است و هنوز اشتراک جدید را به دست نیاورد. فراخوانی getProducts() و getPurchaseToken() در مورد PendingPurchaseUpdate ، شناسه های محصول را برمی گرداند و نشانه اشتراک جدید را خریداری می کند. پس از اتمام معامله ، برنامه شما با استفاده از نشانه خرید سطح بالا برای اشتراک جدید و وضعیت خریداری PURCHASED ، Purchase دریافت می کند. یک پیام SubscriptionNotification با Type SUBSCRIPTION_PURCHASED به مشتری RTDN شما ارسال می شود. فقط در این زمان ، شما باید توکن خرید قدیمی را با نشانه خرید جدید جایگزین کرده و دسترسی کاربر به محتوا را به روز کنید. اگر معامله منقضی شود یا لغو شود ، یک پیام SubscriptionNotification با نوع SUBSCRIPTION_PENDING_PURCHASE_CANCELED به مشتری RTDN شما ارسال می شود. در چنین مواردی ، کاربر هنوز باید به محتوای اشتراک قدیمی دسترسی داشته باشد.

این موضوع نحوه رسیدگی به رویدادهای چرخه عمر اشتراک مانند تجدید و انقضا را شرح می دهد. همچنین ویژگی های اشتراک اضافی مانند ارائه تبلیغات و اجازه کاربران خود را برای مدیریت اشتراک های خود توصیف می کند.

اگر محصولات اشتراک را برای برنامه خود پیکربندی نکرده اید ، به ایجاد و پیکربندی محصولات خود مراجعه کنید.

اشتراک اشتراک

اشتراک مجموعه ای از مزایایی را که کاربران می توانند در یک دوره زمانی مشخص به آن دسترسی پیدا کنند ، نشان می دهد. به عنوان مثال ، یک اشتراک ممکن است به یک کاربر اجازه دسترسی به یک سرویس پخش موسیقی را بدهد.

شما می توانید چندین اشتراک در یک برنامه مشابه داشته باشید ، یا برای نشان دادن مجموعه های مختلف مزایا ، یا ردیف های مختلف یک مجموعه از مزایای واحد (به عنوان مثال ، "نقره" و "طلا").

از طریق برنامه ها و پیشنهادات پایه ، می توانید چندین تنظیم برای همان محصول اشتراک ایجاد کنید. به عنوان مثال ، می توانید برای کاربرانی که هرگز در برنامه شما مشترک نشده اند ، یک پیشنهاد مقدماتی ایجاد کنید. به همین ترتیب ، می توانید برای کاربرانی که قبلاً مشترک شده اند ، یک پیشنهاد ارتقاء ایجاد کنید.

برای بررسی دقیق محصولات اشتراک ، برنامه های پایه و پیشنهادات ، به مستندات موجود در مرکز راهنمای کنسول Play مراجعه کنید.

ادغام برنامه های پیش پرداخت

برنامه های پیش پرداخت به طور خودکار پس از انقضا تمدید نمی شوند. برای گسترش حق اشتراک خود بدون وقفه ، کاربر باید برای همان اشتراک یک برنامه پیش پرداخت را از آن خود کند .

برای بالا به بالا ، جریان صورتحساب را همانطور که می خواهید با خرید اصلی راه اندازی کنید. نیازی نیست که نشان دهید خرید از بالا به بالا است.

برنامه های پیش پرداخت بالا به بالا همیشه از حالت جایگزینی CHARGE_FULL_PRICE استفاده می کنند و نیازی به تنظیم صریح این حالت ندارید. کاربر بلافاصله برای یک دوره صورتحساب کامل شارژ می شود و حق آنها با مدت زمان مشخص شده در بالا به بالا تمدید می شود.

پس از بالا به بالا ، زمینه های زیر در شیء نتیجه Purchase به روز می شوند تا منعکس کننده جدیدترین خرید بالا به بالا باشند:

• شناسه سفارش
• زمان خرید
• امضا
• خرید توکن
• تصدیق کرد

قسمتهای Purchase زیر همیشه حاوی همان داده های موجود در خرید اصلی هستند:

• نام بسته
• حالت خرید
• محصولات
• تجدید خودکار

تأیید خرید پیش پرداخت

مشابه اشتراک های تمدید خودکار ، باید برنامه های پیش پرداخت را پس از خرید تصدیق کنید. هر دو خرید اولیه و هر نوع بالادست باید تصدیق شوند. برای اطلاعات بیشتر ، به پردازش خریدها مراجعه کنید.

با توجه به پتانسیل مدت زمان برنامه پیش پرداخت کوتاه ، مهم است که هرچه سریعتر خرید را تصدیق کنید.

برنامه های پیش پرداخت با مدت یک هفته یا بیشتر باید ظرف سه روز تصدیق شود.

برنامه های پیش پرداخت با مدت زمان کوتاهتر از یک هفته باید در نیمی از مدت زمان برنامه تصدیق شود. به عنوان مثال ، توسعه دهندگان 1.5 روز فرصت دارند تا یک برنامه پیش پرداخت سه روزه را تصدیق کنند.

ادغام اشتراک اقساط

اشتراک اقساطی نوعی اشتراک است که در آن کاربران به جای پرداخت کل هزینه اشتراک به صورت مقدماتی ، اشتراک را در چندین قسط در طی یک دوره زمانی پرداخت می کنند.

ملاحظات اضافی برای اشتراک اقساط:

• در دسترس بودن کشور : ویژگی اشتراک اقساط فقط در برزیل ، فرانسه ، ایتالیا و اسپانیا در دسترس است (برای آخرین در دسترس بودن کنسول را بررسی کنید).
• تنظیم قیمت : هنگام تعیین قیمت برای اشتراک اقساطی روی کنسول ، قیمت مبلغ پرداخت ماهانه را نشان می دهد. این ، همراه با دوره تعهد که تعیین شده است ، کل مبلغ اشتراک در صفحه خرید را تولید می کند.
• دوره تعهد : کل مدت زمان تعهد اشتراک اولیه ، که طی آن به پرداخت ماهانه نیاز است. به عنوان مثال ، اگر یک برنامه پایه یک دوره تعهد 15 ماهه داشته باشد ، کاربر در طی این دوره 15 پرداخت ماهانه انجام می دهد.
• تمدید : در زمینه اشتراک اقساط ، "تجدید" نتیجه گیری یک دوره تعهد ، دوره تعهد اولیه یا دوره تعهد بعدی را نشان می دهد. پس از ثبت نام اولیه ، اولین تجدید پس از اتمام کل دوره تعهد اولیه انجام می شود. تجدید بعدی پس از تحقق هر دوره تعهد بعدی رخ می دهد. انواع تمدید برای اشتراک اقساط می تواند "تمدید ماهانه" یا "تمدید خودکار برای مدت زمان" باشد. برای "ماهانه تمدید خودکار" ، هیچ تعهدی بعدی وجود ندارد و این طرح مانند اشتراک ماهانه رفتار می کند که در آن هر هزینه اشتراک ماهانه تجدید دارد.
• دوره صورتحساب : در زمینه اشتراک های اقساطی ، این به بازه مکرر که در آن پرداخت های فردی انجام می شود ، همانطور که در برنامه پایه مشخص شده است ، اشاره دارد.
• تغییر برنامه در مقابل رفتارهای تغییر قیمت : برای تغییرات قیمت و لغو ، تعهد محکم است. این بدان معناست که اگر کاربر بخواهد لغو کند یا یک توسعه دهنده بخواهد قیمت را تغییر دهد ، تغییر در پایان دوره تعهد عملی می شود. برای تغییرات برنامه ، تعهد محکم نیست. این بدان معناست که تغییر برنامه لازم نیست تا پایان دوره تعهد صبر کند ، بلافاصله یا در تاریخ پرداخت بعدی بر اساس حالت جایگزینی تنظیم می شود.
• تغییر طرح همان مقاله : تغییر برنامه از یک طرح پایه اقساطی به یک برنامه پایه غیر نصب از همان محصول اشتراک یکسان مجاز نیست.

• اعلان های توسعه دهنده در زمان واقعی (RTDN) : یک SUBSCRIPTION_CANCELLATION_SCHEDULED RTDN بلافاصله پس از لغو شروع به کار در هنگام پرداخت هزینه برای دوره تعهد ارسال می شود. لغو در انتظار است و فقط در پایان دوره تعهد عملی خواهد شد. سپس ، اگر توسط کاربر ترمیم نشود ، RTDN های SUBSCRIPTION_CANCELED و SUBSCRIPTION_EXPIRED در پایان دوره تعهد ارسال می شوند.

• پرداخت / تحقق درآمد : پرداخت های توسعه دهنده با توجه به همان شرایط با سایر اشتراک ها ، پرداخت های ماهانه خود را انجام می دهند. هنگامی که کاربر برای اشتراک اقساط ثبت نام کرد ، توسعه دهندگان به صورت مقدماتی پرداخت نمی شوند.

• مجموعه های پرداخت از دست رفته : اگر کاربر نتواند هرگونه پرداخت اشتراک اقساطی را انجام دهد ، نه Google و نه توسعه دهنده سعی در جمع آوری چنین پرداخت های از دست رفته یا برجسته از کاربر نخواهند داشت ، به جز این که Google ممکن است به طور دوره ای پرداخت را در هر دوره GRACE قابل اجرا یا دوره نگهدارنده حساب مطابق با روشهای عادی پرداخت مجدد پرداخت کند. Google مسئولیتی در قبال هرگونه پرداخت بدون پرداخت اقساط بدون پرداخت هزینه نخواهد داشت.

• در دسترس بودن کتابخانه صورتحساب بازی کنید : قسمت installmentDetails فقط برای PBL 7 یا بالاتر در دسترس است. برای PBL 5 و بعد ، اشتراک اقساط با استفاده از queryProductDetails() بازگردانده می شود ، اما این اشتراک شامل اطلاعات مربوط به اقساط دقیق مانند تعداد پرداخت های متعهد از طرح نخواهد بود.

از پیوندهای عمیق استفاده کنید تا کاربران بتوانند اشتراک را مدیریت کنند

برنامه شما باید پیوندی را در صفحه تنظیمات یا تنظیمات تنظیمات قرار دهد که به کاربران امکان می دهد اشتراک های خود را مدیریت کنند ، که می توانید در ظاهر و احساس طبیعی برنامه خود گنجانید.

برای اشتراک های غیر توسعه یافته می توانید یک لینک عمیق از برنامه خود به مرکز اشتراک Google Play وارد کنید ، که می توانید با استفاده از قسمت subscriptionState منبع اشتراک تعیین کنید. بر این اساس ، روش های مختلفی وجود دارد که می توانید به مرکز اشتراک فروشگاه های Play Link پیوند دهید.

پیوند به مرکز اشتراک ها

از URL زیر برای هدایت کاربران به صفحه استفاده کنید که تمام اشتراک های آنها را نشان می دهد ، همانطور که در شکل 1 و 2 نشان داده شده است:

https://play.google.com/store/account/subscriptions

این پیوند عمیق می تواند برای کمک به کاربر برای بازگرداندن اشتراک لغو شده از مرکز اشتراک فروشگاه Play مفید باشد.

پیوند به یک صفحه مدیریت اشتراک خاص (توصیه می شود)

برای پیوند مستقیم به صفحه مدیریت برای اشتراک غیر گسترده ، نام بسته و productId مرتبط با اشتراک خریداری شده را نشان دهید. برای تعیین برنامه نویسی productId برای اشتراک موجود ، از پس زمینه برنامه خود پرسید یا با BillingClient.queryPurchasesAsync() تماس بگیرید تا لیستی از اشتراک های مرتبط با یک کاربر خاص داشته باشید. هر اشتراک شامل productId مربوطه به عنوان بخشی از اطلاعات وضعیت اشتراک است. هر شیء SubscriptionPurchaseLineItem مرتبط با خرید اشتراک شامل مقدار productId مرتبط با اشتراک که کاربر در آن کالای خط خریداری کرده است.

از URL زیر استفاده کنید تا کاربران را به یک صفحه نمایش خاص مدیریت اشتراک هدایت کنید ، و جایگزین "-Sub-Product-ID" و "بسته بندی برنامه" خود با نام productId و بسته برنامه:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

کاربر سپس قادر به مدیریت روش های پرداخت و ویژگی های دسترسی از جمله لغو ، ارسال مجدد و مکث است.

به کاربران اجازه دهید اشتراک خود را به روزرسانی ، کاهش یا تغییر دهند

شما می توانید به مشترکان موجود گزینه های مختلفی را برای تغییر برنامه اشتراک خود برای تأمین بهتر نیازهای آنها ارائه دهید:

• اگر چندین ردیف اشتراک مانند اشتراک های "اساسی" و "حق بیمه" را به فروش می رسانید ، می توانید به کاربران اجازه دهید تا با خرید برنامه یا پیشنهاد مشترک یک اشتراک متفاوت ، لایه ها را تغییر دهند.
• شما می توانید به کاربران اجازه دهید دوره صورتحساب فعلی خود را تغییر دهند ، مانند تغییر ماهانه به یک برنامه سالانه.
• همچنین می توانید به کاربران اجازه دهید بین برنامه های تمدید خودکار و پیش پرداخت تغییر کنند.

شما می توانید با ارائه پیشنهادات اشتراک برای ارائه تخفیف برای کاربران واجد شرایط ، هر یک از این تغییرات را تشویق کنید. به عنوان مثال ، شما می توانید در هنگام جابجایی از ماهانه به یک برنامه سالانه ، 50 ٪ تخفیف در سال اول تخفیف ایجاد کنید و این پیشنهاد را برای کاربران مشترک در یک برنامه ماهانه که این پیشنهاد را خریداری نکرده اند ، محدود کنید. اطلاعات بیشتر در مورد معیارهای واجد شرایط بودن در مرکز راهنما در دسترس است

شکل 3 یک برنامه مثال با سه برنامه مختلف را نشان می دهد:

برنامه شما می تواند یک صفحه نمایش مشابه شکل 3 را نشان دهد و به کاربران گزینه های خود را برای تغییر اشتراک خود نشان می دهد. در همه موارد ، باید برای کاربران مشخص شود که برنامه اشتراک فعلی آنها چیست و چه گزینه هایی برای تغییر آن دارند.

هنگامی که کاربران تصمیم به به روزرسانی ، کاهش یا تغییر اشتراک خود می گیرند ، شما یک حالت جایگزینی را مشخص می کنید که تعیین می کند چگونه ارزش پیش بینی شده در دوره صورتحساب فعلی پرداخت شده و چه موقع تغییر حق وجود دارد.

حالت های تعویض

در جدول زیر حالت های جایگزینی موجود و استفاده از مثال و تعداد پرداخت های در نظر گرفته شده در نظر گرفته شده است.

برای کسب اطلاعات بیشتر در مورد برنامه های مختلف Upsell و Winback از پیشنهادات ارتقا یا پایین ، راهنمای پیشنهادات و تبلیغات را بخوانید.

حالت جایگزینی را برای خرید تنظیم کنید

شما می توانید بر اساس ترجیحات و منطق تجاری خود از حالت های جایگزینی مختلف برای انواع مختلف انتقال اشتراک استفاده کنید. این بخش نحوه تنظیم حالت جایگزینی برای تغییر در اشتراک و محدودیت های اعمال شده را توضیح می دهد.

برنامه ها را در همان اشتراک مجدداً ارسال کنید یا سوئیچ کنید

می توانید یک حالت جایگزینی پیش فرض را در کنسول Google Play مشخص کنید. این تنظیم به شما امکان می دهد در صورت خرید یک برنامه پایه متفاوت یا پیشنهاد برای همان اشتراک یا پس از لغو ، مشترکین فعلی را شارژ کنید. گزینه های موجود بلافاصله شارژ می شوند ، معادل CHARGE_FULL_PRICE و در تاریخ صورتحساب بعدی ، معادل WITHOUT_PRORATION شارژ می شوند. این تنها حالت های جایگزینی مربوطه هنگام تعویض برنامه های پایه در همان اشتراک هستند.

به عنوان مثال ، اگر پس از لغو کاربر ، پیشنهاد Winback را برای همان طرح اجرا می کنید اما قبل از پایان اشتراک ، می توانید خرید جدید را به عنوان یک خرید منظم پردازش کنید بدون اینکه هیچ مقدار در SubscriptionUpdateParams نشان دهید. این سیستم از حالت جایگزینی پیش فرض که در اشتراک پیکربندی کرده اید استفاده می کند و به طور خودکار انتقال برنامه از خرید قدیمی به خرید جدید را کنترل می کند.

برنامه ها را در میان اشتراک ها تغییر دهید ، یا حالت جایگزینی پیش فرض را نادیده بگیرید

اگر کاربر در حال تغییر محصولات اشتراکی است - خرید اشتراک متفاوت - یا اگر می خواهید به هر دلیلی حالت جایگزینی پیش فرض را نادیده بگیرید ، نرخ پیش بینی را در زمان اجرا به عنوان بخشی از پارامترهای جریان خرید مشخص می کنید.

برای تهیه صحیح SubscriptionUpdateParams به عنوان بخشی از پیکربندی جریان خرید زمان اجرا ، به محدودیت های زیر توجه کنید:

• هنگام به روزرسانی ، کاهش یا شروع انجام یک سوئیچ همان مقاله به یک برنامه پیش پرداخت از یک برنامه پیش پرداخت ، برنامه تمدید خودکار یا برنامه اقساطی ، تنها حالت جایگزینی مجاز CHARGE_FULL_PRICE است. اگر هر حالت جایگزینی دیگر را مشخص کنید ، خرید از بین می رود و خطایی به کاربر نشان داده می شود.
• هنگام تعویض برنامه ها در همان اشتراک به یک برنامه تمدید خودکار از یک برنامه پیش پرداخت یا یک برنامه تمدید خودکار ، حالت های معتبر Prouration CHARGE_FULL_PRICE و WITHOUT_PRORATION هستند. اگر هر حالت دیگر را مشخص کنید ، خرید از بین می رود و خطایی به کاربر نشان داده می شود.
• تعویض برنامه ها در همان محصول اشتراک از یک برنامه پایه اقساطی به یک برنامه پایه غیر نصب مجاز نیست.

نمونه ها و رفتارهای جایگزینی

برای درک نحوه عملکرد هر حالت proration ، سناریوی زیر را در نظر بگیرید:

Samwise دارای اشتراک در محتوای آنلاین از برنامه Gardener Country است. وی اشتراک ماهانه در نسخه Tier 1 محتوا دارد که فقط متن است. این اشتراک برای او 2 دلار در هر ماه هزینه دارد و در اول ماه تجدید می شود.

در تاریخ 15 آوریل ، Samwise تصمیم گرفت به نسخه سالانه اشتراک Tier 2 ، که شامل به روزرسانی های ویدیویی است و 36 دلار در سال هزینه دارد ، ارتقاء داد.

هنگام به روزرسانی اشتراک ، توسعه دهنده یک حالت proration را انتخاب می کند. در لیست زیر نحوه تأثیر هر حالت proration بر اشتراک Samwise توضیح می دهد:

WITH_TIME_PRORATION

اشتراک Samwise's Tier 1 بلافاصله به پایان می رسد. از آنجا که او یک ماه کامل (1-30 آوریل) را پرداخت کرد اما در نیمه راه در طول دوره اشتراک ، نیمی از اشتراک ماه (1 دلار) به اشتراک جدید وی اعمال می شود. با این حال ، از آنجا که این اشتراک جدید 36 دلار در سال هزینه دارد ، 1 دلار مانده اعتبار فقط 10 روز (16-25 آوریل) پرداخت می کند. بنابراین در تاریخ 26 آوریل ، وی 36 دلار برای اشتراک جدید و 36 دلار دیگر در تاریخ 26 آوریل هر سال پس از آن هزینه می شود.

شما باید لحظه ای که خرید موفق می شود ، PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از یک تماس queryPurchasesAsync() بازیابی کنید. با باطن شما بلافاصله یک اعلان توسعه دهنده زمان SUBSCRIPTION_PURCHASED را دریافت می کند.

CHARGE_PRORATED_PRICE

این حالت می تواند مورد استفاده قرار گیرد زیرا قیمت اشتراک Tier 2 در هر واحد زمان (36 دلار در سال = 3 دلار در ماه) از قیمت اشتراک Tier 1 در هر واحد زمان (2 دلار در ماه) بیشتر است. اشتراک Samwise's Tier 1 بلافاصله به پایان می رسد. از آنجا که او یک ماه کامل را پرداخت می کرد اما تنها نیمی از آن را استفاده می کرد ، نیمی از اشتراک ماه (1 دلار) برای اشتراک جدید وی اعمال می شود. با این حال ، از آنجا که این اشتراک جدید 36 دلار در سال هزینه دارد ، 15 روز باقیمانده 1.50 دلار هزینه دارد. بنابراین برای اشتراک جدید خود تفاوت 0.50 دلار را متهم می کند. در اول ماه مه ، Samwise 36 دلار برای ردیف اشتراک جدید خود و 36 دلار دیگر در تاریخ 1 مه هر سال پس از آن هزینه می شود.

شما باید لحظه ای که خرید موفق می شود ، PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از یک تماس queryPurchasesAsync() بازیابی کنید. با باطن شما بلافاصله یک اعلان توسعه دهنده زمان SUBSCRIPTION_PURCHASED را دریافت می کند.

WITHOUT_PRORATION

اشتراک Samwise's Tier 1 بلافاصله بدون هزینه اضافی به ردیف 2 ارتقا می یابد و در اول ماه مه به وی 36 دلار برای ردیف اشتراک جدید خود و 36 دلار دیگر در تاریخ 1 مه هر سال پس از آن پرداخت می شود.

شما باید لحظه ای که خرید موفق می شود ، PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از یک تماس queryPurchasesAsync() بازیابی کنید. با باطن شما بلافاصله یک اعلان توسعه دهنده زمان SUBSCRIPTION_PURCHASED را دریافت می کند.

DEFERRED

اشتراک Samwise's Tier 1 تا زمانی که در تاریخ 30 آوریل منقضی شود ، ادامه می یابد. در تاریخ 1 مه ، اشتراک Tier 2 به اجرا در می آید و Samwise 36 دلار برای ردیف اشتراک جدید خود شارژ می شود.

شما باید لحظه ای که خرید موفق می شود ، PurchasesUpdatedListener برنامه خود تماس بگیرید و می توانید خرید جدید را به عنوان بخشی از یک تماس queryPurchasesAsync() بازیابی کنید. با باطن شما بلافاصله یک اعلان توسعه دهنده زمان SUBSCRIPTION_PURCHASED را دریافت می کند. شما باید خرید را به همان روشی که می توانید هر خرید جدید دیگری را در آن مرحله پردازش کنید ، پردازش کنید . به طور خاص ، مطمئن شوید که خرید جدید را تصدیق می کنید. توجه داشته باشید که startTime اشتراک جدید در لحظه ای که تعویض مؤثر است ، جمع می شود ، که با انقضای اشتراک قدیمی اتفاق می افتد. در آن مرحله ، شما برای برنامه اشتراک جدید یک RTDN SUBSCRIPTION_RENEWED دریافت می کنید. اطلاعات بیشتر در مورد جایگزین ReplacementMode.DEFERRED در تعویض معوق را بخوانید.

CHARGE_FULL_PRICE

Samwise's Tier 1 subscription ends immediately. His Tier 2 subscription begins today and he is charged $36. Because he paid for a full month but used only half of it, half of a month's subscription ($1) is applied to his new subscription. Because that new subscription costs $36/year, he would get 1/36th of a year added on to his subscription period (~10 days). Therefore, Samwise's next charge would be 1 year and 10 days from today for $36. After that, he is charged $36 each year following.

When choosing a proration mode, be sure to review our replacement recommendations .

Trigger subscription changes in-app

Your app can offer users an upgrade or downgrade using the same steps as with launching a purchase flow . However, when upgrading or downgrading, you need to provide details for the current subscription, the future (upgraded or downgraded) subscription, and the replacement mode to use, as shown in the following example:

val offerToken = productDetails
        .getSubscriptionOfferDetails(selectedOfferIndex)
        .getOfferToken()

val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList(
       listOf(
           BillingFlowParams.ProductDetailsParams.newBuilder()
               .setProductDetails(productDetails)
               .setOfferToken(offerToken)
               .build()
       )
       ).setSubscriptionUpdateParams(
           BillingFlowParams.SubscriptionUpdateParams.newBuilder()
               .setOldPurchaseToken("old_purchase_token")
               .setSubscriptionReplacementMode(
                 BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE
               )
               .build()
       ).build()

billingClient.launchBillingFlow(
    activity,
    billingParams
   )
// ...

String offerToken = productDetails
    .getSubscriptionOfferDetails(selectedOfferIndex)
    .getOfferToken();

BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        ImmuableList.of(
            ProductDetailsParams.newBuilder()
                // fetched via queryProductDetailsAsync
                .setProductDetails(productDetails)
                // offerToken can be found in
                // ProductDetails=>SubscriptionOfferDetails
                .setOfferToken(offerToken)
                .build()))
    .setSubscriptionUpdateParams(
        SubscriptionUpdateParams.newBuilder()
            // purchaseToken can be found in Purchase#getPurchaseToken
            .setOldPurchaseToken("old_purchase_token")
            .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE)
            .build())
    .build();

BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
// ...

Replacement recommendations

The following table shows diferrent proration scenarios along with what we recommend for each scenario:

Handle subscription change purchases

Changes of plan are new purchases for all terms and purposes, and they should be processed and acknowledged as such after the billing flow completes successfully. In addition to processing the new purchase appropriately, you have to retire the purchase that is being replaced.

The in-app behavior is the same as for any new purchase. Your app receives the outcome of the new purchase in your PurchasesUpdatedListener , and the new purchase is available in queryPurchasesAsync .

The Google Play Developer API returns a linkedPurchaseToken in the subscription resource when a purchase replaces an existing one. Be sure to invalidate the token provided in the linkedPurchaseToken to ensure that the old token is not used to gain access to your services. See Upgrades, downgrades, and resignups for information on handling upgrade and downgrade purchases.

When you receive the new purchase token, follow the same verification process as with verifying a new purchase token . Make sure to acknowledge these purchases with BillingClient.acknowledgePurchase() from the Google Play Billing Library or Purchases.subscriptions:acknowledge from the Google Play Developer API.

Handle deferred replacement

Deferred replacement mode lets you let a user use up the remaining entitlement in their old plan before starting on the new plan.

When you use ReplacementMode.DEFERRED for a new purchase, queryPurchasesAsync() returns a new purchase token after the purchase flow that remains associated with the old product until the deferred replacement takes place on the next renewal date, after which the new product is returned.

In the past you could achieve this user experience with the deprecated ProrationMode.DEFERRED , but ProrationMode.DEFERRED is deprecated with Play Billing Library 6. See the following table to understand where the behavior differs:

ReplacementMode.DEFERRED should be used from now on instead of the deprecated ProrationMode.DEFERRED, as it presents the same behavior regarding entitlement changes, but offers a way to manage the purchase that is more consistent with behaviors for other new purchases.

مدیریت مشتری

Using Real-time developer notifications, you can detect in real time when a user decides to cancel. When a user cancels, but before their subscription has expired, you can send them push notifications or in-app messages to ask them to resubscribe.

After a user has cancelled their subscription, you can try to win them back either in your app, or through the Play store. The following table describes various subscription scenarios along with associated winback actions and app requirements.

Before subscription expiration - in-app

For subscriptions that have been canceled but have not yet expired, you can allow subscribers to restore their subscription within your app by applying the same in-app product purchase flow as for new subscribers. Ensure your UI reflects that the user has an existing subscription. For example, you might want to display the user's current expiration date and recurring price with a Reactivate button.

Most of the time, you will want to offer the user the same price and SKU they were already subscribed to, as follows:

• Initiate a new subscription purchase with the same SKU.
• The new subscription replaces the old one and renews on the same expiration date. The old subscription is immediately marked as expired.
• As an example, Achilles has a subscription to Example Music App, and the subscription is due to expire on August 1. On July 10, he resubscribes to the one-month subscription at the same price per month. The new subscription is prorated with the remaining credit, is immediately active, and still renews on August 1.

If you would like to offer a different price—for example a new free trial or a winback discount—you can instead offer a different SKU to the user:

• Initiate an upgrade or downgrade with the different SKU using the replacement mode WITHOUT_PRORATION .
• The new subscription replaces the old one and renews on the same expiration date. The user is charged the price of the new SKU, including any introductory prices, on the original expiration date. If the old subscription was created using an obfuscated account id, that same id should be passed to the BillingFlowParams for upgrades and downgrades.
• As an example, Achilles has a subscription to Example Music App, and the subscription is due to expire on August 1. On July 10, he resubscribes to an annual subscription with an introductory price. The new subscription is immediately active, and the user is charged the introductory price on August 1.
• If you decide to include a free trial or intro price in your winback SKU, ensure that the user is eligible by unchecking the Allow one free trial per app box in the Google Play Console, which restricts the user to getting one free trial per app.

When you receive the purchase token, process the purchase just as you would with a new subscription. Additionally, the Google Play Developer API returns a linkedPurchaseToken in the subscription resource. Be sure to invalidate the token provided in the linkedPurchaseToken to ensure that the old token is not used to gain access to your services.

Before subscription expiration - in Play Store

While the subscription is canceled but still active, users can restore the subscription in the Google Play subscriptions center by clicking Resubscribe (previously Restore ). This keeps the same subscription and purchase token.

For more information on restoring subscriptions, see Restorations .

After subscription expiration - in-app

You can allow expired subscribers to resubscribe within your app by applying the same in-app product purchase flow as for new subscribers. به موارد زیر توجه کنید:

• To offer users a discount, you might want to offer a product ID with special pricing for your subscription, also called a winback SKU . You can provide the offer in your app, or you can notify the user of the offer outside of the app, such as in email.
• To start a winback subscription, launch the purchase flow in your Android app using the Google Play Billing Library. This is the same process as with a new subscription, but you can determine the SKU that is available to the user.
• If you decide to include a free trial or intro price in your winback SKU, ensure that the user is eligible by unchecking the Allow one free trial per app box in the Google Play Console, which restricts the user to getting one free trial per app.
• If the user resubscribes to the same SKU, they are no longer eligible for free trials or introductory price. Ensure that your UI reflects this.

When you receive the purchase token, process the purchase just as you would with a new subscription. You will not receive a linkedPurchaseToken in the subscription resource.

After subscription expiration - in Play Store

If enabled, users can resubscribe to the same SKU for up to one year after expiration by clicking Resubscribe in the Google Play subscriptions center. This generates a new subscription and purchase token.

Resubscribing is considered an out-of-app purchase, so be sure to follow best practices for handling purchases made from outside your app .

Promote your subscription

You can create promotion codes to give selected users an extended free trial to an existing subscription. To learn more, see Promo codes .

For free trials, Google Play verifies that the user has a valid payment method before starting the free trial. Some users may see this verification as a hold or charge on their payment method. This hold or charge is temporary and is later reversed or refunded.

After the trial period ends, the user's payment method is charged for the full subscription amount.

If a user cancels a subscription at any time during the free trial, the subscription remains active until the end of the trial, and they aren't charged when the free trial period ends.

Cancel, refund, or revoke

You can use the Google Play Developer API to cancel , refund , or revoke a subscription. This functionality is also available in the Google Play Console .

• Cancel : Users can cancel a subscription on Google Play. You can also provide an option for users to cancel in your app or on your website. Your app should handle these cancellations as described in Cancellations .
• Refund : When you refund, the user can continue to use the subscription. Refunds can be used if, for example, there was a technical error that prevented the user from accessing your product, but the error has been resolved. Note that to refund more than the most recent payment, or if you want to issue a partial refund, you must use the Google Play Console.
• Revoke : When you revoke, the user immediately loses access to the subscription. This can be used if, for example, there was a technical error that prevented the user from accessing your product, and the user does not want to continue using the product. Your app should handle these cancellations as described in Revocations .

The following table illustrates the differences between cancel, refund, and revoke.

Defer billing for a subscriber

You can advance the next billing date for an auto-renewing subscriber by using Purchases.subscriptions:defer from the Google Play Developer API. During the deferral period, the user is subscribed to your content with full access but is not charged. The subscription renewal date is updated to reflect the new date.

For prepaid plans, you can use the defer billing API to defer the expiration time.

Deferred billing allows you to do the following:

• Give users free access as a special offer, such as giving one week free for purchasing a movie.
• Give free access to customers as a gesture of goodwill.

Billing can be deferred by as little as one day and by as long as one year per API call. To defer the billing even further, you can call the API again before the new billing date arrives.

As an example, Darcy has a monthly subscription to online content for the Fishing Quarterly app. She is normally billed £1.25 on the first of each month. In March, she participated in an online survey for the app publisher. The publisher rewards her with six free weeks by deferring the next payment until May 15, which is six weeks after her previously scheduled billing date of April 1. Darcy is not charged for April or the beginning of May and still has access to the content. On May 15, she is charged the normal £1.25 subscription fee for the month. Her next renewal date is now June 15.

When deferring, you might want to notify the user by email or within the app to notify them that their billing date has changed.

Handling payment declines

If there are payment issues with a subscription renewal, Google will periodically attempt to renew the subscription for some time before canceling. This recovery period can consists of a grace period, followed by an account hold period. During this time, Google sends the user emails and notifications prompting them to update their payment method.

Upon payment decline, the subscription enters a grace period if one is configured. During the grace period, you should ensure the user still has access to the subscription entitlements.

After any grace period has ended, the subscription enters an account hold period. During account hold, you should ensure the user does not have access to the subscription entitlements.

You can specify the length of each auto-renewing base plan's grace period and account hold in the Google Play Console. Specifying lengths less than the default values may reduce the number of subscriptions recovered from payment declines.

To maximize the likelihood of subscription recovery during a payment decline, you can inform your user of a payment issue and ask them to fix it.

You can either do this yourself, as described in the grace period and account hold sections, or you can implement the in-app messaging API, where Google shows a message to users in your app.

پیام رسانی درون برنامه ای

If you've enabled in-app messaging with InAppMessageCategoryId.TRANSACTIONAL , Google Play will show users messaging during grace period and account hold once per day and provide them an opportunity to fix their payment without leaving the app.

We recommend that you call this API whenever the user opens the app to determine whether the message should be shown.

If the user successfully recovered their subscription, you will receive a response code of SUBSCRIPTION_STATUS_UPDATED along with a purchase token. You should then use this purchase token to call the Google Play Developer API and refresh the subscription status in your app.

Integrate in-app messaging

To show in-app messaging to user, use BillingClient.showInAppMessages() .

Here is an example of triggering the in-app messaging flow:

val inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build()

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        object : InAppMessageResponseListener() {
            override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
                if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        })

InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build();

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        new InAppMessageResponseListener() {
            @Override
            public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) {
                if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        });

Handle subscription pending transactions

Pending transactions can happen in initial purchase, top-up, upgrade or downgrade. The subscription purchase starts with the SUBSCRIPTION_STATE_PENDING state before transitioning to SUBSCRIPTION_STATE_ACTIVE . If the transaction is expired or canceled by the user, it goes to SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED . You must and should only update the user's entitlement after the transaction is completed.

Subscription state change for initial purchase with pending transactions is straightforward. Your app receives a Purchase with PENDING state when the user initiates a pending transaction. When the transaction is completed, your app receives the Purchase again with state updated to PURCHASED . A SubscriptionNotification message with type SUBSCRIPTION_PURCHASED is sent to your RTDN client. Follow the normal process to verify the purchase, give the user access to the content and acknowledge the purchase. If the transaction expires or is canceled, a SubscriptionNotification message with type SUBSCRIPTION_PENDING_PURCHASE_CANCELED is sent to your RTDN client. In such cases, the user should never have gained access to the content.

Top-up, upgrade or downgrade with pending transactions involves state changes for both the old and new subscriptions. When the user initiates a pending top-up, upgrade or downgrade transaction, your app receives a Purchase for the old subscription with a PendingPurchaseUpdate object. At this time, the user is still owning the old subscription and has not gained the new subscription yet. Calling getProducts() and getPurchaseToken() on the PendingPurchaseUpdate object returns the product ids and purchase token of the new subscription. When the transaction is completed, your app receives a Purchase with the top-level purchase token set for the new subscription and the state set to PURCHASED . A SubscriptionNotification message with type SUBSCRIPTION_PURCHASED is sent to your RTDN client. Only at this time, you should replace the old purchase token with the new purchase token and update the user's access to the content. If the transaction expires or is canceled, a SubscriptionNotification message with type SUBSCRIPTION_PENDING_PURCHASE_CANCELED is sent to your RTDN client. In such cases, the user should still have access to the content of the old subscription.