Ako radite s kupovinama unutar aplikacije na Androidu, prije ili kasnije ćete se morati suočiti s Biblioteka za naplatu na Google Playu v7To nije samo još jedno ažuriranje: dolazi s promjenama API-ja, novim funkcijama pretplate, zahtjevima konzole i vrlo jasnim rokovima od strane Googlea. Ignoriranje više nije opcija ako želite nastaviti objavljivati ili ažurirati svoju aplikaciju na Google Playu bez ikakvih iznenađenja.
Kroz cijeli članak vidjet ćete kako Ažurirajte i implementirajte Google Play Billing Library v7 Korak po korak: od onoga što se razlikuje od PBL 5 i 6, do toga kako integrirati pretplate, jednokratne kupovine, RTDN, testiranje s Play Billing Labom i kako preživjeti u ekosistemima poput .NET MAUI-ja gdje službena podrška zaostaje. Ideja je da, kada završite s čitanjem, možete pripremiti migraciju s povjerenjem i bez trošenja ijednog centa.
Pregled Google Play biblioteke za naplatu v7
Google Play Billing Library 7 uvodi značajna poboljšanja u načinu upravljanja računima Plaćanja, pretplate i posebni planoviMeđutim, dizajniran je tako da migracija bude relativno glatka. Dobra vijest je da su mnogi novi API-ji opcionalni: možete ažurirati zavisnost, prilagoditi nekoliko referenci, a vaša osnovna integracija će i dalje raditi.
Ova verzija se fokusira na tri ključna područja: nove opcije pretplate (kao što su virtuelne kvote), bolja podrška za kupovine na čekanju na prepaid planovimai promjene API-ja koje uklanjaju ono što je već bilo zastarjelo u prethodnim verzijama (PBL 5 i 6). Osim toga, Google prilagođava neke načine rukovanja greškama i način na koji biste trebali rukovati transakcijama na čekanju kako biste izbjegli nedosljednosti.
Za početak, u modulu vaše aplikacije trebate ažurirati zavisnost u vašoj datoteci build.gradle:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
Kada se ovo uradi, vrijeme je za pregled koda koji koristi naslijeđene API-je. Mnogi pozivi povezani sa proporcionalna podjela pretplate i alternativno naplativanje Preimenovani su ili uklonjeni, pa je dobra ideja dobro pogledati sve reference na BillingClient i BillingFlowParams prije kompajliranja i otpremanja bilo čega na Play Console.
Strategije monetizacije s jednokratnim kupovinama i pretplatama
Kada prodajete digitalne proizvode unutar svoje aplikacije, nije dovoljno samo zalijepiti dijalog za kupovinu i završiti s tim: dizajniranje besprijekorno korisničko iskustvo tokom cijelog ciklusa kupovineOvo se odnosi i na pojedinačne proizvode (koji se mogu potrošiti ili ne) i na pretplate. Što je proces prirodniji i bez problema, to su konverzije veće, a stopa otkazivanja niža.
Tipičan tok kupovine putem Play Billinga, bilo da se radi o pretplati ili pojedinačnoj stavci, obično prati ove dobro definirane faze kojih bi vaš backend također trebao biti svjestan:
- Korisnik istražuje dostupne proizvode i odabire jedan.
- Aplikacija pokreće proces naplate na Google Playu kako bi se dovršilo plaćanje.
- Kupovina je završena i vaša aplikacija prima rezultat.
- Vaš server provjerava kupovinu putem Google Play Developer API-ja.
- Odgovarajući sadržaj ili pravo je dodijeljeno korisniku u vašem sistemu.
- Google je obaviješten da je kupovina obrađena (konzumirana ili potvrđena).
U slučaju proizvoda za potrošnju, ključno je da potrošite token u pravo vrijeme kako bi se omogućila besprijekorna ponovna kupovina i pomoć Blokirajte slučajne kupovine na Google PlayuKod pretplata morate kontrolirati obnavljanja, periode odgode, suspenzije i otkazivanja kako bi korisnik dobio tačno ono što je platio, a ne ni dan manje.
Integracija u aplikaciju je samo pola posla: vaš server mora održavati pouzdana evidencija prava i statusa kupovineOvo je posebno važno ako nudite pristup više platformi ili vam je potrebna detaljna statistika o prihodima, zadržavanju i odlivu korisnika. Tu dolaze do izražaja obavještenja za programere u realnom vremenu (RTDN), koja djeluju kao "crna kutija" životnog ciklusa kupovine.
Pomoću RTDN-a možete reagovati gotovo u realnom vremenu na kritične događaje: novu kupovinu, neuspješno obnavljanje, pretplatu koja ulazi u period odgode ili otkazanu kupovinu. Ovo vam omogućava da razvijete strategije za oporavak pretplatnika i prevencija prevara, kao što je automatsko slanje e-pošte kada plaćanje ne uspije ili prilagođavanje prava ako kupac ne primi poruku zbog problema s mrežom.
Obavještenja za programere u realnom vremenu (RTDN) i Google Cloud Pub/Sub
RTDN-ovi koriste Google Cloud Pub/Sub kao sistem za razmjenu poruka u realnom vremenu između Google Playa i vašeg backenda. Google Play objavljuje događaje o temi Pub/Sub, a vi se pretplatite na tu temu da biste primali poruke kad god se status kupovine ili pretplate promijeni.
Osnovni tok je jednostavan: Google Play šalje poruku kodiranu u base64 formatu na temu Pub/Sub, vaš pretplatnik je izdvaja, dekodira i obrađuje obavještenje. Unutar polja data Unutar poruke ćete pronaći JSON objekt Obavještenje za programerešto uključuje informacije kao što su verzija poruke, naziv paketa, vrijeme događaja i specifične podatke o jednokratnim kupovinama, pretplatama, otkazanim kupovinama ili probnim verzijama.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Zahvaljujući ovim porukama možete Održavajte sinhronizaciju pozadinskog sistema čak i ako korisnikov uređaj zakažeZamislite da korisnik uspješno izvrši kupovinu, Google Play to potvrdi, ali mobilni uređaj izgubi vezu prije nego što vaša aplikacija primi povratni poziv od Billing Library. Bez RTDN-a, možda nikada nećete znati. Sa Pub/Sub, vaš server prima zasebnu obavijest i može odobriti ovlaštenje nezavisno od klijenta.
Konfiguracija Cloud Pub/Sub-a za RTDN
Prije aktiviranja RTDN-a u Google Play konzoli, potrebno je pripremiti projekat u Google Cloud Platforma (GCP) i tamo konfigurirajte Pub/Sub. Proces je relativno jednostavan, ali ga je najbolje pažljivo slijediti kako biste izbjegli iznenađenja s dozvolama ili nazivima resursa.
Kreiranje teme
Prvo morate kreirati Tema za objavu/pretplatu koja će djelovati kao vaša tačka objavljivanja na Google Playu. Iz Google Cloud konzole odaberite svoj projekat, idite na odjeljak Pub/Sub i kreirajte novu temu slijedeći službeni vodič za "kreiranje teme". Rezultat će imati naziv u sljedećem formatu:
projects/{project_id}/topics/{topic_name}
To puno ime je ono koje ćete morati zalijepiti u Play konzolu kada aktivirate obavještenja.
Kreiranje pretplate
Da biste pročitali poruke u ovoj temi, potreban vam je Pretplata na Pub/SubMožete ga konfigurirati kao guranje ili kao povućiU referentnom kodnom laboratoriju, radimo s pull pretplatom, gdje vaš backend inicira zahtjeve za preuzimanje poruka.
Trebali biste pregledati opcije u vodiču za pretplatnike na Cloud Pub/Sub kako biste odlučili da li je push ili pull opcija bolja za vašu arhitekturu. Nakon što se odlučite, slijedite dokumentaciju za "dodavanje pretplate" i povežite je s temom koju ste ranije kreirali. Od tog trenutka nadalje, sve poruke koje Google Play objavi u temi bit će dostupne vašem pretplatniku.
Dozvole za objavljivanje u vašoj temi na Google Playu
Pub/Sub neće dozvoliti Google Playu da objavi bilo šta osim ako mu ne date eksplicitnu dozvolu. račun uslugeU Google Cloud konzoli, potrebno je da odete na postavke dozvola za temu i dodate glavnu:
[email protected]
Dodijeli ovom računu ulogu Izdavač publikacija/pretplata (Izdavač). Sačuvajte promjene i od tog trenutka nadalje, Google Play će moći slati RTDN-ove vašoj temi bez problema s autorizacijom.
Aktivirajte RTDN u Google Play konzoli
Nakon što je Pub/Sub konfiguriran, potrebno je da Play Consoleu kažete gdje da šalje obavještenja. Unutar vaše aplikacije u Google Play Consoleu, idite na Unovčavanje putem Playa > Postavke unovčavanja i pronađite odjeljak s obavijestima za programere u stvarnom vremenu.
Tamo će vam trebati:
- Označite polje da biste omogućili obavještenja u stvarnom vremenu.
- Unesite puni naziv teme za objavu/podgrupu u odgovarajuće polje, poštujući format
projects/{project_id}/topics/{topic_name}. - Pošaljite probnu poruku pomoću testnog dugmeta.
Testna poruka je neophodna za provjeru da li je Integracija je dobro implementirana.Ako imate pull pretplatu, možete otići u Cloud konzolu, odabrati pretplatu, kliknuti na "Prikaži poruke" i izdvojiti testnu poruku. Ne zaboravite uraditi ack bilo koje poruke koju pročitate kako biste izbjegli ponovljena primanja.
Za push pretplate, provjerite da li vaša krajnja tačka prima poruku i odgovara važećim HTTP kodom. Ako nešto pođe po zlu, konzola će prikazati grešku prilikom objavljivanja testa, obično povezanu s nazivom teme ili dozvolama servisnog računa.
Konačno, možete konfigurirati koje vrste obavještenja želite primati: samo pretplate i otkazane kupovine ili sva obavještenja, uključujući jednokratne kupovine (događaji kao što su ONE_TIME_PRODUCT_PURCHASED i ONE_TIME_PRODUCT_CANCELED). Ako koristite i jedinstvene proizvode, uobičajena je praksa aktivirati cijeli set kako bi se održala vidljivost svega.
Izgradite pretplatnika za Pub/Sub u svom backendu
Kada su tema i pretplata spremni, vrijeme je za implementaciju pretplatnik koji čita i obrađuje RTDN-oveGoogle pruža primjere u nekoliko jezika; tipičan slučaj u Javi koristi klijentske biblioteke Cloud Pub/Sub za pokretanje Subscriber koji sluša poruke i zove MessageReceiver.
Opći obrazac je uvijek isti: preuzimate poruku, dekodirate polje data Konvertujete base64 u tekst, parsirate JSON i izdvajate relevantna polja (kao što je packageName, oneTimeProductNotification o subscriptionNotification) i odlučite šta ćete uraditi u svom sistemu. Nakon uspješne obrade obavještenja, morate Potvrdite poruku potvrdom tako da Pub/Sub to ne pošalje ponovo.
Primjer koda pokazuje kako prijemnik ispisuje verziju i naziv paketa, ali u stvarnoj implementaciji biste išli dalje: Potvrdili biste kupovinu, dajući pravo ispravnom korisnikuAžurirali biste svoju bazu podataka i, ako je potrebno, pozvali Play Developer API da biste izvršili ili prepoznali kupovinu.
Poveži obavještenja s korisnikom: korištenjem obfuscatedAccountId-a
Uobičajen problem pri upravljanju kupovinama sa servera je poznavanje kojem korisniku pripada određena RTDN obavijest. Za to vam Billing Client API omogućava da priložite prikriveni identifikator računa kada pokrenete proces kupovine: obfuscatedAccountId.
Ideja je da koristite stabilan identifikator iz vašeg sistema (na primjer, interni ID korisnika), ali zatamnjeno iz razloga privatnosti i sigurnostiOva vrijednost je povezana s kupovinom, a zatim se pojavljuje u informacijama koje vraća Google Play Developer API, tako da kada primite RTDN i verifikujete token, nedvosmisleno ćete znati kojem računu u vašoj bazi podataka trebate dati pravo.
Sa strane kupca, prilikom pripreme BillingFlowParamsSamo trebate sastaviti listu ProductDetailsParams i nazovite setObfuscatedAccountId(obfuscatedAccountId) prije pokretanja toka. To ne mijenja vidljivo korisničko iskustvo, ali znatno pojednostavljuje proces. logika alokacije kupovine na pozadini i pomaže Googleu da otkrije prevaru.
Potvrdite kupovine pomoću Google Play Developer API-ja
Prije dodjeljivanja bilo kakvih prava na vašem serveru, obavezno je provjeriti da li je kupovina legitimna pozivom API za razvojne programere na Google PlayuNije dovoljno oslanjati se na ono što klijent ili čak RTDN kaže: morate validirati purchaseToken direktno naspram službenih krajnjih tačaka, i ako je potrebno upravljajte povratima novca.
U slučaju jedinstvenih proizvoda, koristit ćete krajnju tačku purchases.products:getZa pretplate, put vodi kroz purchases.subscriptionsv2:getPreporučeni tok je:
- Izdvojite
purchaseTokeniz Pub/Sub poruke. - Provjerite svoju bazu podataka da vidite da li ste je već obradili; svaki token je globalno jedinstvenDakle, savršen je kao primarni ključ kako bi se izbjegli duplikati.
- Ako je nov, pozovite Google Play Developer API sa paketom, SKU-om i
purchaseToken. - Provjerite da li odgovor ukazuje na status kupovine KUPLJENO (nije NA ČEKANJU niti otkazano).
- Ako se sve poklapa, registrujte token i dodijelite odgovarajuće pravo pridruženom korisniku.
Za komunikaciju s Play Developer API-jem iz Jave možete koristiti AndroidPublisher, inicijalizirano s vjerodajnicama servisnog računa u JSON formatu. Konfigurirate opseg AndroidPublisherScopes.ANDROIDPUBLISHERKreirate klijenta i pozivate metodu purchases().products().get(...)Ako poziv ne uspije zbog privremenog problema s mrežom ili uslugom, preporučuje se implementirati ponovne pokušaje s eksponencijalnim odgađanjem kako ne bi propustili događaj.
Potvrdite ili dovršite kupovinu sa servera
Nakon što ste potvrdili kupovinu i odobrili autorizaciju u svom sistemu, sljedeći korak je obavijestiti Google da je transakcija uspješno obrađena. Za proizvode s jednim artiklom imate dvije mogućnosti: konzumirati kupovinu ili jednostavno prepoznati je.
Potrošni proizvodi (npr. virtuelna valuta, životi itd.) moraju proći kroz krajnju tačku purchases.products:consumeOvo označava token kao korišten i omogućava korisniku da ponovo kupi isti artikl bez konflikta. Za proizvode koji se ne mogu potrošiti (kao što je otključavanje premium verzije za cijeli život), morate pozvati purchases.products:acknowledge, što obavještava Google da korisnik već ima povezano pravo.
Pretplate se koriste purchases.subscriptions:acknowledgešto ukazuje na to da je pretplata uspješno obrađena i dodijeljena korisniku. Ako ne potvrdite kupovinu u razumnom roku, Google može pretpostaviti da postoji problem i poništiti transakciju, stoga je važno da povratak se vrši odmah nakon davanja prava.
U vašem AndroidPublisher pomoćniku možete dodati metode poput executeProductPurchasesConsume y executeProductPurchasesAcknowledge koji pozivaju odgovarajuće krajnje tačke. Opet, preporučljivo je implementirati ponovne pokušaje u slučaju povremenih neuspjeha, kako bi se osiguralo da nijedan token ne ostane u opasnom međustanju.
Napredno testiranje s Play Billing Labom
Jedan aspekt koji mnogi programeri podcjenjuju je faza testiranja. Da biste pokrenuli program sa bilo kakvim stepenom pouzdanosti, morate biti u stanju simulirati mrežne greške, nestandardni odgovori i rubni slučajeviTu nastupa Play Billing Lab, besplatna aplikacija na Google Playu dizajnirana posebno za testiranje integracija Play Billing Library.
Play Billing Lab uključuje simulator odgovora što omogućava forsiranje različitih BillingResponseCode u pozivima vaše aplikacije prema biblioteci za naplatu. Na ovaj način možete ponovo kreirati scenarije u kojima, na primjer, kupac ne može dovršiti kupovinu zbog problema s mrežom, ali vaš backend ispravno obrađuje RTDN i na kraju odobrava ovlaštenje bez intervencije korisnika.
Da bi vaša aplikacija komunicirala sa simulatorom, potrebno je da omogućite testiranje "nadjačavanja naplate" koristeći metapodatke u 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>
Etiketa omogući testiranje nadjačavanja naplate Aktivirajte simulirane testove odgovora u Biblioteci za naplatu. Oznaka NONPRODUCTION je vrsta podsjetnika da ova verzija ne bi trebala ići u produkciju s aktivnim nadjačavanjima. Prilikom pripreme konačne verzije za korisnike, obavezno Uklonite ove metapodatke ili koristite zaseban manifest.
Nakon konfiguracije, prijavite se iz aplikacije Play Billing Lab s računom testera licenci, aktivirajte opciju "Simuliraj odgovor Play Billing Library" i odaberite koje kodove grešaka želite vratiti za svaki API (na primjer, određenu grešku u consumeAsyncZatim jednostavno otvorite aplikaciju i pokrenete tok koji želite testirati: simulator će vratiti konfigurirane odgovore i možete provjeriti da li se vaša logika ponovnog pokušaja, rukovanje greškama i RTDN ponašaju kako se očekuje.
Ključne promjene API-ja prilikom migracije na Play Billing Library 7
Pored RTDN-a i testiranja, migracija na PBL 7 uključuje rješavanje nekih specifičnih API tačaka. Za one koji dolaze sa PBL 5 ili 6, vrijedi pregledati najrelevantnije promjene kako bi se osiguralo da se projekat glatko kompajlira i da poslovna logika ostane konzistentna.
Prvo, API-ji povezani sa Proporcionalni način rada Opcije za promjenu pretplate su uklonjene. Sada se koristi sljedeće: Zamjenski način rada za upravljanje promjenama plana (nadogradnje, snižavanje plana itd.). Ako i dalje koristite metode poput setReplaceProrationMode o setReplaceSkusProrationModeMorat ćete ih migrirati na nove varijante setSubscriptionReplacementMode i prilagodite logiku u skladu s ažuriranom dokumentacijom.
API je također uklonjen launchPriceConfirmationFlowšto je već bilo označeno kao zastarjelo. Da biste se nosili s promjenama cijena pretplate, trebali biste se pozvati na nove tokove rada i preporuke u vodiču za promjenu cijena, koji detaljno opisuje kako pravilno informirati korisnika i kako upravljati pristankom.
Još jedna važna tačka je Alternativni API-ji za naplatuMetode BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails nestali su u korist usklađenije nomenklature: sada morate koristiti BillingClient.Builder.enableUserChoiceBilling() pored UserChoiceBillingListener y UserChoiceDetailsPrema samom Googleu, to je u osnovi promjena imena bez promjena u ponašanju, u kontekstu obilježenom sporazumima kao što su Google i Epic Games se slažu da otvore Android.
Konačno, unosi se novi kod greške. MREŽNA_GREŠKA en BillingResulti značenja i uslove SERVICE_TIMEOUT i SERVICE_NEDOSTUPNOAko imate prilagođenu logiku za rukovanje greškama (na primjer, odlučivanje kada prikazati poruku korisniku, kada tiho pokušati ponovo itd.), preporučljivo je da je pregledate kako biste uzeli u obzir ove nove nijanse.
Transakcije na čekanju i nedostatak ID-a narudžbe do KUPOVINE
Suptilna promjena u PBL 7 je da biblioteka više ne generira ID narudžbe za kupovine na čekanju. U ovim slučajevima, orderId Bit će dostupno tek kada kupovina dostigne stanje KUPLJENO. Ovo posebno utiče na tokove rada gdje ste od početka koristili ID narudžbe kao primarnu referencu.
Googleova preporuka je da se oslonite na purchaseToken za vaše evidencije i usklađivanjabarem dok je transakcija na čekanju. Ako pronađete kupovinu koja je nestala s Playa, provjerite Šta učiniti ako kupovina nestane.
Ako još niste radili s nepodmirenim dugovima, pregledajte vodič za integraciju Billing Library i dokumentaciju o upravljanje životnim ciklusom nabavkeTamo ćete pronaći različita stanja, kako reagovati na svako od njih i kako se RTDN-ovi uklapaju u ovu slagalicu.
Nove opcionalne mogućnosti u PBL 7: virtualne rate i avansna plaćanja
Među "lijepim" novim karakteristikama PBL 7 su i virtualne pretplate (virtualne pretplate na rate) i proširena podrška za kupovine na čekanju za prepaid pretplate. Ove funkcije nisu obavezne, ali vam mogu pružiti veću fleksibilnost prilikom prilagođavanja vašeg poslovnog modela različitim tržištima.
Virtualne rate omogućavaju korisniku da plati dugoročniju pretplatu u male periodične uplateUmjesto jedne velike uplate, Google objašnjava da, u svrhu naplate programerima, nastavljate primati mjesečne uplate u okviru godišnjeg plana s mjesečnim ratama. Ako korisnik propusti plaćanje, ni vi ni Google ne biste trebali pokušavati naplatiti prošle rate. Zbog toga je njegova praktična upotreba prilično slična standardnoj mjesečnoj pretplati, barem u početku.
Za sada su ove pretplate dostupne samo u Brazil, Francuska, Italija i ŠpanijaGoogle preporučuje da pratite Play konzolu za novopodržane zemlje. Konfiguracija se vrši putem ProductDetails.InstallmentPlanDetails i slijedeći specifičan vodič za njihovu integraciju u vašu aplikaciju.
Paralelno s tim, podrška se proširuje kupovine na čekanju za prepaid pretplateSada možete ponuditi modele u kojima korisnik započinje kupovinu u aplikaciji i kasnije dovršava plaćanje na druge načine, a Biblioteka za naplatu zna kako pravilno obraditi taj tok. Aktivacija se vrši pozivom funkcije enablePendingPurchases() prilikom inicijalizacije BillingClienta i, posebno za prepaid planove, korištenjem PendingPurchasesParams.Builder.enablePrepaidPlans().
Periodi amortizacije za Play Billing Library 5 i 6
S obzirom na pojavu PBL 7, Google je odredio jasne datume za povlačenje podrške za verzije 5 i 6Ako se još uvijek nalazite u nekom od njih, morate označiti kalendar crvenom bojom:
- Google Play Billing Library 5 će biti zvanično zastario 31. augusta 2024. za nove aplikacije i ažuriranja. Moguće je zatražiti produženje do 1. novembra 2024., ali to nije nešto na što biste se trebali oslanjati dugoročno.
- Google Play Billing Library 6 može se koristiti za objavljivanje novih aplikacija do 1. augusta 2025. godine i za ažuriranje postojećih aplikacija do 1. novembra 2025. godine.
Nakon tog datuma, ako niste migrirali barem na verziju 6 ili idealno na verziju 7, morat ćete ažurirati na najnoviju verziju. 7 verzijaAžuriranja će biti blokirana u Play konzoli. Iako će vaša aplikacija nastaviti funkcionirati na korisničkim uređajima, bit ćete zamrznuti i nećete moći ispravljati greške ili dodavati nove funkcije koje zavise od objavljivanja u trgovini.
Slučaj .NET MAUI-ja i trenutna ograničenja
Ako radite sa .NET MAUI-jem i pretplatama na Androidu, vjerovatno ste već pročitali ili iskusili da to nije tako jednostavno. Mnogi projekti su koristili Plugin.InAppBilling od Jamesa Montemagna, ali je dodatak arhiviran i neodržavan, tako da neće biti ažuriran da bi podržavao Billing Library 7. Istovremeno, službeni paket Xamarin.Android.Google.BillingClient Ostao je vezan za ekosistem Xamarin.Android i nije direktno kompatibilan sa .NET MAUI-jem.
Praktična posljedica je da Upozorenja Play konzole Vaša aplikacija ne koristi Billing Library 7.0.0 ili noviju verziju, što blokira ažuriranja ako nastavite koristiti starije biblioteke. Neki programeri su se odlučili za drastična rješenja, kao što je privremeno onemogućavanje pretplata kako bi mogli otpremiti verziju, ali očito to nije održivo ako vaš poslovni model ovisi o toj monetizaciji.
U tom kontekstu, mnogi timovi razmatraju alternative kao što su SDK-ovi trećih strana Ove usluge već podržavaju PBL 7 u osnovi i pružaju stabilniji API za više platformi (na primjer, backend rješenja za pretplatu sa SDK-ovima za Android, iOS i druge platforme). Ove usluge obično obrađuju migracije verzija Billing Library-a i pružaju stabilan omotač, značajno smanjujući opterećenje sa svakim novim Googleovim ukidanjem podrške.
Dok Microsoft i MAUI tim ne ponude Zvanični paket ažuriran i potpuno kompatibilan Sa Billing Library 7, opcije uključuju: implementaciju vlastitog povezivanja s izvornom Billing Library, korištenje usluge treće strane ili ponovno razmišljanje o tome kako integrirate kupovine unutar svog MAUI projekta. U svakom slučaju, najbolje je ne ostavljati odluku do posljednjeg trenutka, jer su Play rokovi fiksni.
Sveukupno, ažuriranje Google Play Billing Library v7 uključuje pregled zavisnosti, čišćenje zastarjelih API-ja, jačanje backend logike s verifikacijom kupovine i RTDN-om, te korištenje alata za testiranje poput Play Billing Laba kako bi se otkrile sve greške prije objavljivanja. Oni koji odvoje vrijeme za fino podešavanje ove migracije moći će bolje da se nose s prepaid planovima, virtualnim naknadama, mrežnim greškama i promjenama životnog ciklusa pretplate, te će imati mnogo veće šanse da održe stabilan prihod i uglađeno korisničko iskustvo na Google Playu. Podijelite informacije kako bi više korisnika moglo saznati više o toj temi.