Ja strādājat ar pirkumiem lietotnēs operētājsistēmā Android, agrāk vai vēlāk jums būs jātiek galā ar šo problēmu. Google Play norēķinu bibliotēka, 7. versijaTas nav tikai vēl viens atjauninājums: tas ietver API izmaiņas, jaunas abonēšanas funkcijas, konsoles prasības un ļoti skaidrus termiņus no Google puses. Ignorēt to vairs nav iespējams, ja vēlaties turpināt publicēt vai atjaunināt savu lietotni pakalpojumā Google Play bez jebkādiem pārsteigumiem.
Visā šajā rakstā jūs redzēsiet, kā Atjauniniet un ieviesiet Google Play norēķinu bibliotēku 7. versijā Soli pa solim: sākot ar atšķirībām no PBL 5 un 6, līdz abonementu, vienreizēju pirkumu, RTDN, testēšanas ar Play Billing Lab integrācijai un izdzīvošanai tādās ekosistēmās kā .NET MAUI, kur oficiālais atbalsts atpaliek. Ideja ir tāda, ka pēc lasīšanas pabeigšanas varat sagatavoties migrācijai ar pārliecību un netērējot ne santīma.
Google Play norēķinu bibliotēkas 7. versijas pārskats
Google Play Billing Library 7 ievieš būtiskus uzlabojumus rēķinu pārvaldībā Maksājumi, abonementi un īpašie plāniTomēr tas ir izstrādāts tā, lai migrācija būtu relatīvi vienmērīga. Labā ziņa ir tā, ka daudzas no jaunajām API ir neobligātas: jūs varat atjaunināt atkarību, pielāgot dažas atsauces, un jūsu pamata integrācija joprojām darbosies.
Šī versija koncentrējas uz trim galvenajām jomām: jaunas abonēšanas iespējas (piemēram, virtuālās kvotas), labāks atbalsts neapstiprināti pirkumi priekšapmaksas plānosun API izmaiņas, kas novērš novecojušos elementus iepriekšējās versijās (PBL 5 un 6). Turklāt Google pielāgo dažas kļūdu apstrādes metodes un to, kā jārīkojas ar gaidāmajiem darījumiem, lai izvairītos no neatbilstībām.
Lai sāktu, lietotnes modulī jums ir jāatjaunina atkarība failā. veidot.grale:
dependencies {
def billingVersion = "7.0.0"
implementation "com.android.billingclient:billing:$billingVersion"
}
Kad tas ir paveikts, ir pienācis laiks pārskatīt kodu, kas izmanto mantotas API. Daudzi izsaukumi ir saistīti ar abonēšanas proporcionālā sadalīšana un alternatīvā norēķināšanās Tie ir pārdēvēti vai noņemti, tāpēc pirms jebkādu failu kompilēšanas un augšupielādes pakalpojumā Play Console ieteicams rūpīgi pārskatīt visas atsauces uz BillingClient un BillingFlowParams.
Monetizācijas stratēģijas ar vienreizējiem pirkumiem un abonementiem
Pārdodot digitālos produktus savā lietotnē, nepietiek tikai ielīmēt pirkuma dialoglodziņu un beigt darbu: izstrādājot nevainojamu lietotāja pieredzi visā pirkuma ciklāTas attiecas gan uz atsevišķiem produktiem (gan patērējamiem, gan nepatērējamiem), gan uz abonementiem. Jo dabiskāks un vienmērīgāks ir process, jo augstāks ir konversiju skaits un zemāks atcelšanas līmenis.
Tipiska pirkuma plūsma, izmantojot Play Billing, neatkarīgi no tā, vai tas ir abonements vai atsevišķa prece, parasti notiek pēc šiem precīzi definētajiem posmiem, kas jāzina arī jūsu servera serverim:
- Lietotājs apskata pieejamos produktus un izvēlas vienu.
- Lietotne uzsāk Google Play norēķinu procesu, lai pabeigtu maksājumu.
- Pirkums ir pabeigts, un jūsu lietotne saņem rezultātu.
- Jūsu serveris validē pirkumu, izmantojot Google Play izstrādātāja API.
- Atbilstošais saturs vai tiesības tiek piešķirtas lietotājam jūsu sistēmā.
- Google tiek informēts, ka pirkums ir apstrādāts (patērēts vai apstiprināts).
Patērējamo produktu gadījumā ir svarīgi, lai patērēt žetonu īstajā laikā lai nodrošinātu netraucētu atkārtotu iegādi un palīdzību Bloķēt nejaušus pirkumus pakalpojumā Google PlayAbonementos jums ir jākontrolē atjaunošana, labvēlības periodi, apturēšana un atcelšana, lai lietotājs saņemtu tieši to, par ko ir samaksājis, un ne dienu mazāk.
Integrācija lietotnē ir tikai puse no darba: jūsu serverim ir jāuztur uzticama tiesību un pirkuma statusu uzskaiteTas ir īpaši svarīgi, ja piedāvājat piekļuvi vairākās platformās vai nepieciešama detalizēta statistika par ieņēmumiem, klientu noturēšanu un klientu aizplūšanu. Šeit noder reāllaika izstrādātāju paziņojumi (RTDN), kas darbojas kā pirkuma dzīves cikla "melnā kaste".
Ar RTDN jūs varat gandrīz reāllaikā reaģēt uz kritiskiem notikumiem: jaunu pirkumu, atjaunošanas kļūmi, abonementa ieiešanu labvēlības periodā vai atceltu pirkumu. Tas ļauj jums izstrādāt stratēģijas, lai abonentu atgūšana un krāpšanas novēršana, piemēram, automātiska e-pasta nosūtīšana, ja maksājums neizdodas, vai tiesību pielāgošana, ja klients nesaņem ziņojumu tīkla problēmu dēļ.
Reāllaika izstrādātāju paziņojumi (RTDN) un Google Cloud Pub/Sub
RTDN izmantošana Google Cloud Pub/Sub kā reāllaika ziņojumapmaiņas sistēma starp Google Play un jūsu aizmugursistēmu. Google Play publicē notikumus par publicēšanas/abonēšanas tēmu, un jūs abonējat šo tēmu, lai saņemtu ziņojumus ikreiz, kad mainās pirkuma vai abonementa statuss.
Pamatplūsma ir vienkārša: Google Play nosūta base64 kodētu ziņojumu uz Pub/Sub tēmu, jūsu abonents to izvelk, dekodē un apstrādā paziņojumu. Lauka ietvaros data Ziņojumā jūs atradīsiet JSON objektu Izstrādātāja paziņojumskas ietver tādu informāciju kā ziņojuma versija, pakotnes nosaukums, notikuma laiks un konkrētus datus par vienreizējiem pirkumiem, abonementiem, atceltiem pirkumiem vai izmēģinājuma periodiem.
{
"version": string,
"packageName": string,
"eventTimeMillis": long,
"oneTimeProductNotification": OneTimeProductNotification,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification,
"testNotification": TestNotification
}
Pateicoties šiem ziņojumiem, jūs varat Nodrošiniet sinhronizāciju ar jūsu serveri pat tad, ja lietotāja ierīce nedarbojasIedomājieties, ka lietotājs veiksmīgi veic pirkumu, Google Play to apstiprina, bet mobilā ierīce zaudē savienojumu, pirms jūsu lietotne saņem atzvanu no norēķinu bibliotēkas. Bez RTDN jūs, iespējams, nekad neuzzināsiet. Izmantojot Pub/Sub, jūsu serveris saņem atsevišķu paziņojumu un var piešķirt tiesības neatkarīgi no klienta.
Mākoņa publicēšanas/abonēšanas konfigurācija RTDN
Pirms RTDN aktivizēšanas pakalpojumā Google Play konsolē ir jāsagatavo projekts. Google mākoņa platforma (GSP) un tur konfigurējiet Pub/Sub. Process ir samērā vienkāršs, taču vislabāk to rūpīgi ievērot, lai izvairītos no pārsteigumiem saistībā ar atļaujām vai resursu nosaukumiem.
Tēmas izveide
Vispirms jums ir jāizveido Publikācijas/abonēšanas tēma kas darbosies kā jūsu Google Play publicēšanas punkts. Google Cloud konsolē atlasiet savu projektu, dodieties uz sadaļu Pub/Abonēt un izveidojiet jaunu tēmu, ievērojot oficiālo tēmu izveides rokasgrāmatu. Rezultātā būs nosaukums šādā formātā:
projects/{project_id}/topics/{topic_name}
Šis pilns vārds ir tas, kas jums būs jāielīmē pakalpojumā Play Console, aktivizējot paziņojumus.
Abonementa izveide
Lai lasītu ziņojumus šajā pavedienā, jums ir nepieciešams Publikācijas/abonēšanas abonementsVarat to konfigurēt kā push vai kā vilktAtsauces kodlaboratorijā mēs strādājam ar pull abonementu, kur jūsu aizmugursistēma iniciē pieprasījumus ziņojumu izgūšanai.
Lai izlemtu, vai jūsu arhitektūrai labāk atbilst “push” vai “pull” metode, jums vajadzētu pārskatīt Cloud Pub/Sub abonenta rokasgrāmatā pieejamās opcijas. Kad esat pieņēmis lēmumu, izpildiet “add abonation” dokumentāciju un saistiet to ar iepriekš izveidoto tēmu. Turpmāk visi ziņojumi, ko Google Play publicē šajā tēmā, būs pieejami jūsu abonentam.
Atļaujas pakalpojumam Google Play publicēt saturu jūsu motīvā
Pub/Sub neļaus pakalpojumam Google Play publicēt neko, ja vien jūs tam nesniegsiet skaidru atļauju. pakalpojuma kontsGoogle Cloud konsolē jums jāiet uz tēmas atļauju iestatījumiem un jāpievieno galvenais:
google-play-developer-notifications@system.gserviceaccount.com
Piešķirt šim kontam lomu Publikāciju/abonementu izdevējs (Izdevējs). Saglabājiet izmaiņas, un no šī brīža Google Play varēs nosūtīt RTDN uz jūsu tēmu bez autorizācijas problēmām.
Aktivizējiet RTDN pakalpojumā Google Play Console
Kad publicēšana/abonēšana ir konfigurēta, jums jānorāda Play Console, kur sūtīt paziņojumus. Savā lietotnē pakalpojumā Google Play Console dodieties uz Monetizācija ar Play > Monetizācijas iestatījumi un atrodiet sadaļu ar izstrādātāju paziņojumiem reāllaikā.
Tur jums būs nepieciešams:
- Atzīmējiet izvēles rūtiņu, lai iespējotu paziņojumus reāllaikā.
- Atbilstošajā laukā ievadiet pilnu publicēšanas/abonēšanas tēmas nosaukumu, ievērojot formātu.
projects/{project_id}/topics/{topic_name}. - Nosūtiet testa ziņojumu, izmantojot testa pogu.
Testa ziņojums ir būtisks, lai pārliecinātos, ka Integrācija ir labi ieviesta.Ja jums ir abonements ar izvilkšanas iespēju, varat doties uz mākoņkonsoli, atlasīt abonementu, noklikšķināt uz “Skatīt ziņojumus” un izvilkt testa ziņojumu. Neaizmirstiet to izdarīt. ack jebkura izlasītā ziņojuma, lai izvairītos no atkārtotas saņemšanas.
Push abonementu gadījumā pārbaudiet, vai jūsu galapunkts saņem ziņojumu un atbild ar derīgu HTTP kodu. Ja kaut kas noiet greizi, konsolē, publicējot testu, tiks parādīta kļūda, kas parasti ir saistīta ar tēmas nosaukumu vai pakalpojuma konta atļaujām.
Visbeidzot, varat konfigurēt, kāda veida paziņojumus vēlaties saņemt: tikai abonementus un atceltus pirkumus vai visi paziņojumi, tostarp vienreizējie pirkumi (tādi notikumi kā ONE_TIME_PRODUCT_PURCHASED un ONE_TIME_PRODUCT_CANCELED). Ja izmantojat arī unikālus produktus, parasti tiek aktivizēts viss komplekts, lai saglabātu redzamību visam.
Izveidojiet Pub/Sub abonentu savā aizmugursistēmā
Kad tēma un abonements ir gatavi, ir pienācis laiks ieviest abonents, kurš lasa un apstrādā RTDNGoogle sniedz piemērus vairākās valodās; tipisks gadījums Java valodā izmanto Cloud Pub/Sub klienta bibliotēkas, lai sāktu Subscriber kurš klausās ziņas un zvana MessageReceiver.
Vispārējais modelis vienmēr ir viens un tas pats: jūs izgūstat ziņojumu, jūs atšifrējat lauku data Jūs konvertējat base64 uz tekstu, parsējat JSON un izvelkat atbilstošos laukus (piemēram, packageName, oneTimeProductNotification o subscriptionNotification) un izlemiet, ko darīt savā sistēmā. Pēc paziņojuma veiksmīgas apstrādes jums ir jāveic Apstipriniet ziņojumu ar apstiprinājumu lai Pub/Sub to vairs nenosūtītu.
Koda piemērā parādīts, kā uztvērējs izdrukā versiju un pakotnes nosaukumu, taču reālā ieviešanas variantā būtu jāiet vēl tālāk: Jūs apstiprinātu pirkumu, piešķirot tiesības pareizajam lietotājamJūs atjauninātu savu datubāzi un, ja nepieciešams, izsauktu Play izstrādātāja API, lai izmantotu vai atpazītu pirkumu.
Saistīt paziņojumus ar lietotāju: izmantojot obfuscatedAccountId
Bieži sastopama problēma, pārvaldot pirkumus no servera, ir zināt, kuram lietotājam pieder konkrēts RTDN paziņojums. Šim nolūkam Billing Client API ļauj pievienot apmulsināts konta identifikators kad palaižat pirkuma plūsmu: obfuscatedAccountId.
Ideja ir tāda, ka jūs izmantojat stabilu identifikatoru no savas sistēmas (piemēram, lietotāja iekšējo ID), bet apmulsināts privātuma un drošības apsvērumu dēļŠī vērtība tiek saistīta ar pirkumu un pēc tam parādās informācijā, ko atgriež Google Play izstrādātāja API, lai, saņemot RTDN un pārbaudot pilnvaru, jūs nepārprotami zinātu, kuram kontam jūsu datubāzē jums jāpiešķir tiesības.
Klienta pusē, sagatavojot BillingFlowParamsJums tikai jāizveido saraksts ar ProductDetailsParams un piezvani setObfuscatedAccountId(obfuscatedAccountId) pirms plūsmas palaišanas. Tas nemaina redzamo lietotāja pieredzi, bet ievērojami vienkāršo procesu. iekšējās iepirkumu sadales loģika un palīdz Google atklāt krāpniecību.
Pārbaudiet pirkumus, izmantojot Google Play izstrādātāja API
Pirms jebkādu tiesību piešķiršanas jūsu serverī ir obligāti jāpārbauda, vai pirkums ir likumīgs, zvanot uz Google Play izstrādātāja APINepietiek paļauties tikai uz to, ko saka klients vai pat RTDN: jums ir jāapstiprina purchaseToken tieši pret oficiālajiem galapunktiem un, ja nepieciešams pārvaldīt atmaksas.
Unikālu produktu gadījumā jūs izmantosiet galapunktu purchases.products:getAbonementu gadījumā ceļš ved caur purchases.subscriptionsv2:getIeteicamā plūsma ir šāda:
- Izvelciet
purchaseTokenno publicēšanas/abonēšanas ziņojuma. - Pārbaudiet savu datubāzi, lai redzētu, vai esat to jau apstrādājis; katrs marķieris ir globāli unikālsTātad tā ir ideāli piemērota kā primārā atslēga, lai izvairītos no dublikātiem.
- Ja tas ir jauns, izsauciet Google Play izstrādātāja API ar pakotni, SKU un
purchaseToken. - Pārliecinieties, vai atbilde norāda pirkuma statusu IEGĀDĀTS (nav NEPABEIGTS vai atcelts).
- Ja viss sakrīt, reģistrējiet pilnvaru un piešķiriet atbilstošās tiesības saistītajam lietotājam.
Lai sazinātos ar Play izstrādātāja API no Java, varat izmantot AndroidPublisher, inicializēts ar pakalpojuma konta akreditācijas datiem JSON formātā. Jūs konfigurējat darbības jomu AndroidPublisherScopes.ANDROIDPUBLISHERJūs izveidojat klientu un izsaucat metodi purchases().products().get(...)Ja zvans neizdodas īslaicīgas tīkla vai pakalpojuma problēmas dēļ, ieteicams ieviest atkārtotus mēģinājumus ar eksponenciālu atlikšanu lai nepalaistu garām pasākumu.
Apstipriniet vai pabeidziet pirkumu no servera
Kad esat verificējis pirkumu un piešķīris autorizāciju savā sistēmā, nākamais solis ir paziņot Google, ka darījums ir veiksmīgi apstrādāts. Atsevišķu preču gadījumā jums ir divas iespējas: patērēt pirkumu o simplemente atpazīt viņu.
Patērējamiem produktiem (piemēram, virtuālajai valūtai, dzīvībām utt.) jāiziet cauri galapunktam purchases.products:consumeTas atzīmē žetonu kā izmantotu un ļauj lietotājam atkārtoti iegādāties to pašu preci bez konfliktiem. Attiecībā uz nepatērējamiem produktiem (piemēram, premium versijas atbloķēšanai uz mūžu) jums jāzvana purchases.products:acknowledge, kas informē Google, ka lietotājam jau ir saistītās tiesības.
Abonementi tiek izmantoti purchases.subscriptions:acknowledgenorādot, ka abonements ir veiksmīgi apstrādāts un piešķirts lietotājam. Ja neapstiprināsiet pirkumu saprātīgā laika posmā, Google var pieņemt, ka ir radusies problēma, un atcelt darījumu, tāpēc ir svarīgi, lai jūs atgriešanās tiek veikta tūlīt pēc tiesību piešķiršanas.
Savā AndroidPublisher palīgā varat pievienot tādas metodes kā executeProductPurchasesConsume y executeProductPurchasesAcknowledge kas izsauc atbilstošos galapunktus. Atkal ieteicams ieviest atkārtotus mēģinājumus neregulāru kļūmju gadījumā, lai nodrošinātu, ka neviens marķieris nepaliek bīstamā starpstāvoklī.
Paplašināta testēšana ar Play Billing Lab
Viens aspekts, ko daudzi izstrādātāji nenovērtē, ir testēšanas fāze. Lai palaistu produktu ar zināmu pārliecības pakāpi, jums ir jāspēj simulēt tīkla kļūdas, nestandarta atbildes un robežgadījumiŠeit noder Play Billing Lab — bezmaksas lietotne pakalpojumā Google Play, kas īpaši izstrādāta Play Billing Library integrāciju testēšanai.
Play Billing Lab ietver atbilžu simulators kas ļauj piespiest dažādus BillingResponseCode jūsu lietotnes izsaukumos uz norēķinu bibliotēku. Tādā veidā jūs varat atjaunot scenārijus, kuros, piemēram, klients nevar pabeigt pirkumu tīkla problēmas dēļ, bet jūsu aizmugursistēma pareizi apstrādā RTDN un galu galā piešķir tiesības bez lietotāja iejaukšanās.
Lai jūsu lietotne varētu sazināties ar simulatoru, jums ir jāiespējo "norēķinu ignorēšanas" testēšana, izmantojot metadatus. 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>
Etiķete enableBillingOverridesTestēšana Aktivizējiet simulētās atbildes testus norēķinu bibliotēkā. Birka NONPRODUCTION ir sava veida atgādinājums, ka šo versiju nevajadzētu nodot ražošanai ar aktīvām ignorēšanas iespējām. Sagatavojot galīgo versiju lietotājiem, noteikti pārliecinieties, ka Noņemiet šos metadatus vai izmantojiet atsevišķu manifestu.
Kad konfigurēšana ir pabeigta, lietotnē Play Billing Lab piesakieties ar licences testētāja kontu, aktivizējiet opciju “Simulēt Play Billing Library atbildi” un atlasiet, kurus kļūdu kodus vēlaties atgriezt katram API (piemēram, konkrētu kļūdu consumeAsyncPēc tam vienkārši atveriet lietotni un palaidiet plūsmu, kuru vēlaties testēt: simulators atgriezīs konfigurētās atbildes, un jūs varat pārbaudīt, vai atkārtotas mēģināšanas loģika, kļūdu apstrāde un RTDN darbojas, kā paredzēts.
Galvenās API izmaiņas, migrējot uz Play Billing Library 7
Papildus RTDN un testēšanai migrācija uz PBL 7 ietver dažu specifisku API punktu risināšanu. Tiem, kas pāriet no PBL 5 vai 6, ir vērts pārskatīt svarīgākās izmaiņas, lai nodrošinātu, ka projekts kompilējas vienmērīgi un biznesa loģika saglabājas konsekventa.
Pirmkārt, API, kas saistīti ar Proporcionalitātes režīms Abonementa maiņas opcijas ir noņemtas. Tagad tiek izmantots sekojošais: Aizstāšanas režīms lai pārvaldītu plāna izmaiņas (jauninājumus, pazeminājumus utt.). Ja joprojām izmantojat tādas metodes kā setReplaceProrationMode o setReplaceSkusProrationModeJums tie būs jāmigrē uz jaunākajiem variantiem setSubscriptionReplacementMode un pielāgojiet loģiku atbilstoši atjauninātajai dokumentācijai.
Arī API ir noņemta. launchPriceConfirmationFlowkas jau bija atzīmēts kā novecojis. Lai apstrādātu abonementa cenu izmaiņas, jums jāiepazīstas ar jaunajām darbplūsmām un ieteikumiem cenu izmaiņu rokasgrāmatā, kurā ir sīki aprakstīts, kā pareizi informēt lietotāju un kā pārvaldīt piekrišanu.
Vēl viens svarīgs punkts ir Alternatīvas norēķinu APIMetodes BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails ir pazuduši par labu saskaņotākai nomenklatūrai: tagad jums ir jāizmanto BillingClient.Builder.enableUserChoiceBilling() kliķe UserChoiceBillingListener y UserChoiceDetailsPēc paša Google teiktā, tā būtībā ir nosaukuma maiņa bez izmaiņām uzvedībā kontekstā, ko raksturo tādi līgumi kā Google un Epic Games vienojas atvērt Android platformu.
Visbeidzot, tiek ievadīts jauns kļūdas kods. TĪKLA_KĻŪDA en BillingResultun nozīmes un nosacījumi SERVICE_TIMEOUT un SERVICE_UNAVAILABLEJa jums ir pielāgota kļūdu apstrādes loģika (piemēram, lai noteiktu, kad lietotājam parādīt ziņojumu, kad mēģināt vēlreiz bez iepriekšēja brīdinājuma utt.), ieteicams to pārskatīt, lai ņemtu vērā šīs jaunās nianses.
Neapstiprināti darījumi un pasūtījuma ID neesamība līdz PURCHASED
Neliela izmaiņa PBL 7 ir tā, ka bibliotēka vairs neģenerē Pasūtījuma ID neapstiprinātiem pirkumiem. Šajos gadījumos, orderId Tas būs pieejams tikai tad, kad pirkums sasniegs statusu PURCHASED. Tas jo īpaši ietekmē darbplūsmas, kurās jau no paša sākuma kā galveno atsauci izmantojāt pasūtījuma ID.
Google ieteikums ir paļauties uz purchaseToken jūsu uzskaitei un saskaņošanaivismaz kamēr darījums vēl nav apstrādāts. Ja atrodat pirkumu, kas ir pazudis no pakalpojuma Play, pārbaudiet Ko darīt, ja pirkums pazūd.
Ja vēl neesat strādājis ar nesamaksātajiem atlikumiem, pārskatiet Billing Library integrācijas rokasgrāmatu un dokumentāciju vietnē iepirkumu dzīves cikla pārvaldībaTur jūs atradīsiet dažādos stāvokļus, kā reaģēt uz katru no tiem un kā RTDN iederas šajā mīklā.
Jaunas papildu iespējas PBL 7: virtuālie maksājumi un priekšapmaksas
Starp PBL 7 "jaukajām" jaunajām funkcijām ir virtuālās maksas abonementi (virtuālie abonementi ar nomaksu) un paplašināts atbalsts gaidāmajiem pirkumiem priekšapmaksas abonementiem. Šīs funkcijas nav obligātas, taču tās var sniegt jums lielāku elastību, pielāgojot savu biznesa modeli dažādiem tirgiem.
Virtuālie maksājumi ļauj lietotājam norēķināties par ilgtermiņa abonementu nelieli periodiski maksājumiGoogle paskaidro, ka izstrādātāju norēķinu nolūkos jūs turpināt saņemt ikmēneša maksājumus saskaņā ar gada plānu ar ikmēneša maksājumiem, nevis vienu lielu maksājumu, bet gan ikmēneša maksājumus. Ja lietotājs nokavē maksājumu, ne jums, ne Google nevajadzētu mēģināt atgūt iepriekšējos maksājumus. Tas padara tā praktisko lietojumu diezgan līdzīgu standarta ikmēneša abonementam, vismaz sākotnēji.
Pagaidām šīs abonēšanas maksas ir pieejamas tikai šādās valstīs: Brazīlija, Francija, Itālija un SpānijaGoogle iesaka sekot līdzi Play Console jaunpienācēju atbalstītajām valstīm. Konfigurēšana tiek veikta, izmantojot ProductDetails.InstallmentPlanDetails un ievērojot konkrēto rokasgrāmatu, lai tos integrētu savā lietotnē.
Paralēli tiek paplašināts atbalsts. neapstiprinātie pirkumi priekšapmaksas abonementiemTagad jūs varat piedāvāt modeļus, kuros lietotājs sāk pirkumu lietotnē un vēlāk pabeidz maksājumu, izmantojot citus līdzekļus, un norēķinu bibliotēka zina, kā pareizi apstrādāt šo plūsmu. Aktivizēšana tiek veikta, izsaucot enablePendingPurchases() inicializējot BillingClient un, īpaši priekšapmaksas plāniem, izmantojot PendingPurchasesParams.Builder.enablePrepaidPlans().
Play Billing Library 5 un 6 nolietojuma periodi
Ar PBL 7 uzstāšanos Google ir noteicis skaidrus datumus 5. un 6. versijas atbalsta atsaukšanaJa joprojām atrodaties kādā no tiem, kalendārs jāatzīmē sarkanā krāsā:
- Google Play Billing Library 5 oficiāli vairs nebūs pieejama jaunām lietotnēm un atjauninājumiem 2024. gada 31. augustā. Ir iespējams pieprasīt pagarinājumu līdz 2024. gada 1. novembrim, taču uz to nevajadzētu paļauties ilgtermiņā.
- Google Play Billing Library 6 var izmantot jaunu lietotņu publicēšanai līdz 2025. gada 1. augustam un esošo lietotņu atjaunināšanai līdz 2025. gada 1. novembrim.
Pēc šī datuma, ja neesat migrējis uz vismaz 6. versiju vai ideālā gadījumā uz 7. versiju, jums būs jāatjaunina uz jaunāko versiju. versija 7Play Console atjauninājumi tiks bloķēti. Lai gan jūsu lietotne turpinās darboties lietotāju ierīcēs, tā nedarbosies, nevarēsiet labot kļūdas vai pievienot jaunas funkcijas, kas ir atkarīgas no publicēšanas veikalā.
.NET MAUI gadījums un pašreizējie ierobežojumi
Ja strādājat ar .NET MAUI un abonementiem operētājsistēmā Android, iespējams, jau esat lasījis vai pieredzējis, ka tas nav tik vienkārši. Daudzos projektos tika izmantots Spraudnis.InAppBilling autors Džeimss Montemagno, taču spraudnis ir arhivēts un netiek uzturēts, tāpēc tas netiks atjaunināts, lai atbalstītu Billing Library 7. Tajā pašā laikā oficiālā pakotne Xamarin.Android.Google.BillingClient Tas ir palicis piesaistīts Xamarin.Android ekosistēmai un nav tieši saderīgs ar .NET MAUI.
Praktiskās sekas ir tādas, ka Play Console brīdina Jūsu lietotne neizmanto Billing Library 7.0.0 vai jaunāku versiju, kas bloķē atjauninājumus, ja turpināt izmantot vecākas bibliotēkas. Daži izstrādātāji ir izvēlējušies radikālus risinājumus, piemēram, īslaicīgi atspējojuši abonementus, lai varētu augšupielādēt versiju, taču tas, protams, nav ilgtspējīgi, ja jūsu biznesa modelis ir atkarīgs no šīs monetizācijas.
Šajā kontekstā daudzas komandas apsver alternatīvas, piemēram, Trešo pušu SDK Šie pakalpojumi jau atbalsta PBL 7 un nodrošina stabilāku, starpplatformu API (piemēram, abonēšanas aizmugursistēmas risinājumus ar SDK operētājsistēmai Android, iOS un citām platformām). Šie pakalpojumi parasti apstrādā norēķinu bibliotēkas versiju migrāciju un nodrošina stabilu apvalku, ievērojami samazinot stresu ar katru jaunu Google novecošanu.
Līdz brīdim, kad Microsoft un MAUI komanda piedāvās Oficiālā pakotne ir atjaunināta un pilnībā saderīga Izmantojot Billing Library 7, iespējas ietver: savas saistīšanas ieviešanu ar vietējo Billing Library, trešās puses pakalpojuma izmantošanu vai pirkumu integrēšanas pārdomāšanu savā MAUI projektā. Jebkurā gadījumā vislabāk nav atlikt lēmumu uz pēdējo brīdi, jo Play termiņi ir fiksēti.
Kopumā Google Play Billing Library v7 atjauninājums ietver atkarību pārskatīšanu, novecojušu API attīrīšanu, aizmugursistēmas loģikas stiprināšanu ar pirkumu verifikāciju un RTDN, kā arī testēšanas rīku, piemēram, Play Billing Lab, izmantošanu, lai atklātu visas kļūdas pirms publicēšanas. Tie, kas veltīs laiku šīs migrācijas precizēšanai, varēs labāk tikt galā ar priekšapmaksas plāniem, virtuālajām maksām, tīkla kļūdām un abonementu dzīves cikla izmaiņām, kā arī viņiem būs daudz lielākas iespējas saglabāt stabilus ieņēmumus un perfektu lietotāja pieredzi pakalpojumā Google Play. Kopīgojiet informāciju, lai vairāk lietotāju varētu uzzināt par šo tēmu.