Kumpletong gabay sa pag-update at pag-deploy ng Google Play Billing Library v7

  • Ang Google Play Billing Library v7 ay nangangailangan ng pag-update ng mga dependency, pagpapalit ng mga hindi na ginagamit na API, at pag-aangkop sa paghawak ng error, habang pinapanatili ang pagiging tugma sa mga nakaraang integration.
  • Ang mga RTDN na may Google Cloud Pub/Sub ay nagbibigay-daan sa iyong i-synchronize ang backend halos sa totoong oras, i-verify ang mga pagbili, at bawasan ang pandaraya sa pamamagitan ng maayos na pamamahala ng purchaseToken at obfuscatedAccountId.
  • Ang mga bagong opsyonal na tampok tulad ng mga virtual na hulugan at mga nakabinbing pagbili sa mga prepaid plan ay nagpapalawak sa kakayahang umangkop ng mga subscription, na nakakaapekto sa ilang merkado.
  • Dahil sa mga huling araw ng paghinto ng paggamit para sa PBL 5 at 6, kinakailangan nang planuhin ang migrasyon ngayon, lalo na sa mga ecosystem tulad ng .NET MAUI kung saan limitado pa rin ang opisyal na suporta.
Joaquin Romero

18 Minutos

Library ng Pagsingil sa Google Play v7

Kung gumagamit ka ng mga in-app purchase sa Android, maaga o huli ay kakailanganin mong harapin ang Library ng Pagsingil sa Google Play v7Hindi ito basta-bastang update lang: may kasama itong mga pagbabago sa API, mga bagong feature ng subscription, mga kinakailangan sa console, at napakalinaw na mga deadline mula sa Google. Hindi na opsyon ang pagbalewala dito kung gusto mong ipagpatuloy ang pag-publish o pag-update ng iyong app sa Google Play nang walang anumang sorpresa.

Sa buong artikulong ito makikita mo kung paano I-update at ipatupad ang Google Play Billing Library v7 Hakbang-hakbang: mula sa kung ano ang pagkakaiba sa PBL 5 at 6, hanggang sa kung paano i-integrate ang mga subscription, mga minsanang pagbili, RTDN, pagsubok gamit ang Play Billing Lab, at kung paano mabuhay sa mga ecosystem tulad ng .NET MAUI kung saan nahuhuli ang opisyal na suporta. Ang ideya ay, kapag natapos mo nang basahin, maaari mong ihanda ang iyong migration nang may kumpiyansa at hindi gumagastos ng kahit isang sentimo.

Pangkalahatang-ideya ng Google Play Billing Library v7

Ang Google Play Billing Library 7 ay nagpapakilala ng mga makabuluhang pagpapabuti sa kung paano pinamamahalaan ang mga bayarin Mga pagbabayad, subscription, at mga espesyal na planoGayunpaman, dinisenyo ito upang gawing medyo maayos ang paglipat. Ang magandang balita ay marami sa mga bagong API ay opsyonal: maaari mong i-update ang dependency, baguhin ang ilang mga sanggunian, at gagana pa rin ang iyong pangunahing integrasyon.

Ang bersyong ito ay nakatuon sa tatlong pangunahing aspeto: mga bagong opsyon sa subscription (tulad ng mga virtual na quota), mas mahusay na suporta para sa mga nakabinbing pagbili sa mga prepaid planat mga pagbabago sa API na naglilinis ng mga bagay na lipas na sa mga nakaraang bersyon (PBL 5 at 6). Bukod pa rito, inaayos ng Google ang ilang paghawak ng error at kung paano mo dapat pangasiwaan ang mga nakabinbing transaksyon upang maiwasan ang mga hindi pagkakapare-pareho.

Para magsimula, sa iyong app module, kailangan mong i-update ang dependency sa iyong file magtayo.gradle:

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

Kapag tapos na ito, oras na para suriin ang code na gumagamit ng mga legacy API. Maraming tawag na may kaugnayan sa prorasyon ng subscription at alternatibong pagsingil Pinalitan o inalis na ang mga ito, kaya mainam na tingnang mabuti ang lahat ng reperensya sa BillingClient at BillingFlowParams bago mag-compile at mag-upload ng kahit ano sa Play Console.

Mga estratehiya sa monetization na may mga minsanang pagbili at subscription

Kapag nagbebenta ka ng mga digital na produkto sa loob ng iyong app, hindi sapat ang simpleng pag-paste ng dialog ng pagbili at pagtatapos nito: pagdidisenyo ng maayos na karanasan ng gumagamit sa buong siklo ng pagbiliIto ay naaangkop sa parehong mga produktong isahan (nakokonsumo o hindi nakokonsumo) at mga subscription. Kung mas natural at walang aberya ang proseso, mas mataas ang mga conversion at mas mababa ang rate ng pagkansela.

Ang karaniwang daloy ng pagbili sa Play Billing, para man sa isang subscription o isang item, ay karaniwang sumusunod sa mga detalyadong yugtong ito na dapat ding malaman ng iyong backend:

  • Sinusuri ng gumagamit ang mga produktong magagamit at pumipili ng isa.
  • Sinisimulan ng app ang proseso ng pagsingil sa Google Play upang makumpleto ang pagbabayad.
  • Nakumpleto na ang pagbili at matatanggap ng iyong app ang resulta.
  • Pinapatunayan ng iyong server ang pagbili gamit ang Google Play Developer API.
  • Ang kaukulang nilalaman o karapatan ay ipinagkakaloob sa gumagamit sa iyong sistema.
  • Ipinaalam sa Google na ang pagbili ay naproseso na (nagamit na o kinilala).

Sa kaso ng mga produktong nauubos, mahalaga na ubusin ang token sa tamang oras upang payagan ang tuluy-tuloy na mga muling pagbili at makatulong I-block ang mga hindi sinasadyang pagbili sa Google PlaySa mga subscription, dapat mong kontrolin ang mga pag-renew, palugit, suspensyon, at pagkansela upang matanggap ng user ang eksaktong halaga ng kanilang binayaran at hindi isang araw na kulang.

Ang pagsasama sa app ay kalahati lamang ng trabaho: dapat mapanatili ng iyong server ang isang maaasahang talaan ng mga karapatan at katayuan ng pagbiliMahalaga ito lalo na kung nag-aalok ka ng cross-platform access o nangangailangan ng detalyadong istatistika sa kita, pagpapanatili, at churn. Dito pumapasok ang mga real-time developer notification (RTDN), na nagsisilbing "black box" ng lifecycle ng pagbili.

Gamit ang RTDN, maaari kang tumugon nang halos real-time sa mga kritikal na kaganapan: isang bagong pagbili, isang pagkabigo sa pag-renew, isang subscription na papasok sa palugit nito, o isang nakanselang pagbili. Nagbibigay-daan ito sa iyo na bumuo ng mga estratehiya para sa pagbawi ng subscriber at pagpigil ng pandaraya, tulad ng awtomatikong pagpapadala ng email kapag nabigo ang isang pagbabayad o mga pagsasaayos ng karapatan kung hindi matanggap ng customer ang mensahe dahil sa mga problema sa network.

Mga real-time na notification ng developer (RTDN) at Google Cloud Pub/Sub

Paggamit ng mga RTDN Google Cloud Pub/Sub bilang isang real-time messaging system sa pagitan ng Google Play at ng iyong backend. Nagpa-publish ang Google Play ng mga event tungkol sa isang paksang Pub/Sub, at nag-subscribe ka sa paksang iyon para makatanggap ng mga mensahe tuwing magbabago ang status ng isang pagbili o subscription.

Simple lang ang proseso: Magpapadala ang Google Play ng mensaheng naka-encode sa base64 papunta sa paksang Pub/Sub, kukunin ito ng iyong subscriber, ide-decode, at ipoproseso ang notification. Sa loob ng field data Sa loob ng mensahe ay makakahanap ka ng isang JSON object Abiso ng Developerna kinabibilangan ng impormasyon tulad ng bersyon ng mensahe, pangalan ng pakete, oras ng kaganapan, at partikular na data sa mga minsanang pagbili, mga subscription, mga nakanselang pagbili, o mga pagsubok.

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

Dahil sa mga mensaheng ito, magagawa mo Panatilihing naka-synchronize ang iyong backend kahit na masira ang device ng userIsipin na matagumpay na bumili ang isang user, kinumpirma ito ng Google Play, ngunit nawalan ng koneksyon ang mobile device bago pa man matanggap ng iyong app ang callback mula sa Billing Library. Kung walang RTDN, maaaring hindi mo malalaman. Gamit ang Pub/Sub, makakatanggap ang iyong server ng hiwalay na notification at maaaring ibigay ang entitlement nang hiwalay sa client.

Pag-configure ng Cloud Pub/Sub para sa RTDN

Bago i-activate ang RTDN sa Google Play console, kailangan mong maghanda ng isang proyekto sa Google Cloud Platform (GCP) at i-configure ang Pub/Sub doon. Medyo diretso lang ang proseso, ngunit mas mainam na sundin ito nang mabuti upang maiwasan ang anumang sorpresa sa mga pahintulot o pangalan ng mapagkukunan.

Paglikha ng paksa

Una, kailangan mong lumikha ng isang Paksa ng Pub/Sub na magsisilbing publishing point mo sa Google Play. Mula sa Google Cloud console, piliin ang iyong proyekto, pumunta sa seksyong Pub/Sub, at gumawa ng bagong paksa ayon sa opisyal na gabay na "create topic". Ang resulta ay magkakaroon ng pangalan sa sumusunod na format:

projects/{project_id}/topics/{topic_name}

Ang buong pangalan na iyon ang kailangan mong i-paste sa Play Console kapag na-activate mo ang mga notification.

Paglikha ng suskrisyon

Para mabasa ang mga mensahe sa thread na ito, kailangan mo ng Subskripsyon sa Pub/SubMaaari mo itong i-configure bilang itulak o bilang paghilaSa reference codelab, gumagamit tayo ng pull subscription, kung saan ang iyong backend ang nagsisimula ng mga request para makuha ang mga mensahe.

Dapat mong suriin ang mga opsyon sa gabay sa subscriber ng Cloud Pub/Sub upang magpasya kung ang push o pull ay mas akma para sa iyong arkitektura. Kapag nakapagdesisyon ka na, sundin ang dokumentasyong "add subscription" at i-link ito sa paksang ginawa mo kanina. Mula sa puntong iyon, anumang mensaheng ilalathala ng Google Play sa paksa ay magiging accessible na ng iyong subscriber.

Mga pahintulot para sa Google Play na mag-publish sa iyong tema

Hindi papayagan ng Pub/Sub ang Google Play na mag-publish ng kahit ano maliban kung bibigyan mo ito ng tahasang pahintulot. account ng serbisyoSa Google Cloud console, kailangan mong pumunta sa mga setting ng pahintulot sa paksa at idagdag ang pangunahing isa:

[email protected]

Ibigay sa account na ito ang papel ng Publisher ng Pub/Sub (Tagapaglathala). I-save ang mga pagbabago at mula sa sandaling iyon, makakapagpadala na ang Google Play ng mga RTDN sa iyong tema nang walang problema sa awtorisasyon.

I-activate ang RTDN sa Google Play Console

Library ng Pagsingil sa Google Play v7

Kapag na-configure na ang Pub/Sub, kailangan mong sabihin sa Play Console kung saan magpapadala ng mga notification. Sa loob ng iyong app sa Google Play Console, pumunta sa Mag-monetize gamit ang Play > Mga Setting ng Monetization at hanapin ang seksyon ng mga real-time na abiso ng developer.

Doon kakailanganin mo:

  • Lagyan ng tsek ang kahon upang paganahin ang mga real-time na notification.
  • Ilagay ang buong pangalan ng paksa ng Pub/Sub sa kaukulang field, na isinasaalang-alang ang format. projects/{project_id}/topics/{topic_name}.
  • Magpadala ng mensahe ng pagsubok gamit ang buton ng pagsubok.

Ang mensahe ng pagsubok ay mahalaga upang mapatunayan na ang Ang integrasyon ay mahusay na naipatupad.Kung mayroon kang pull subscription, maaari kang pumunta sa Cloud console, piliin ang subscription, i-click ang "View messages," at i-extract ang test message. Huwag kalimutang gawin ack ng anumang mensaheng iyong binabasa upang maiwasan ang paulit-ulit na pagtanggap.

Para sa mga push subscription, tiyaking natatanggap ng iyong endpoint ang mensahe at tumutugon gamit ang isang wastong HTTP code. Kung may magkamali, magpapakita ang console ng error kapag inilalathala ang pagsubok, kadalasang nauugnay sa pangalan ng paksa o mga pahintulot ng service account.

Mag-subscribe sa mga pagsubok sa app sa Google Play Store
Kaugnay na artikulo:
Kumpletong gabay sa pag-sign up para sa mga pagsubok ng app sa Google Play Store at pag-access sa mga bersyon ng beta, maagang pag-access, at mga libreng pagsubok.

Panghuli, maaari mong i-configure kung aling mga uri ng notification ang gusto mong matanggap: mga subscription at nakanselang pagbili lamang, o lahat ng abiso kabilang ang mga minsanang pagbili (mga kaganapan tulad ng ONE_TIME_PRODUCT_PURCHASED at ONE_TIME_PRODUCT_CANCELED). Kung gumagamit ka rin ng mga natatanging produkto, karaniwang kasanayan na i-activate ang buong set upang mapanatili ang visibility sa lahat ng bagay.

Gumawa ng Pub/Sub subscriber sa iyong backend

Kapag handa na ang tema at suskrisyon, oras na para ipatupad ang isang subscriber na nagbabasa at nagpoproseso ng mga RTDNNagbibigay ang Google ng mga halimbawa sa ilang wika; isang tipikal na kaso sa Java ang gumagamit ng mga Cloud Pub/Sub client library upang magsimula ng isang Subscriber na nakikinig sa mga mensahe at tumatawag sa isang MessageReceiver.

Ang pangkalahatang padron ay palaging pareho: kinukuha mo ang mensahe, idine-decode mo ang field data Kino-convert mo ang base64 sa text, i-parse ang JSON, at kinukuha ang mga kaugnay na field (tulad ng packageName, oneTimeProductNotification o subscriptionNotification) at magpasya kung ano ang gagawin sa iyong sistema. Pagkatapos matagumpay na maproseso ang abiso, dapat mong Kumpirmahin ang mensahe gamit ang isang ack para hindi na ito ipadala muli ng Pub/Sub.

Ipinapakita ng halimbawang code kung paano ini-print ng receiver ang bersyon at pangalan ng package, ngunit sa isang totoong implementasyon ay mas lalapit ka pa: Patatawarin mo ang pagbili, na magbibigay ng karapatan sa tamang gumagamitIa-update mo ang iyong database at, kung kinakailangan, tatawagin ang Play Developer API para gamitin o kilalanin ang pagbili.

Mag-link ng mga notification sa user: gamit ang obfuscatedAccountId

Isang karaniwang problema kapag namamahala ng mga pagbili mula sa server ay ang pag-alam kung kaninong user nabibilang ang isang partikular na notification ng RTDN. Para dito, pinapayagan ka ng Billing Client API na maglakip ng nalilitong pagkakakilanlan ng account kapag sinimulan mo ang daloy ng pagbili: obfuscatedAccountId.

Ang ideya ay gagamit ka ng isang stable identifier mula sa iyong system (halimbawa, ang internal ID ng user) ngunit natatakpan para sa mga kadahilanang pangpribado at seguridadAng halagang ito ay nauugnay sa pagbili at pagkatapos ay lumalabas sa impormasyong ibinalik mula sa Google Play Developer API, upang kapag natanggap mo ang RTDN at na-verify ang token, malalaman mo nang walang pag-aalinlangan kung aling account sa iyong database ang dapat mong ibigay ang karapatan.

Sa panig ng kostumer, kapag inihahanda ang BillingFlowParamsKailangan mo lang buuin ang listahan ng mga ProductDetailsParams at tumawag setObfuscatedAccountId(obfuscatedAccountId) bago ilunsad ang daloy. Hindi nito binabago ang nakikitang karanasan ng gumagamit, ngunit lubos nitong pinapasimple ang proseso. lohika ng alokasyon ng pagbili sa backend at tumutulong sa Google na matukoy ang pandaraya.

I-verify ang mga pagbili gamit ang Google Play Developer API

Bago magbigay ng anumang karapatan sa iyong server, kinakailangang beripikahin muna kung lehitimo ang pagbili sa pamamagitan ng pagtawag sa Google Play Developer APIHindi sapat ang umasa lang sa sinasabi ng kliyente o kahit ng RTDN: dapat mong patunayan ang purchaseToken direkta laban sa mga opisyal na endpoint, at kung kinakailangan pamahalaan ang mga refund.

Sa kaso ng mga natatanging produkto, gagamitin mo ang endpoint purchases.products:getPara sa mga subscription, ang landas ay patungo sa purchases.subscriptionsv2:getAng inirerekomendang daloy ay:

  • Kunin ang purchaseToken mula sa mensahe ng Pub/Sub.
  • Suriin ang iyong database upang makita kung naproseso mo na ito; ang bawat token ay kakaiba sa buong mundoKaya perpekto ito bilang pangunahing susi upang maiwasan ang mga duplikado.
  • Kung bago ito, tawagan ang Google Play Developer API kasama ang package, SKU, at ang purchaseToken.
  • Tiyaking ang tugon ay nagpapahiwatig ng katayuan ng pagbili BINILI (hindi NAKABIBITIN o kinansela).
  • Kung tugma ang lahat, irehistro ang token at ibigay ang kaukulang karapatan sa nauugnay na gumagamit.

Para makipag-ugnayan sa Play Developer API mula sa Java, maaari mong gamitin ang AndroidPublisher, sinisimulan gamit ang mga kredensyal ng account ng serbisyo sa format na JSON. Ikaw ang magko-configure ng saklaw AndroidPublisherScopes.ANDROIDPUBLISHERBinuo mo ang kliyente at tinatawag ang pamamaraan purchases().products().get(...)Kung mabigo ang tawag dahil sa pansamantalang problema sa network o serbisyo, inirerekomenda ipatupad ang mga retries na may exponential backoff para hindi makaligtaan ang kaganapan.

Kumpirmahin o kumpletuhin ang pagbili mula sa server

Kapag na-verify mo na ang pagbili at naibigay na ang awtorisasyon sa iyong system, ang susunod na hakbang ay ipaalam sa Google na matagumpay na naproseso ang transaksyon. Para sa mga produktong single-item, mayroon kang dalawang opsyon: ubusin ang binili o simpleng kilalanin siya.

Ang mga produktong nauubos (hal., virtual na pera, buhay, atbp.) ay dapat dumaan sa endpoint purchases.products:consumeMinamarkahan nito ang token bilang nagamit na at nagbibigay-daan sa user na bilhin muli ang parehong item nang walang conflict. Para sa mga produktong hindi nauubos (tulad ng pag-unlock ng premium na bersyon habang buhay), dapat kang tumawag purchases.products:acknowledge, na nagpapaalam sa Google na ang user ay mayroon nang kaugnay na karapatan.

Ginagamit ang mga suskrisyon purchases.subscriptions:acknowledgena nagpapahiwatig na ang subscription ay matagumpay na naproseso at naitalaga sa user. Kung hindi mo kinikilala ang isang pagbili sa loob ng makatwirang takdang panahon, maaaring ipagpalagay ng Google na may problema at bawiin ang transaksyon, kaya mahalaga na ikaw ang pagbabalik ay ginagawa pagkatapos ibigay ang karapatan.

Sa iyong AndroidPublisher helper, maaari kang magdagdag ng mga paraan tulad ng executeProductPurchasesConsume y executeProductPurchasesAcknowledge na tumatawag sa mga kaukulang endpoint. Muli, ipinapayong ipatupad ang mga retries kung sakaling magkaroon ng paminsan-minsang pagkabigo, upang matiyak na walang token na mananatiling nasa mapanganib na intermediate state.

Advanced na pagsubok gamit ang Play Billing Lab

Isang aspeto na minamaliit ng maraming developer ay ang yugto ng pagsubok. Para makapaglunsad nang may kumpiyansa, kailangan mong kayanin ang paggaya mga error sa network, mga hindi karaniwang tugon, at mga edge caseDiyan pumapasok ang Play Billing Lab, isang libreng app sa Google Play na partikular na idinisenyo para sa pagsubok ng mga integrasyon ng Play Billing Library.

Kasama sa Play Billing Lab ang isang simulator ng sagot na nagpapahintulot sa pagpilit ng iba't ibang BillingResponseCode sa mga tawag ng iyong app sa Billing Library. Sa ganitong paraan, maaari mong muling likhain ang mga sitwasyon kung saan, halimbawa, hindi makumpleto ng customer ang pagbili dahil sa isang isyu sa network, ngunit maayos na pinoproseso ng iyong backend ang RTDN at sa huli ay ibinibigay ang karapatan nang walang interbensyon ng user.

Para makipag-ugnayan ang iyong app sa simulator, kailangan mong paganahin ang pagsubok na "mga override sa pagsingil" gamit ang metadata sa 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>

Ang label paganahin ang Pagsusuri sa Pagsingil I-activate ang mga simulated response test sa Billing Library. Ang NONPRODUCTION tag ay isang uri ng paalala na ang build na ito ay hindi dapat isagawa nang aktibo ang mga override. Kapag inihahanda ang pinal na bersyon para sa mga user, siguraduhing Alisin ang metadata na ito o gumamit ng hiwalay na manifest.

Kapag na-configure na, mula sa Play Billing Lab app, mag-log in gamit ang isang license tester account, i-activate ang opsyong "Simulate Play Billing Library response", at piliin kung aling mga error code ang gusto mong ibalik para sa bawat API (halimbawa, isang partikular na error sa consumeAsyncPagkatapos ay buksan mo lang ang iyong app at patakbuhin ang daloy na gusto mong subukan: ibabalik ng simulator ang mga na-configure na tugon at maaari mong i-verify na ang iyong retry logic, error handling, at RTDN ay gumagana ayon sa inaasahan.

Mga pangunahing pagbabago sa API kapag lumilipat sa Play Billing Library 7

Bukod sa RTDN at pagsubok, ang paglipat sa PBL 7 ay kinabibilangan ng pagtugon sa ilang partikular na API points. Para sa mga nagmula sa PBL 5 o 6, mahalagang suriin ang mga pinaka-kaugnay na pagbabago upang matiyak na maayos ang pag-compile ng proyekto at nananatiling pare-pareho ang business logic.

Una, ang mga API na may kaugnayan sa ProrationMode Inalis na ang mga opsyon sa pagbabago ng subscription. Ngayon, ang mga sumusunod ang ginagamit: Mode ng Pagpapalit para pamahalaan ang mga pagbabago sa plano (mga pag-upgrade, pagbaba ng antas, atbp.). Kung gumagamit ka pa rin ng mga pamamaraan tulad ng setReplaceProrationMode o setReplaceSkusProrationModeKailangan mong ilipat ang mga ito sa mga bagong variant ng setSubscriptionReplacementMode at isaayos ang lohika ayon sa na-update na dokumentasyon.

Tinanggal na rin ang API launchPriceConfirmationFlowna minarkahan na bilang hindi na ginagamit. Para mapangasiwaan ang mga pagbabago sa presyo ng subscription, dapat mong tingnan ang mga bagong daloy ng trabaho at mga rekomendasyon sa gabay sa pagbabago ng presyo, na nagdedetalye kung paano wastong ipaalam sa user at kung paano pamahalaan ang pahintulot.

Ang isa pang mahalagang punto ay ang Mga alternatibong billing APIAng mga pamamaraan BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails ay nawala pabor sa isang mas nakahanay na katawagan: ngayon dapat mong gamitin BillingClient.Builder.enableUserChoiceBilling() junto isang UserChoiceBillingListener y UserChoiceDetailsAyon mismo sa Google, ito ay karaniwang isang pagpapalit ng pangalan na walang mga pagbabago sa pag-uugali, sa isang kontekstong minarkahan ng mga kasunduan tulad ng Nagkasundo ang Google at Epic Games na buksan ang Android.

Sa wakas, isang bagong error code ang ipinasok. NETWORK_ERROR en BillingResultat ang mga kahulugan at kundisyon ng SERVICE_TIMEOUT at SERVICE_UNAVAILABLEKung mayroon kang pasadyang lohika sa paghawak ng error (halimbawa, pagpapasya kung kailan ipapakita ang isang mensahe sa user, kung kailan tahimik na susubukan muli, atbp.), ipinapayong suriin ito upang isaalang-alang ang mga bagong nuances na ito.

Mga nakabinbing transaksyon at kawalan ng orderId hanggang sa MABILI

Isang banayad na pagbabago sa PBL 7 ay ang hindi na pagbuo ng library ng Order ID para sa mga nakabinbing pagbili. Sa mga kasong ito, ang orderId Magiging available lamang ito kapag ang binili ay umabot na sa estadong BINILI. Lalo na nitong naaapektuhan ang mga workflow kung saan ginamit mo ang order ID bilang pangunahing sanggunian mula sa simula.

Ang rekomendasyon ng Google ay umasa ka sa pagbili ng Token para sa iyong mga rekord at pagkakasundokahit man lang habang nakabinbin ang transaksyon. Kung may makita kang binili na nawala sa Play, tingnan Ano ang gagawin kung mawala ang binili.

Kung hindi mo pa naaayos ang mga natitirang balanse, suriin ang gabay at dokumentasyon ng pagsasama ng Billing Library sa pamamahala ng lifecycle ng pagkuhaDoon mo makikita ang iba't ibang estado, kung paano tumugon sa bawat isa, at kung paano nababagay ang mga RTDN sa palaisipang ito.

Mga bagong opsyonal na kakayahan sa PBL 7: mga virtual na hulugan at mga paunang bayad

Kabilang sa mga "magaganda" na bagong tampok ng PBL 7 ay ang mga subscription sa virtual na bayad (mga virtual na installment subscription) at pinalawak na suporta para sa mga nakabinbing pagbili para sa mga prepaid subscription. Ang mga feature na ito ay hindi mandatory, ngunit maaari ka nitong bigyan ng higit na kakayahang umangkop kapag iniaangkop ang iyong modelo ng negosyo sa iba't ibang merkado.

Ang mga virtual na hulugan ay nagbibigay-daan sa isang gumagamit na magbayad para sa isang mas pangmatagalang subscription sa maliliit na pana-panahong pagbabayadSa halip na isang malaking bayad lamang, ipinaliwanag ng Google na para sa mga layunin ng pagsingil ng developer, patuloy kang makakatanggap ng mga buwanang bayad sa ilalim ng isang taunang plano na may mga buwanang hulugan. Kung ang isang user ay hindi makabayad, hindi ninyo dapat subukang bawiin ni ng Google ang mga nakaraang hulugan. Ginagawa nitong halos kapareho ng isang karaniwang buwanang subscription ang praktikal na paggamit nito, kahit man lang sa simula.

Sa ngayon, ang mga bayarin sa subscription na ito ay makukuha lamang sa Brazil, Pransya, Italya at EspanyaInirerekomenda ng Google na bantayan ang Play Console para sa mga bagong sinusuportahang bansa. Ginagawa ang pag-configure sa pamamagitan ng ProductDetails.InstallmentPlanDetails at pagsunod sa partikular na gabay upang maisama ang mga ito sa iyong app.

Kasabay nito, ang suporta ay pinalalawak mga nakabinbing pagbili para sa mga prepaid na subscriptionNgayon ay maaari ka nang mag-alok ng mga modelo kung saan sisimulan ng user ang pagbili sa app at kukumpletuhin ang pagbabayad sa ibang pagkakataon sa pamamagitan ng iba pang paraan, at alam ng Billing Library kung paano pangasiwaan nang tama ang daloy na iyon. Ginagawa ang pag-activate sa pamamagitan ng pagtawag enablePendingPurchases() kapag ini-initialize ang BillingClient at, partikular para sa mga prepaid plan, gamit ang PendingPurchasesParams.Builder.enablePrepaidPlans().

Mga panahon ng depreciation para sa Play Billing Library 5 at 6

Dahil sa PBL 7 na naganap, nagtakda ang Google ng malinaw na mga petsa para sa pag-alis ng suporta para sa mga bersyon 5 at 6Kung ikaw ay nasa alinman sa mga ito pa rin, dapat mong markahan ang kalendaryo ng pula:

  • Opisyal nang hindi na gagamitin ang Google Play Billing Library 5 sa Agosto 31, 2024, para sa mga bagong app at update. Posibleng humiling ng extension hanggang Nobyembre 1, 2024, ngunit hindi ito isang bagay na dapat mong asahan sa pangmatagalan.
  • Maaaring gamitin ang Google Play Billing Library 6 para mag-publish ng mga bagong app hanggang Agosto 1, 2025, at para i-update ang mga kasalukuyang app hanggang Nobyembre 1, 2025.

Pagkatapos ng petsang iyon, kung hindi ka pa lumilipat sa kahit man lang bersyon 6 o mas mainam kung sa bersyon 7, kakailanganin mong mag-update sa pinakabagong bersyon. bersyon 7Magkakaroon ng mga update na maba-block sa Play Console. Bagama't patuloy na gagana ang iyong app sa mga device ng mga user, mapi-freeze ka, hindi makakapag-ayos ng mga bug o makakapagdagdag ng mga bagong feature na nakadepende sa pag-publish sa store.

Ang kaso ng .NET MAUI at mga kasalukuyang limitasyon

Kung gumagamit ka ng .NET MAUI at mga subscription sa Android, malamang nabasa o naranasan mo na na hindi ito ganoon kadali. Maraming proyekto ang gumamit Plugin.InAppBilling ni James Montemagno, ngunit ang plugin ay naka-archive at hindi pinapanatili, kaya hindi ito ia-update upang suportahan ang Billing Library 7. Kasabay nito, ang opisyal na pakete Xamarin.Android.Google.BillingClient Nanatili itong nakaangkla sa ecosystem ng Xamarin.Android at hindi direktang tugma sa .NET MAUI.

Ang praktikal na bunga ay ang Mga babala ng Play Console Hindi gumagamit ang iyong app ng Billing Library 7.0.0 o mas bago, na humaharang sa mga update kung patuloy kang gagamit ng mga lumang library. May ilang developer na pumili ng mga matinding solusyon, tulad ng pansamantalang pag-disable ng mga subscription para makapag-upload ng bersyon, ngunit malinaw na hindi iyon sustainable kung ang modelo ng iyong negosyo ay nakasalalay sa monetization na iyon.

Sa kontekstong ito, maraming koponan ang isinasaalang-alang ang mga alternatibo tulad ng Mga third-party na SDK Sinusuportahan na ng mga serbisyong ito ang PBL 7 sa ilalim at nagpapakita ng mas matatag at cross-platform na API (halimbawa, mga solusyon sa backend ng subscription na may mga SDK para sa Android, iOS, at iba pang mga platform). Karaniwang pinangangasiwaan ng mga serbisyong ito ang mga paglilipat ng bersyon ng Billing Library at nagpapakita ng isang matatag na wrapper, na makabuluhang binabawasan ang stress sa bawat bagong paghinto ng paggamit ng Google.

Hanggang sa mag-alok ang Microsoft at ang pangkat ng MAUI ng Na-update at ganap na tugma ang opisyal na pakete Sa Billing Library 7, kabilang sa mga opsyon ang: pagpapatupad ng sarili mong binding sa native Billing Library, paggamit ng third-party service, o pag-iisip muli kung paano mo isasama ang mga pagbili sa loob ng iyong MAUI project. Sa anumang kaso, mas mainam na huwag ipagpaliban ang desisyon hanggang sa huling minuto, dahil nakatakda na ang mga deadline ng Play.

Library ng Pagsingil sa Google Play v7
Kaugnay na artikulo:
Paano humiling ng refund para sa mga pagbili sa Google Play nang paunti-unti

Sa pangkalahatan, ang update sa Google Play Billing Library v7 ay kinabibilangan ng pagsusuri sa mga dependency, paglilinis ng mga hindi na ginagamit na API, pagpapalakas ng backend logic gamit ang purchase verification at RTDN, at paggamit ng mga testing tool tulad ng Play Billing Lab upang matuklasan ang lahat ng bug bago ito ilunsad. Ang mga maglalaan ng oras upang pinuhin ang migration na ito ay mas makakayanan ang mga prepaid plan, virtual fees, network error, at mga pagbabago sa lifecycle ng subscription, at magkakaroon ng mas malaking pagkakataon na mapanatili ang matatag na kita at isang maayos na karanasan ng user sa Google Play. Ibahagi ang impormasyon para mas maraming user ang matuto tungkol sa paksa.


Idagdag bilang ginustong mapagkukunan