Jei dirbate su pirkimais programose „Android“ sistemoje, anksčiau ar vėliau turėsite susidurti su tuo, „Google Play“ atsiskaitymo biblioteka, 7 versijaTai ne šiaip eilinis atnaujinimas: jis apima API pakeitimus, naujas prenumeratos funkcijas, konsolės reikalavimus ir labai aiškius „Google“ terminus. Nepaisyti jo nebėra įmanoma, jei norite ir toliau publikuoti ar atnaujinti savo programėlę „Google Play“ be jokių netikėtumų.
Visame šiame straipsnyje pamatysite, kaip Atnaujinkite ir įdiekite „Google Play“ atsiskaitymo bibliotekos 7 versiją Žingsnis po žingsnio: nuo PBL 5 ir 6 skirtumų iki prenumeratų, vienkartinių pirkinių, RTDN integravimo, testavimo su „Play Billing Lab“ ir išlikimo tokiose ekosistemose kaip .NET MAUI, kur oficiali pagalba atsilieka. Idėja ta, kad perskaitę galėsite užtikrintai ir neišleisdami nė cento pasiruošti migracijai.
„Google Play“ atsiskaitymo bibliotekos 7 versijos apžvalga
„Google Play“ atsiskaitymo biblioteka 7 siūlo reikšmingus sąskaitų tvarkymo patobulinimus Mokėjimai, prenumeratos ir specialūs planaiTačiau jis sukurtas taip, kad perkėlimas būtų gana sklandus. Geros žinios yra tai, kad daugelis naujųjų API yra neprivalomos: galite atnaujinti priklausomybę, pakoreguoti kelias nuorodas, o pagrindinė integracija vis tiek veiks.
Šioje versijoje daugiausia dėmesio skiriama trims pagrindinėms sritims: naujos prenumeratos parinktys (pvz., virtualios kvotos), geresnė parama laukiantys pirkimai pagal išankstinio mokėjimo planusir API pakeitimai, kurie išvalo tai, kas ankstesnėse versijose (PBL 5 ir 6) jau buvo pasenę. Be to, „Google“ pakoreguoja kai kuriuos klaidų tvarkymo būdus ir tai, kaip turėtumėte tvarkyti laukiančius sandorius, kad būtų išvengta neatitikimų.
Norėdami pradėti, savo programos modulyje turite atnaujinti priklausomybę savo faile statyti.grale:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
Kai tai bus padaryta, laikas peržiūrėti kodą, kuris naudoja pasenusias API sąsajas. Daug iškvietimų, susijusių su prenumeratos proporcingas paskirstymas ir alternatyvus atsiskaitymas Jie buvo pervadinti arba pašalinti, todėl prieš kompiliuojant ir įkeliant ką nors į „Play Console“, rekomenduojama atidžiai peržiūrėti visas nuorodas į „BillingClient“ ir „BillingFlowParams“.
Monetizacijos strategijos su vienkartiniais pirkiniais ir prenumeratomis
Kai savo programėlėje parduodate skaitmeninius produktus, neužtenka tiesiog įklijuoti pirkimo dialogo langą ir užbaigti darbą: sukurti sklandi naudotojo patirtis per visą pirkimo cikląTai taikoma tiek atskiriems produktams (tiek vartojamiesiems, tiek nevartojamiesiems), tiek prenumeratoms. Kuo natūralesnis ir sklandesnis procesas, tuo didesnis konversijų skaičius ir mažesnis atšaukimų rodiklis.
Įprastas pirkimo procesas naudojant „Play Billing“, nesvarbu, ar tai prenumerata, ar vienas elementas, paprastai vyksta pagal šiuos aiškiai apibrėžtus etapus, apie kuriuos taip pat turėtų žinoti jūsų serveris:
- Vartotojas peržiūri turimus produktus ir pasirenka vieną.
- Programėlė pradeda „Google Play“ atsiskaitymo procesą, kad užbaigtų mokėjimą.
- Pirkimas baigtas ir jūsų programėlė gauna rezultatą.
- Jūsų serveris patvirtina pirkimą naudodamas „Google Play“ kūrėjo API.
- Atitinkamas turinys arba teisė suteikiami vartotojui jūsų sistemoje.
- „Google“ informuojama, kad pirkimas apdorotas (sunaudotas arba patvirtintas).
Kalbant apie vartojimo prekes, labai svarbu, kad suvartoti žetoną tinkamu laiku kad būtų galima sklandžiai pirkti iš naujo ir padėti Blokuoti atsitiktinius pirkimus „Google Play“ parduotuvėjePrenumeratose turite kontroliuoti atnaujinimus, atidėjimo laikotarpius, sustabdymus ir atšaukimus, kad vartotojas gautų būtent tai, už ką sumokėjo, ir nė viena diena mažiau.
Integracija į programėlę yra tik pusė darbo: jūsų serveris turi palaikyti patikimas teisių ir pirkimo būsenų įrašasTai ypač svarbu, jei siūlote prieigą keliose platformose arba jums reikia išsamios statistikos apie pajamas, klientų išlaikymą ir klientų praradimą. Čia praverčia realaus laiko kūrėjų pranešimai (RTDN), kurie veikia kaip pirkimo gyvavimo ciklo „juodoji dėžė“.
Naudodami RTDN galite beveik realiuoju laiku reaguoti į svarbius įvykius: naują pirkinį, atnaujinimo nesėkmę, prenumeratos atidėjimo laikotarpį arba atšauktą pirkimą. Tai leidžia jums kurti strategijas, skirtas abonentų atkūrimas ir sukčiavimo prevencija, pavyzdžiui, automatinis el. laiško siuntimas, kai mokėjimas nepavyksta, arba teisių koregavimas, jei klientas negauna pranešimo dėl tinklo problemų.
Realiojo laiko kūrėjų pranešimai (RTDN) ir „Google Cloud Pub/Sub“
RTDN naudojimas Google Cloud Pub/Sub kaip realiuoju laiku veikianti pranešimų sistema tarp „Google Play“ ir jūsų vidinės sistemos. „Google Play“ skelbia įvykius, susijusius su publikavimo / prenumeratos tema, o jūs užsiprenumeruojate tą temą, kad gautumėte pranešimus, kai pasikeičia pirkinio ar prenumeratos būsena.
Pagrindinis procesas paprastas: „Google Play“ siunčia „base64“ koduotę turintį pranešimą į „Pub/Sub“ temą, jūsų prenumeratorius jį išskleidžia, dekoduoja ir apdoroja pranešimą. Lauke data Žinutėje rasite JSON objektą Kūrėjo pranešimaskuri apima tokią informaciją kaip pranešimo versija, paketo pavadinimas, įvykio laikas ir konkretūs duomenys apie vienkartinius pirkimus, prenumeratas, atšauktus pirkimus ar bandomąsias versijas.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Dėl šių pranešimų galite Sinchronizuokite savo vidinę sistemą, net jei vartotojo įrenginys sugendaĮsivaizduokite, kad vartotojas sėkmingai atlieka pirkimą, „Google Play“ tai patvirtina, bet mobilusis įrenginys praranda ryšį prieš tai, kai jūsų programa gauna atgalinį iškvietimą iš atsiskaitymo bibliotekos. Be RTDN, galite niekada nežinoti. Naudojant „Pub/Sub“, jūsų serveris gauna atskirą pranešimą ir gali suteikti teises nepriklausomai nuo kliento.
Debesijos publikavimo / subtitravimo konfigūracija RTDN
Prieš aktyvuodami RTDN „Google Play“ konsolėje, turite paruošti projektą „Google Cloud Platform“ (GSP) ir ten sukonfigūruokite „Pub/Sub“. Procesas yra gana paprastas, tačiau geriausia jį atidžiai atlikti, kad išvengtumėte netikėtumų dėl leidimų ar išteklių pavadinimų.
Temos kūrimas
Pirmiausia turite sukurti Publikacijos/prenumeratos tema kuris veiks kaip jūsų „Google Play“ publikavimo vieta. „Google Cloud“ konsolėje pasirinkite savo projektą, eikite į skiltį „Pub/Prenumerata“ ir sukurkite naują temą vadovaudamiesi oficialiu „temos kūrimo“ vadovu. Rezultatas turės pavadinimą tokiu formatu:
projects/{project_id}/topics/{topic_name}
Šį pilną vardą ir pavardę turėsite įklijuoti į „Play Console“, kai aktyvuosite pranešimus.
Prenumeratos kūrimas
Norėdami perskaityti šios temos pranešimus, jums reikia Publikacijos / prenumeratos prenumerataGalite jį sukonfigūruoti kaip stumti arba kaip trauktiNuorodų kodų laboratorijoje dirbame su „pull“ prenumerata, kai jūsų serveris inicijuoja užklausas gauti pranešimus.
Turėtumėte peržiūrėti „Cloud Pub/Sub“ prenumeratorių vadove pateiktas parinktis, kad nuspręstumėte, ar jūsų architektūrai labiau tinka „push“, ar „pull“ tipo prijungimas. Kai nuspręsite, vadovaukitės „pridėti prenumeratą“ dokumentacija ir susiekite ją su anksčiau sukurta tema. Nuo to momento visi „Google Play“ temoje skelbiami pranešimai bus pasiekiami jūsų prenumeratoriui.
„Google Play“ leidimai publikuoti jūsų temoje
„Pub/Sub“ neleis „Google Play“ nieko skelbti, nebent duosite aiškų leidimą. paslaugos paskyra„Google Cloud“ konsolėje turite pereiti prie temos leidimų nustatymų ir pridėti pagrindinį:
[email protected]
Suteikite šiai paskyrai vaidmenį Pub/Prenumeratos leidėjas (Leidėjas). Išsaugokite pakeitimus ir nuo to momento „Google Play“ galės siųsti RTDN į jūsų temą be autorizacijos problemų.
Aktyvuokite RTDN sistemoje „Google Play Console“
Sukonfigūravę „Pub/Sub“, turite nurodyti „Play Console“, kur siųsti pranešimus. Savo programėlėje „Google Play Console“ eikite į Pajamų gavimas naudojant „Play“ > Pajamų gavimo nustatymai ir raskite skiltį „Greitasis kūrėjo pranešimas“.
Ten jums reikės:
- Pažymėkite langelį, kad įgalintumėte pranešimus realiuoju laiku.
- Įveskite visą publikavimo/prenumeratos temos pavadinimą atitinkamame lauke, laikydamiesi formato
projects/{project_id}/topics/{topic_name}. - Išsiųskite bandomąjį pranešimą naudodami bandymo mygtuką.
Bandomasis pranešimas yra būtinas norint patikrinti, ar Integracija yra gerai įdiegta.Jei turite prenumeratą su ištraukimo funkcija, galite apsilankyti debesies konsolėje, pasirinkti prenumeratą, spustelėti „Peržiūrėti pranešimus“ ir išskleisti bandomąjį pranešimą. Nepamirškite to padaryti ACK bet kokį perskaitytą pranešimą, kad išvengtumėte pakartotinio gavimo.
Jei naudojate tiesiogines prenumeratas, patikrinkite, ar jūsų galinis punktas gauna pranešimą ir atsako galiojančiu HTTP kodu. Jei kas nors nepavyksta, konsolėje publikuojant testą bus rodoma klaida, paprastai susijusi su temos pavadinimu arba paslaugos paskyros leidimais.
Galiausiai galite konfigūruoti, kokio tipo pranešimus norite gauti: tik apie prenumeratas ir atšauktus pirkimus arba visi pranešimai, įskaitant vienkartinius pirkimus (tokie įvykiai kaip „ONE_TIME_PRODUCT_PURCHASED“ ir „ONE_TIME_PRODUCT_CANCELED“). Jei taip pat naudojate unikalius produktus, įprasta aktyvuoti visą rinkinį, kad būtų išlaikytas visko matomumas.
Sukurkite „Pub/Sub“ prenumeratorių savo vidinėje sistemoje
Kai tema ir prenumerata paruošti, laikas įdiegti abonentas, kuris skaito ir apdoroja RTDN„Google“ pateikia pavyzdžių keliomis kalbomis; tipiškas atvejis „Java“ kalboje naudoja „Cloud Pub/Sub“ kliento bibliotekas, kad pradėtų Subscriber kuris klausosi žinučių ir skambina MessageReceiver.
Bendras modelis visada tas pats: gaunate pranešimą, iššifruojate lauką data Jūs konvertuojate „base64“ į tekstą, analizuojate JSON ir ištraukiate atitinkamus laukus (pvz., packageName, oneTimeProductNotification o subscriptionNotification) ir nuspręskite, ką daryti savo sistemoje. Sėkmingai apdorojus pranešimą, turite Patvirtinkite pranešimą patvirtinimu kad „Pub/Sub“ jo nebesiųstų.
Pavyzdiniame kode parodyta, kaip imtuvas atspausdina versiją ir paketo pavadinimą, tačiau realiame įgyvendinime reikėtų eiti toliau: Patvirtintumėte pirkimą, suteikdami teisę tinkamam vartotojuiAtnaujintumėte savo duomenų bazę ir, jei reikia, kreiptumėtės į „Play Developer“ API, kad galėtumėte naudoti arba atpažinti pirkinį.
Susieti pranešimus su vartotoju: naudojant „obfuscatedAccountId“
Dažna problema tvarkant pirkimus iš serverio yra žinojimas, kuriam vartotojui priklauso konkretus RTDN pranešimas. Tam „Billing Client“ API leidžia pridėti užmaskuotas paskyros identifikatorius kai paleidžiate pirkimo srautą: obfuscatedAccountId.
Idėja yra ta, kad naudojate stabilų identifikatorių iš savo sistemos (pavyzdžiui, vartotojo vidinį ID), bet užmaskuotas dėl privatumo ir saugumo priežasčiųŠi reikšmė susiejama su pirkiniu ir rodoma „Google Play“ kūrėjo API pateiktoje informacijoje, kad gavę RTDN ir patikrinę prieigos raktą, vienareikšmiškai žinotumėte, kuriai paskyrai savo duomenų bazėje turėtumėte suteikti teisę.
Kliento pusėje, rengiant BillingFlowParamsJums tereikia sudaryti sąrašą ProductDetailsParams ir paskambink setObfuscatedAccountId(obfuscatedAccountId) prieš paleidžiant srautą. Tai nekeičia matomos naudotojo patirties, bet labai supaprastina procesą. vidinės pirkimų paskirstymo logika ir padeda „Google“ aptikti sukčiavimą.
Pirkinių patvirtinimas naudojant „Google Play“ kūrėjo API
Prieš suteikiant bet kokias teises į savo serverį, privaloma patikrinti, ar pirkimas yra teisėtas, paskambinus į „Google Play“ kūrėjo APINepakanka pasikliauti tuo, ką sako klientas ar net RTDN: turite patvirtinti purchaseToken tiesiogiai su oficialiais vertinimo kriterijais ir, jei reikia, valdyti grąžinamąsias išmokas.
Unikalių produktų atveju naudosite galinį tašką purchases.products:getPrenumeratų atveju kelias veda per purchases.subscriptionsv2:getRekomenduojamas srautas yra:
- Ištraukite
purchaseTokeniš „Pub/Sub“ pranešimo. - Patikrinkite savo duomenų bazę, ar jau ją apdorojote; kiekvienas prieigos raktas yra pasauliniu mastu unikalusTaigi, jis puikiai tinka kaip pagrindinis raktas, siekiant išvengti dublikatų.
- Jei tai nauja, iškvieskite „Google Play“ kūrėjo API su paketu, SKU ir
purchaseToken. - Patikrinkite, ar atsakymas rodo pirkimo būseną PIRKTI (nėra LAUKIAMA arba atšaukta).
- Jei viskas sutampa, užregistruokite prieigos raktą ir suteikite atitinkamą teisę susijusiam vartotojui.
Norėdami bendrauti su „Play Developer API“ iš „Java“, galite naudoti „AndroidPublisher“, inicijuotas naudojant paslaugos paskyros kredencialus JSON formatu. Jūs konfigūruojate taikymo sritį AndroidPublisherScopes.ANDROIDPUBLISHERSukuriate klientą ir iškviečiate metodą purchases().products().get(...)Jei skambutis nepavyksta dėl laikino tinklo ar paslaugos sutrikimo, rekomenduojama įgyvendinti pakartotinius bandymus su eksponentiniu atsilikimu kad nepraleistų renginio.
Patvirtinkite arba užbaikite pirkimą iš serverio
Patvirtinę pirkimą ir suteikę autorizaciją savo sistemoje, kitas žingsnis – pranešti „Google“, kad operacija sėkmingai apdorota. Vieno elemento produktams turite dvi galimybes: suvartoti pirkinį O simplemente atpažinti ją.
Vartojimo produktai (pvz., virtuali valiuta, gyvybės ir kt.) turi praeiti per galinį tašką purchases.products:consumeTai pažymi žetoną kaip panaudotą ir leidžia vartotojui iš naujo įsigyti tą patį daiktą be jokių konfliktų. Dėl nesuvartojamų produktų (pvz., norint atrakinti „premium“ versiją visam laikui) turite paskambinti purchases.products:acknowledge, kuris informuoja „Google“, kad naudotojas jau turi susijusią teisę.
Prenumeratos yra naudojamos purchases.subscriptions:acknowledgenurodant, kad prenumerata sėkmingai apdorota ir priskirta naudotojui. Jei per pagrįstą laiką nepatvirtinsite pirkimo, „Google“ gali manyti, kad yra problema, ir atšaukti operaciją, todėl svarbu, kad jūs grąžinimas atliekamas iškart po teisės suteikimo.
„AndroidPublisher“ pagalbinėje programoje galite pridėti tokius metodus kaip executeProductPurchasesConsume y executeProductPurchasesAcknowledge kurie iškviečia atitinkamus galinius taškus. Vėlgi, patartina pakartoti bandymus retkarčiais pasitaikančių gedimų atveju, siekiant užtikrinti, kad joks žetonas neliktų pavojingoje tarpinėje būsenoje.
Išplėstinis testavimas naudojant „Play Billing Lab“
Vienas aspektas, kurį daugelis kūrėjų neįvertina, yra testavimo etapas. Norint paleisti su bent kiek užtikrintumo, reikia mokėti imituoti tinklo klaidos, nestandartiniai atsakymai ir kraštutiniai atvejaiČia praverčia „Play Billing Lab“ – nemokama „Google Play“ programėlė, specialiai sukurta „Play Billing Library“ integracijoms testuoti.
„Play“ atsiskaitymo laboratorijoje yra atsakymų simuliatorius kuris leidžia priversti skirtingus BillingResponseCode jūsų programos iškvietimuose į atsiskaitymo biblioteką. Tokiu būdu galite atkurti scenarijus, kai, pavyzdžiui, klientas negali užbaigti pirkimo dėl tinklo problemos, bet jūsų serveris teisingai apdoroja RTDN ir galiausiai suteikia teisę be vartotojo įsikišimo.
Kad jūsų programa galėtų bendrauti su simuliatoriumi, turite įjungti „atsiskaitymo išrašymo nepaisymo“ testavimą naudodami metaduomenis. 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>
Etiketė „enableBillingOverrides“ testavimas Aktyvuokite imituojamus atsako testus atsiskaitymo bibliotekoje. Žymė NONPRODUCTION yra savotiškas priminimas, kad ši versija neturėtų būti naudojama gamyboje su aktyviais pakeitimais. Rengdami galutinę versiją vartotojams, būtinai Pašalinkite šiuos metaduomenis arba naudokite atskirą manifestą.
Sukonfigūravę, „Play Billing Lab“ programėlėje prisijunkite naudodami licencijos testuotojo paskyrą, suaktyvinkite parinktį „Imituoti „Play Billing Library“ atsakymą“ ir pasirinkite, kuriuos klaidų kodus norite pateikti kiekvienai API (pvz., konkreti klaida consumeAsyncTada tiesiog atidarykite programėlę ir paleiskite norimą išbandyti srautą: simuliatorius grąžins sukonfigūruotus atsakymus ir galėsite patikrinti, ar pakartotinio bandymo logika, klaidų tvarkymas ir RTDN veikia taip, kaip tikėtasi.
Pagrindiniai API pakeitimai perkeliant į „Play Billing Library 7“
Be RTDN ir testavimo, migracija į PBL 7 apima kai kurių konkrečių API klausimų sprendimą. Tiems, kurie pereina iš PBL 5 arba 6, verta peržiūrėti svarbiausius pakeitimus, kad projektas vyktų sklandžiai ir verslo logika išliktų nuosekli.
Pirma, API, susijusios su Proporcingumo režimas Prenumeratos keitimo parinktys buvo pašalintos. Dabar naudojama: Pakeitimo režimas valdyti plano pakeitimus (atnaujinimus, pažeminimus ir pan.). Jei vis dar naudojate tokius metodus kaip setReplaceProrationMode o setReplaceSkusProrationModeTurėsite juos perkelti į naujus variantus setSubscriptionReplacementMode ir pakoreguokite logiką pagal atnaujintą dokumentaciją.
API taip pat buvo pašalinta launchPriceConfirmationFlowkuris jau buvo pažymėtas kaip pasenęs. Norėdami tvarkyti prenumeratos kainų pakeitimus, turėtumėte vadovautis naujais darbo eigomis ir rekomendacijomis kainodaros keitimo vadove, kuriame išsamiai aprašyta, kaip tinkamai informuoti vartotoją ir kaip valdyti sutikimą.
Kitas svarbus dalykas yra Alternatyvios atsiskaitymo APIMetodai BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails išnyko labiau suderintos nomenklatūros naudai: dabar turite naudoti BillingClient.Builder.enableUserChoiceBilling() Kliķe UserChoiceBillingListener y UserChoiceDetailsPasak pačios „Google“, tai iš esmės yra pavadinimo pakeitimas be jokių elgesio pokyčių, kontekste, kuriam būdingi tokie susitarimai kaip „Google“ ir „Epic Games“ susitarė atidaryti „Android“.
Galiausiai įvedamas naujas klaidos kodas. TINKLO_KLAIDA en BillingResultir reikšmes bei sąlygas SERVICE_TIMEOUT ir SERVICE_UNAVAILABLEJei turite pasirinktinę klaidų tvarkymo logiką (pvz., nusprendžiate, kada rodyti pranešimą vartotojui, kada tyliai bandyti dar kartą ir pan.), patartina ją peržiūrėti ir atsižvelgti į šiuos naujus niuansus.
Laukiančios operacijos ir užsakymo ID nebuvimas iki PURCHASED
Subtilus PBL 7 pakeitimas yra tas, kad biblioteka nebegeneruoja Laukiamų pirkimų užsakymo ID. Šiais atvejais, orderId Jis bus pasiekiamas tik tada, kai pirkinys pasieks būseną „ĮSIGYTA“. Tai ypač paveikia darbo eigas, kuriose nuo pat pradžių kaip pagrindinę nuorodą naudojote užsakymo ID.
„Google“ rekomenduoja pasikliauti „purchaseToken“ jūsų įrašams ir suderinimamsbent jau kol laukiama operacijos. Jei radote pirkinį, kuris dingo iš „Play“, patikrinkite Ką daryti, jei pirkinys dingsta.
Jei dar nedirbote su neapmokėtais likučiais, peržiūrėkite Atsiskaitymo bibliotekos integravimo vadovą ir dokumentaciją, esančią adresu viešųjų pirkimų gyvavimo ciklo valdymasTen rasite skirtingas būsenas, kaip į kiekvieną reaguoti ir kaip RTDN telpa į šią dėlionę.
Naujos pasirenkamos PBL 7 funkcijos: virtualūs mokėjimai dalimis ir išankstiniai mokėjimai
Tarp „malonių“ naujų PBL 7 funkcijų yra virtualių mokamų prenumeratų (virtualios prenumeratos dalimis) ir išplėstinė išankstinio mokėjimo prenumeratų laukiančių pirkimų parama. Šios funkcijos nėra privalomos, tačiau jos gali suteikti daugiau lankstumo pritaikant verslo modelį skirtingoms rinkoms.
Virtualūs mokėjimai dalimis leidžia vartotojui mokėti už ilgesnės trukmės prenumeratą maži periodiniai mokėjimai„Google“ paaiškina, kad kūrėjams atsiskaitant ir toliau gaunate mėnesinius mokėjimus pagal metinį planą su mėnesinėmis įmokomis. Jei vartotojas praleidžia mokėjimą, nei jūs, nei „Google“ neturėtumėte bandyti atgauti ankstesnių įmokų. Dėl to praktinis naudojimas yra gana panašus į standartinę mėnesinę prenumeratą, bent jau iš pradžių.
Kol kas šie prenumeratos mokesčiai galimi tik Brazilija, Prancūzija, Italija ir Ispanija„Google“ rekomenduoja stebėti „Play Console“ platformą, kurioje bus atnaujintas palaikymas. Konfigūracija atliekama per ProductDetails.InstallmentPlanDetails ir vadovaudamiesi konkrečiu vadovu, kad juos integruotumėte į savo programėlę.
Lygiagrečiai plečiama parama laukiantys išankstinio mokėjimo prenumeratų pirkimaiDabar galite pasiūlyti modelius, kai vartotojas pradeda pirkimą programėlėje ir vėliau užbaigia mokėjimą kitomis priemonėmis, o atsiskaitymo biblioteka žino, kaip teisingai apdoroti šį srautą. Aktyvinimas atliekamas iškviečiant enablePendingPurchases() inicijuojant „BillingClient“ ir, ypač išankstinio mokėjimo planams, naudojant PendingPurchasesParams.Builder.enablePrepaidPlans().
„Play Billing Library 5“ ir „6“ nusidėvėjimo laikotarpiai
Prasidėjus PBL 7, „Google“ nustatė aiškias datas. 5 ir 6 versijų palaikymo nutraukimasJei vis dar esate bet kuriame iš jų, turite pažymėti kalendorių raudonai:
- „Google Play Billing Library 5“ bus oficialiai nebenaudojama nuo 2024 m. rugpjūčio 31 d., jai nebebus teikiamos naujos programos ir atnaujinimai. Galima prašyti pratęsimo iki 2024 m. lapkričio 1 d., tačiau tuo nereikėtų pasikliauti ilgalaikėje perspektyvoje.
- „Google Play“ atsiskaitymo bibliotekos 6 versiją galima naudoti naujoms programėlėms publikuoti iki 2025 m. rugpjūčio 1 d., o esamoms programėlėms atnaujinti – iki 2025 m. lapkričio 1 d.
Po šios datos, jei neperėjote bent į 6 versiją arba idealiu atveju į 7 versiją, turėsite atnaujinti į naujausią versiją. versija 7„Play Console“ bus užblokuoti atnaujinimai. Nors jūsų programa ir toliau veiks naudotojų įrenginiuose, ji bus užstrigusi ir negalėsite taisyti klaidų ar pridėti naujų funkcijų, kurios priklauso nuo paskelbimo parduotuvėje.
.NET MAUI atvejis ir dabartiniai apribojimai
Jei dirbate su .NET MAUI ir prenumeratomis „Android“ sistemoje, tikriausiai jau skaitėte arba patyrėte, kad tai nėra taip paprasta. Daugelyje projektų buvo naudojama Plugin.InAppBilling James Montemagno, tačiau įskiepis yra archyvuotas ir nebeprižiūrimas, todėl jis nebus atnaujintas, kad palaikytų „Billing Library 7“. Tuo pačiu metu oficialus paketas Xamarin.Android.Google.BillingClient Jis liko susietas su „Xamarin.Android“ ekosistema ir nėra tiesiogiai suderinamas su .NET MAUI.
Praktinė pasekmė yra ta, kad „Play Console“ įspėja Jūsų programa nenaudoja „Billing Library 7.0.0“ ar naujesnės versijos, todėl atnaujinimai blokuojami, jei ir toliau naudojate senesnes bibliotekas. Kai kurie kūrėjai pasirinko drastiškus sprendimus, pvz., laikinai išjungė prenumeratas, kad būtų galima įkelti versiją, tačiau akivaizdu, kad tai netvarus sprendimas, jei jūsų verslo modelis priklauso nuo tokio pajamų gavimo.
Šiuo atveju daugelis komandų svarsto alternatyvas, pvz. Trečiųjų šalių SDK Šios paslaugos jau palaiko „PBL 7“ ir teikia stabilesnę, keliose platformose veikiančią API (pvz., prenumeratos sprendimus su SDK, skirtais „Android“, „iOS“ ir kitoms platformoms). Šios paslaugos paprastai tvarko atsiskaitymo bibliotekos versijų perkėlimą ir teikia stabilų apvalkalą, o tai žymiai sumažina stresą dėl kiekvieno naujo „Google“ atsisakymo.
Kol „Microsoft“ ir MAUI komanda nepasiūlys Oficialus paketas atnaujintas ir visiškai suderinamas Naudojant „Billing Library 7“, galite: įdiegti savo susiejimą su vietine „Billing Library“, naudoti trečiosios šalies paslaugą arba permąstyti, kaip integruojate pirkimus į savo MAUI projektą. Bet kuriuo atveju geriausia neatidėti sprendimo iki paskutinės minutės, nes „Play“ terminai yra fiksuoti.
Apskritai, atnaujinant „Google Play Billing Library v7“ peržiūrimos priklausomybės, išvalomos pasenusios API, sustiprinama vidinė logika naudojant pirkimų patvirtinimą ir RTDN, taip pat naudojami testavimo įrankiai, tokie kaip „Play Billing Lab“, siekiant aptikti visas klaidas prieš paleidimą. Tie, kurie skirs laiko šiam perkėlimui tiksliai suderinti, galės geriau valdyti išankstinio mokėjimo planus, virtualius mokesčius, tinklo klaidas ir prenumeratos gyvavimo ciklo pakeitimus, taip pat turės daug daugiau galimybių išlaikyti stabilias pajamas ir nepriekaištingą naudotojo patirtį „Google Play“. Pasidalykite informacija, kad daugiau vartotojų galėtų sužinoti apie šią temą.