외부 적으로 활성화 된 기능에 대한 요금 청구

Question

특정 수직 시장을 대상으로하는 앱 범위 지정의 초기 단계입니다. 그것은 소비자 지향적이지 않습니다. 앱을 개발하는 조직은 기존의 웹 기반 제품과 사용자 계정을 등록하고 해당 제품에 대한 청구서 작성 인프라를 구축했으며 앱은 이러한 제품과 상호 작용해야합니다. 이를 위해 다음과 같은 몇 가지 질문이 있습니다.

1) 앱 외부에서 (예 : 별도의 웹 사이트를 통해) 사용할 수있는 기능이 있고 개발자가 사용자에게 청구 한 경우 이 :

Q1. 이 앱을 Google Play를 통해 배포 할 수 있나요?

2. 앱 외부에서 기능을 사용하도록 설정했기 때문에 개발자는 Google Play의 결제 시스템을 사용하여 결제해야합니까?

2) 사용자가 별도의 웹 사이트에 콘텐츠 항목을 만들어서 해당 사이트에서 콘텐츠를 수정할 수 있도록 허용하는 앱 (예 : 청구하는 버그 추적 앱 사이트에 버그 기록 생성) :

Q3이 항목은 인앱 구매로 간주되며 Google Play의 결제 시스템을 사용해야 청구됩니까?

이 시나리오에서 Google의 명확한 진술은 어디에서 찾을 수 있습니까? 저는 구매 및 청구 시나리오가 매우 간단한 소비자 애플리케이션과 관련된 자료 만 찾습니다.

Answer 1

"내 옆에 다른 지불 방법이 없으니"잠재력에 대해 많은 부분을 설명 할 수는 없지만 기술 측면에서 볼 때 다음과 같은 측면이 내 마음에 들었습니다.

• 1 : 기술적으로이 앱은 GP에서 무료로 제공되며 다른 결제 수단을 사용할 수도 있고 라이센스 유효성 검사 서비스를 사용할 수도 있습니다.
• 질문 2 : Google Play 라이선스를 배포하는 유일한 방법은 보안 서버에서 모든 무결성 검사를 수행하는 것입니다. 응용 프로그램은 GP LVL 정보를 요청하여 서버에 전달할 수 있습니다. GP LVL 사용자 ID (난독 화 된 이진 앱 별 바이트 문자열)를 사용하여 사용자를 식별하고 구현하려는 비밀번호 세부 정보를 앱과 협상 할 수 있습니다. 물론이 시나리오에서는 사용자가 이미 지불 한 것처럼 느끼기를 기대하므로 서버 측의 등록을 원활하게 통합해야합니다. 서버 측에서 "활성화"/ "인증"단계가 추가적으로 필요한 경우 GP LVL을 사용할 것인지 잘 모르겠습니다.
• Q3 : GPIAB V3 소모품 인앱 구매를 사용하여이 (또는 V2 구독은 가능하지만 항목 당 지불과 비슷하게 들립니다.) 다시 말하지만, 서버 구매 의도에 대한 구매 당 developerPayload를 생성하고 앱이 사용자의 구매를 볼 때 유효성을 확인하는 경우에만 안전합니다. 유효성 검사는 서버에서 다시 수행해야합니다. 그렇지 않으면 앱에 공개 키를 포함시켜야합니다. 이는 앱에 금이가는 주요 단계입니다.
• 일반적으로 사용하려는 사용자 관리가있는 경우 GP 정보가 상대적으로 익명임을 알고 있어야합니다 (LVL : 난독 화 된 IAB V3 : 앱 방향 정보 없음). 모든). 그래서 "당신의"계정과 GP 경험 사이의 믿을 수 있고, 유스 케이스 지향적 인 바인딩이 여기에서 중요 할 것입니다.