Google Play 결제 라이브러리 v7 업데이트 및 배포 완벽 가이드

안드로이드에서 인앱 구매를 다루는 일을 한다면, 조만간 다음과 같은 문제에 직면하게 될 것입니다. Google Play 결제 라이브러리 v7이번 업데이트는 단순한 업데이트가 아닙니다. API 변경, 새로운 구독 기능, 콘솔 요구 사항, 그리고 구글이 제시하는 명확한 마감일이 포함되어 있습니다. 구글 플레이 스토어에 앱을 게시하거나 업데이트하는 과정에서 예상치 못한 문제가 발생하지 않으려면 더 이상 이번 업데이트를 무시할 수 없습니다.

이 기사 전체에서 다음 내용을 볼 수 있습니다. Google Play 결제 라이브러리 v7을 업데이트하고 구현합니다. 단계별 안내: PBL 5 및 6의 차이점부터 구독, 일회성 구매, RTDN 통합, Play Billing Lab을 사용한 테스트, 그리고 공식 지원이 뒤처지는 .NET MAUI와 같은 생태계에서 살아남는 방법까지 다룹니다. 이 책을 다 읽고 나면, 단 한 푼도 들이지 않고 자신 있게 마이그레이션을 준비할 수 있을 것입니다.

Google Play 결제 라이브러리 v7 개요

Google Play 결제 라이브러리 7은 결제 관리 방식을 크게 개선했습니다. 결제, 구독 및 특별 플랜하지만 이는 마이그레이션을 비교적 원활하게 진행하도록 설계되었습니다. 다행히 새로운 API 중 상당수는 선택 사항입니다. 종속성을 업데이트하고 몇 가지 참조를 수정하면 기본적인 통합 기능은 계속 작동합니다.

이번 버전은 세 가지 핵심 영역에 중점을 둡니다. 새로운 구독 옵션 (가상 할당량과 같은) 더 나은 지원 선불 요금제 보류 중인 구매또한 이전 버전(PBL 5 및 6)에서 이미 사용되지 않던 부분을 정리하는 API 변경 사항이 포함되어 있습니다. 더불어 Google은 일관성을 유지하기 위해 오류 처리 방식과 보류 중인 거래 처리 방식을 일부 조정했습니다.

먼저 앱 모듈에서 해당 파일의 종속성을 업데이트해야 합니다. build.gradle:

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

이 작업이 완료되면 레거시 API를 사용하는 코드를 검토할 차례입니다. 많은 호출이 다음과 관련되어 있습니다. 구독 비례 배분 및 대체 청구 해당 항목들은 이름이 변경되었거나 삭제되었으므로, Play Console에 업로드하기 전에 BillingClient 및 BillingFlowParams에 대한 모든 참조를 꼼꼼히 살펴보는 것이 좋습니다.

일회성 구매 및 구독을 활용한 수익 창출 전략

앱 내에서 디지털 제품을 판매할 때, 단순히 구매 대화 상자를 붙여넣는 것만으로는 충분하지 않습니다. 디자인적인 측면에서 접근해야 합니다. 전체 구매 과정에서 원활한 사용자 경험 제공이는 단일 제품(소모품 또는 비소모품)과 구독 서비스 모두에 적용됩니다. 과정이 자연스럽고 원활할수록 전환율은 높아지고 해지율은 낮아집니다.

Play Billing을 이용한 일반적인 구매 흐름은 구독이든 단일 상품이든 관계없이 다음과 같은 명확한 단계를 따르며, 백엔드 시스템에서도 이러한 단계를 숙지하고 있어야 합니다.

사용자는 이용 가능한 제품을 살펴보고 하나를 선택합니다.
앱은 결제를 완료하기 위해 Google Play 결제 프로세스를 시작합니다.
구매가 완료되었고 앱은 결과를 수신합니다.
서버는 Google Play 개발자 API를 통해 구매를 검증합니다.
해당 콘텐츠 또는 권한은 시스템에서 사용자에게 부여됩니다.
구글은 구매가 처리(소비 또는 확인)되었다는 알림을 받습니다.

소비재의 경우, 다음 사항이 매우 중요합니다. 적절한 시기에 토큰을 사용하세요 원활한 재구매를 가능하게 하고 도움을 주기 위해 Google Play에서 실수로 구매하는 것을 차단하세요구독 서비스에서는 갱신, 유예 기간, 일시 중단 및 취소를 관리하여 사용자가 지불한 금액에 해당하는 서비스를 정확하게 받을 수 있도록 해야 합니다.

앱과의 통합은 작업의 절반에 불과합니다. 서버는 다음을 유지 관리해야 합니다. 권리 및 구매 현황에 대한 신뢰할 수 있는 기록특히 여러 플랫폼에서 접근이 가능하거나 매출, 유지율, 이탈률에 대한 자세한 통계가 필요한 경우 이러한 기능이 더욱 중요합니다. 바로 이럴 때 실시간 개발자 알림(RTDN)이 구매 라이프사이클의 "블랙박스" 역할을 하며 유용하게 활용됩니다.

RTDN을 사용하면 신규 구매, 갱신 실패, 구독 유예 기간 진입 또는 구매 취소와 같은 중요한 이벤트에 거의 실시간으로 대응할 수 있습니다. 이를 통해 전략을 수립할 수 있습니다. 가입자 복구 및 사기 예방예를 들어 결제가 실패했을 때 자동으로 이메일을 보내거나 네트워크 문제로 고객이 메시지를 받지 못한 경우 권한을 조정하는 기능 등이 있습니다.

실시간 개발자 알림(RTDN) 및 Google Cloud Pub/Sub

RTDN은 사용합니다 Google 클라우드 게시/구독 Google Play와 백엔드 간의 실시간 메시징 시스템 역할을 합니다. Google Play는 게시/구독 주제에 대한 이벤트를 게시하고, 해당 주제를 구독하면 구매 또는 구독 상태가 변경될 때마다 메시지를 수신할 수 있습니다.

기본 흐름은 간단합니다. Google Play는 base64로 인코딩된 메시지를 Pub/Sub 토픽으로 보내고, 구독자는 이를 추출하고 디코딩하여 알림을 처리합니다. data 메시지 안에 JSON 객체가 있습니다. 개발자 알림여기에는 메시지 버전, 패키지 이름, 이벤트 시간, 일회성 구매, 구독, 취소된 구매 또는 체험판에 대한 특정 데이터와 같은 정보가 포함됩니다.

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

이 메시지들 덕분에 여러분은 사용자 기기에 문제가 발생하더라도 백엔드 데이터를 동기화 상태로 유지하세요.사용자가 구매를 성공적으로 완료하고 Google Play에서 구매를 확인했지만, 앱이 결제 라이브러리로부터 콜백을 받기 전에 모바일 기기의 연결이 끊어졌다고 가정해 보세요. RTDN이 없다면 이러한 상황을 전혀 알 수 없을 수도 있습니다. 하지만 Pub/Sub을 사용하면 서버는 클라이언트와 별도로 알림을 받고 클라이언트와 관계없이 권한을 부여할 수 있습니다.

RTDN용 클라우드 Pub/Sub 구성

Google Play 콘솔에서 RTDN을 활성화하기 전에 프로젝트를 준비해야 합니다. Google Cloud Platform (GCP) 그리고 거기서 Pub/Sub을 구성하세요. 과정은 비교적 간단하지만, 권한이나 리소스 이름 관련해서 예상치 못한 문제가 발생하지 않도록 주의 깊게 따라하는 것이 좋습니다.

주제 만들기

먼저 생성해야 합니다. 게시글/하위 주제 이는 Google Play 게시 지점 역할을 합니다. Google Cloud 콘솔에서 프로젝트를 선택하고, 게시/구독 섹션으로 이동하여 공식 "토픽 생성" 가이드에 따라 새 토픽을 생성합니다. 생성된 토픽의 이름은 다음과 같은 형식입니다.

projects/{project_id}/topics/{topic_name}

알림을 활성화할 때 플레이 콘솔에 붙여넣어야 하는 이름이 바로 그 전체 이름입니다.

구독 생성

이 스레드의 메시지를 읽으려면 다음이 필요합니다. 펍/구독다음과 같이 설정할 수 있습니다. 푸시 또는 당겨이 참조 코드랩에서는 백엔드에서 메시지 검색 요청을 시작하는 풀 구독 방식을 사용합니다.

클라우드 게시/구독 가이드의 옵션을 검토하여 푸시 방식과 풀 방식 중 어떤 것이 아키텍처에 더 적합한지 결정하세요. 결정 후에는 "구독 추가" 문서를 참조하여 이전에 생성한 토픽에 연결하세요. 그러면 Google Play에서 해당 토픽에 게시하는 모든 메시지를 구독자가 확인할 수 있습니다.

Google Play에서 테마를 게시할 수 있도록 권한을 부여합니다.

Pub/Sub은 사용자가 명시적으로 허용하지 않는 한 Google Play에서 어떤 콘텐츠도 게시할 수 없도록 합니다. 서비스 계정Google Cloud 콘솔에서 토픽 권한 설정으로 이동하여 기본 권한을 추가해야 합니다.

[email protected]

이 계정에 다음 역할을 부여하세요 출판사/하위 출판사 (게시자). 변경 사항을 저장하면 그 시점부터 Google Play는 권한 문제 없이 테마에 RTDN을 보낼 수 있습니다.

Google Play 콘솔에서 RTDN을 활성화하세요

Pub/Sub 설정이 완료되면 Play Console에 알림을 보낼 위치를 알려줘야 합니다. Google Play Console의 앱에서 다음 경로로 이동하세요. Play 스토어에서 수익 창출하기 > 수익 창출 설정 그리고 실시간 개발자 알림 섹션을 찾으세요.

거기서는 다음이 필요합니다.

실시간 알림을 활성화하려면 확인란을 선택하세요.
해당 필드에 게시글/하위 주제어의 전체 이름을 형식에 맞춰 입력하십시오. projects/{project_id}/topics/{topic_name}.
테스트 버튼을 사용하여 테스트 메시지를 보내세요.

테스트 메시지는 다음을 확인하는 데 필수적입니다. 통합이 잘 구현되었습니다.풀 구독을 사용하는 경우 클라우드 콘솔로 이동하여 구독을 선택하고 "메시지 보기"를 클릭한 다음 테스트 메시지를 추출할 수 있습니다. 잊지 마세요. 포장전시회 중복 수신을 방지하기 위해 읽은 메시지는 모두 삭제했습니다.

푸시 구독의 경우 엔드포인트가 메시지를 수신하고 유효한 HTTP 코드로 응답하는지 확인하세요. 문제가 발생하면 테스트를 게시할 때 콘솔에 오류가 표시되며, 일반적으로 토픽 이름 또는 서비스 계정 권한과 관련된 오류입니다.

백엔드에서 발행/구독 시스템을 구축하세요.

테마와 구독 준비가 완료되었으니 이제 실행에 옮길 차례입니다. RTDN을 읽고 처리하는 구독자Google은 여러 언어로 된 예제를 제공합니다. Java의 일반적인 예에서는 Cloud Pub/Sub 클라이언트 라이브러리를 사용하여 서비스를 시작합니다. Subscriber 메시지를 듣고 전화를 거는 사람 MessageReceiver.

일반적인 패턴은 항상 동일합니다. 메시지를 가져오고 필드를 디코딩합니다. data base64를 텍스트로 변환하고, JSON을 파싱한 다음, 관련 필드(예: packageName, oneTimeProductNotification o subscriptionNotification) 그리고 시스템에서 어떻게 처리할지 결정하십시오. 알림을 성공적으로 처리한 후에는 다음을 수행해야 합니다. 확인 응답(ACK)으로 메시지를 확정하세요. 그러면 Pub/Sub에서 해당 내용을 다시 보내지 않습니다.

예제 코드는 수신자가 버전과 패키지 이름을 출력하는 방법을 보여주지만, 실제 구현에서는 더 많은 내용을 출력해야 합니다. 구매를 승인하고 올바른 사용자에게 권한을 부여하면 됩니다.데이터베이스를 업데이트하고 필요한 경우 Play 개발자 API를 호출하여 구매를 처리하거나 인식하면 됩니다.

사용자에게 링크 알림 전송: 난독화된 계정 ID 사용

서버에서 구매를 관리할 때 흔히 발생하는 문제는 특정 RTDN 알림이 어떤 사용자에게 속하는지 파악하는 것입니다. 이를 위해 청구 클라이언트 API는 특정 RTDN 알림을 첨부할 수 있도록 지원합니다. 난독화된 계정 식별자 구매 절차를 시작할 때: obfuscatedAccountId.

핵심은 시스템에서 안정적인 식별자(예: 사용자의 내부 ID)를 사용하는 것입니다. 개인 정보 보호 및 보안상의 이유로 내용이 가려졌습니다.이 값은 구매와 연결되어 Google Play 개발자 API에서 반환되는 정보에 나타나므로, RTDN을 수신하고 토큰을 확인하면 데이터베이스에서 어떤 계정에 권한을 부여해야 하는지 명확하게 알 수 있습니다.

고객 입장에서 준비할 때 BillingFlowParams여러분은 단순히 목록을 작성하기만 하면 됩니다. ProductDetailsParams 그리고 전화 setObfuscatedAccountId(obfuscatedAccountId) 워크플로를 시작하기 전에 이 작업을 수행합니다. 이는 사용자에게 보이는 경험을 바꾸지는 않지만 프로세스를 크게 간소화합니다. 백엔드 구매 할당 로직 또한 구글이 사기 행위를 감지하는 데 도움이 됩니다.

Google Play 개발자 API를 사용하여 구매를 인증하세요

서버에 대한 권한을 부여하기 전에, 반드시 전화로 구매가 합법적인지 확인해야 합니다. Google Play 개발자 API클라이언트나 RTDN의 말에만 의존해서는 충분하지 않습니다. 반드시 검증해야 합니다. purchaseToken 공식 엔드포인트에 직접 대응하고, 필요한 경우 환불 관리.

고유한 제품의 경우 엔드포인트를 사용합니다. purchases.products:get구독의 경우, 경로는 다음과 같습니다. purchases.subscriptionsv2:get권장되는 흐름은 다음과 같습니다.

추출 purchaseToken Pub/Sub 메시지에서 가져온 내용입니다.
데이터베이스에서 해당 토큰이 이미 처리되었는지 확인하세요. 각 토큰은 다음과 같습니다. 전 세계적으로 유일무이한그래서 중복을 방지하기 위한 기본 키로 사용하기에 완벽합니다.
새로운 앱이라면 패키지, SKU 및 기타 정보를 사용하여 Google Play 개발자 API를 호출하세요. purchaseToken.
응답에 구매 상태가 표시되는지 확인하십시오. 구입 한 (보류 중이거나 취소된 상태가 아닙니다.)
모든 조건이 일치하면 토큰을 등록하고 해당 사용자에게 상응하는 권한을 부여합니다.

Java에서 Play 개발자 API와 통신하려면 다음을 사용할 수 있습니다. 안드로이드퍼블리셔JSON 형식의 서비스 계정 자격 증명으로 초기화됩니다. 스코프를 구성할 수 있습니다. AndroidPublisherScopes.ANDROIDPUBLISHER클라이언트를 빌드하고 해당 메서드를 호출합니다. purchases().products().get(...)일시적인 네트워크 또는 서비스 문제로 통화가 실패하는 경우, 다음을 권장합니다. 지수 백오프를 사용하여 재시도 방식을 구현합니다. 행사를 놓치지 않기 위해서요.

서버에서 구매를 확인하거나 완료하세요.

구매를 확인하고 시스템에서 승인을 완료했으면 다음 단계는 거래가 성공적으로 처리되었음을 Google에 알리는 것입니다. 단일 품목 제품의 경우 두 가지 옵션이 있습니다. 구매한 것을 소비하세요 오 simplemente 그녀를 알아보다.

소모성 제품(예: 가상 화폐, 생명 등)은 엔드포인트를 거쳐야 합니다. purchases.products:consume이렇게 하면 토큰이 사용된 것으로 표시되어 사용자가 충돌 없이 동일한 항목을 다시 구매할 수 있습니다. 소모품이 아닌 제품(예: 프리미엄 버전 평생 이용권)의 경우, 해당 기능을 호출해야 합니다. purchases.products:acknowledge이는 사용자가 이미 해당 권한을 가지고 있음을 구글에 알리는 것입니다.

구독이 사용됩니다 purchases.subscriptions:acknowledge구독이 성공적으로 처리되어 사용자에게 할당되었음을 나타냅니다. 적절한 시간 내에 구매를 확인하지 않으면 Google에서 문제가 있다고 판단하여 거래를 취소할 수 있으므로, 구매 확인을 신속하게 처리하는 것이 중요합니다. 복귀는 권한을 부여한 직후에 이루어집니다..

AndroidPublisher 헬퍼에 다음과 같은 메서드를 추가할 수 있습니다. executeProductPurchasesConsume y executeProductPurchasesAcknowledge 해당 엔드포인트를 호출합니다. 마찬가지로, 토큰이 위험한 중간 상태에 남아 있지 않도록 하기 위해 간헐적인 오류 발생 시 재시도 기능을 구현하는 것이 좋습니다.

Play Billing Lab을 이용한 고급 테스트

많은 개발자들이 간과하는 부분 중 하나는 테스트 단계입니다. 어느 정도 확신을 가지고 제품을 출시하려면 다양한 상황을 시뮬레이션할 수 있어야 합니다. 네트워크 오류, 비표준 응답 및 예외 상황바로 이런 문제를 해결하기 위해 Play Billing Lab이라는 앱이 개발되었습니다. 이 앱은 Google Play에서 무료로 다운로드할 수 있으며, Play Billing Library 연동 테스트를 위해 특별히 설계되었습니다.

Play Billing Lab에는 다음이 포함됩니다. 답변 시뮬레이터 이는 서로 다른 것을 강제할 수 있게 해줍니다. BillingResponseCode 앱에서 결제 라이브러리를 호출할 때 이 부분을 추가하세요. 이렇게 하면 예를 들어 고객이 네트워크 문제로 구매를 완료할 수 없지만 백엔드에서 RTDN을 올바르게 처리하고 사용자 개입 없이 최종적으로 권한을 부여하는 시나리오를 재현할 수 있습니다.

앱이 시뮬레이터와 통신하려면 메타데이터를 사용하여 "결제 재정의" 테스트를 활성화해야 합니다. 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>

라벨 청구 재정의 테스트 활성화 청구 라이브러리의 모의 응답 테스트를 활성화합니다. NONPRODUCTION 태그는 이 빌드를 오버라이드가 활성화된 상태로 프로덕션 환경에 배포해서는 안 된다는 것을 알려줍니다. 최종 버전을 사용자에게 배포할 때는 다음 사항을 반드시 확인하십시오. 이 메타데이터를 제거하거나 별도의 매니페스트를 사용하십시오..

설정이 완료되면 Play Billing Lab 앱에서 라이선스 테스터 계정으로 로그인하고 "Play Billing 라이브러리 응답 시뮬레이션" 옵션을 활성화한 다음 각 API에 대해 반환할 오류 코드를 선택하세요(예: 특정 오류 코드). consumeAsync그런 다음 앱을 열고 테스트하려는 흐름을 실행하기만 하면 됩니다. 시뮬레이터는 구성된 응답을 반환하며, 재시도 로직, 오류 처리 및 RTDN이 예상대로 작동하는지 확인할 수 있습니다.

Play Billing Library 7로 마이그레이션 시 주요 API 변경 사항

RTDN 및 테스트 외에도 PBL 7로 마이그레이션하려면 몇 가지 특정 API 포인트를 처리해야 합니다. PBL 5 또는 6에서 마이그레이션하는 경우 프로젝트가 원활하게 컴파일되고 비즈니스 로직이 일관성을 유지하도록 가장 관련성이 높은 변경 사항을 검토하는 것이 좋습니다.

첫째, 관련된 API는 다음과 같습니다. 비례 모드 구독 변경 옵션이 제거되었습니다. 이제 다음 옵션이 사용됩니다. 교체 모드 요금제 변경(업그레이드, 다운그레이드 등)을 관리하기 위해서입니다. 만약 여전히 다음과 같은 방법을 사용하고 있다면... setReplaceProrationMode o setReplaceSkusProrationMode새로운 버전으로 마이그레이션해야 합니다. setSubscriptionReplacementMode 업데이트된 문서에 따라 로직을 조정하십시오.

API도 제거되었습니다. launchPriceConfirmationFlow이미 사용 중단된 것으로 표시된 기능입니다. 구독료 변경을 처리하려면 가격 변경 가이드에 있는 새로운 워크플로 및 권장 사항을 참조하십시오. 이 가이드에는 사용자에게 변경 사항을 알리고 동의를 관리하는 방법이 자세히 설명되어 있습니다.

또 다른 중요한 점은 대체 결제 API방법들 BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails 보다 일관된 명칭 체계로 대체되면서 사라졌습니다. 이제 다음 용어를 사용해야 합니다. BillingClient.Builder.enableUserChoiceBilling() 옆에 UserChoiceBillingListener y UserChoiceDetails구글 자체에 따르면, 이는 기본적으로 이름만 바뀔 뿐 행동에는 아무런 변화가 없으며, 다음과 같은 합의 사항들이 적용되는 맥락에서 이루어지는 것입니다. 구글과 에픽게임즈는 안드로이드 오픈 소스화에 합의했습니다..

마지막으로 새로운 오류 코드가 입력됩니다. 네트워크 오류 en BillingResult그리고 의미와 조건 SERVICE_TIMEOUT 및 SERVICE_UNAVAILABLE사용자 지정 오류 처리 로직(예: 사용자에게 메시지를 표시할 시점, 조용히 재시도할 시점 등)이 있는 경우, 이러한 새로운 사항들을 고려하여 로직을 검토하는 것이 좋습니다.

구매 완료 전까지는 거래가 보류 중이며 주문 ID가 표시되지 않습니다.

PBL 7의 미묘한 변화 중 하나는 라이브러리가 더 이상 생성하지 않는다는 것입니다. 보류 중인 구매에 대한 주문 ID. 이러한 경우에는 orderId 구매 상태가 '구매 완료'로 변경된 후에만 해당 기능을 사용할 수 있습니다. 이는 특히 처음부터 주문 ID를 주요 참조로 사용한 워크플로에 영향을 미칩니다.

구글의 권장 사항은 다음과 같습니다. 기록 및 정산을 위한 구매 토큰적어도 거래가 처리 중인 동안에는 그렇습니다. Play 스토어에서 구매 내역이 사라진 경우, 다음 사항을 확인하세요. 구매 내역이 사라진 경우 어떻게 해야 하나요?.

미결제 잔액 관련 작업을 아직 해보지 않으셨다면, 청구 라이브러리 통합 가이드 및 관련 문서를 검토해 보세요. 조달 라이프사이클 관리거기에서 다양한 상태, 각 상태에 대한 대응 방법, 그리고 RTDN이 이 퍼즐에 어떻게 들어맞는지 알 수 있습니다.

PBL 7의 새로운 선택적 기능: 가상 할부 및 선불

PBL 7의 "좋은" 새로운 기능 중에는 다음과 같은 것들이 있습니다. 가상 유료 구독 (가상 할부 구독) 및 선불 구독에 대한 보류 중인 구매 지원 기능이 추가되었습니다. 이러한 기능은 필수 사항은 아니지만, 다양한 시장에 맞춰 비즈니스 모델을 조정할 때 더 큰 유연성을 제공할 수 있습니다.

가상 분할 납부를 통해 사용자는 장기 구독료를 분할 납부할 수 있습니다. 소액 정기 결제구글은 일시불로 큰 금액을 결제하는 대신, 개발자 결제 목적으로 연간 플랜에 따라 월별 분할 납부 방식으로 계속해서 요금을 청구한다고 설명합니다. 사용자가 결제를 놓치더라도 개발자나 구글 모두 미납된 금액을 회수하려고 시도해서는 안 됩니다. 따라서 적어도 초기에는 일반적인 월간 구독 서비스와 매우 유사하게 사용할 수 있습니다.

현재로서는 이러한 구독료는 다음에서만 이용 가능합니다. 브라질, 프랑스, 이탈리아, 스페인Google은 Play Console에서 새롭게 지원되는 국가를 확인할 것을 권장합니다. 설정은 Play Console을 통해 진행됩니다. ProductDetails.InstallmentPlanDetails 그리고 특정 가이드에 따라 해당 기능을 앱에 통합하세요.

이와 동시에 지원 범위도 확대되고 있습니다. 선불 구독에 대한 보류 중인 구매이제 사용자가 앱에서 구매를 시작하고 나중에 다른 방식으로 결제를 완료하는 모델을 제공할 수 있으며, 결제 라이브러리는 이러한 흐름을 올바르게 처리하는 방법을 알고 있습니다. 활성화는 해당 함수를 호출하여 수행됩니다. enablePendingPurchases() BillingClient를 초기화할 때, 특히 선불 요금제의 경우, 다음을 사용합니다. PendingPurchasesParams.Builder.enablePrepaidPlans().

Play Billing Library 5 및 6의 감가상각 기간

PBL 7이 등장하면서 구글은 명확한 일정을 발표했습니다. 버전 5 및 6에 대한 지원이 종료되었습니다.만약 당신이 아직 그 중 어느 한 곳에 있다면, 달력에 빨간색으로 표시해야 합니다.

Google Play 결제 라이브러리 5는 2024년 8월 31일부로 신규 앱 및 업데이트에 대한 지원이 공식적으로 종료됩니다. 2024년 11월 1일까지 연장을 요청할 수는 있지만, 장기적으로는 이를 기대하기 어렵습니다.
Google Play 결제 라이브러리 6은 2025년 8월 1일까지 새로운 앱을 게시하고 2025년 11월 1일까지 기존 앱을 업데이트하는 데 사용할 수 있습니다.

해당 날짜 이후에 버전 6 이상, 또는 이상적으로는 버전 7로 마이그레이션하지 않은 경우 최신 버전으로 업데이트해야 합니다. 버전 7Play Console에서 업데이트가 차단됩니다. 앱은 사용자 기기에서 계속 작동하지만, 스토어에 게시해야 하는 버그 수정이나 새로운 기능 추가 등의 작업은 중단됩니다.

.NET MAUI 사례 및 현재의 한계점

.NET MAUI와 안드로이드 구독 기능을 사용해 본 경험이 있다면, 생각보다 간단하지 않다는 것을 이미 알고 있거나 읽어보셨을 겁니다. 많은 프로젝트에서 이러한 점을 고려했습니다. 플러그인.인앱 결제 James Montemagno가 개발했지만, 해당 플러그인은 보관 처리되어 더 이상 유지 관리되지 않으므로 Billing Library 7을 지원하도록 업데이트되지 않을 것입니다. 동시에 공식 패키지도 마찬가지입니다. Xamarin.Android.Google.BillingClient Xamarin.Android 생태계에 기반을 두고 있으며 .NET MAUI와는 직접적인 호환이 되지 않습니다.

실질적인 결과는 다음과 같습니다. 플레이 콘솔 경고 귀하의 앱은 Billing Library 7.0.0 이상 버전을 사용하지 않으므로, 이전 버전의 라이브러리를 계속 사용하면 업데이트가 차단됩니다. 일부 개발자는 업데이트 버전을 업로드하기 위해 구독 기능을 일시적으로 비활성화하는 등의 극단적인 해결책을 선택했지만, 수익 모델이 구독료에 의존하는 경우 이러한 방법은 지속 가능하지 않습니다.

이러한 상황에서 많은 팀들이 다음과 같은 대안들을 고려하고 있습니다. 타사 SDK 이러한 서비스는 이미 PBL 7을 기반으로 지원하며, 더욱 안정적인 크로스 플랫폼 API를 제공합니다(예: Android, iOS 및 기타 플랫폼용 SDK를 제공하는 구독 백엔드 솔루션). 이러한 서비스는 일반적으로 청구 라이브러리 버전 마이그레이션을 처리하고 안정적인 래퍼를 제공하여 Google의 새로운 기능 지원 중단으로 인한 부담을 크게 줄여줍니다.

마이크로소프트와 MAUI 팀이 제안을 내놓을 때까지 공식 패키지가 업데이트되었으며 완벽하게 호환됩니다. Billing Library 7을 사용하면 다음과 같은 옵션이 있습니다. 네이티브 Billing Library에 대한 자체 바인딩을 구현하거나, 타사 서비스를 사용하거나, MAUI 프로젝트 내에서 구매 기능을 통합하는 방식을 재고하는 것입니다. 어떤 방법을 선택하든 Play 스토어의 마감일이 정해져 있으므로 마지막 순간까지 결정을 미루지 않는 것이 좋습니다.