환불 방어를 위해 Google Play 실시간 알림과 연동되는 도구는 무엇인가요?

짧게 답하자면, 생각보다 적으며 대부분은 그저 알림을 수신하기만 합니다.

Google Play RTDN은 하나의 통로입니다. 갱신, 취소, 무효화된 구매를 전달하며, 2026년 중반부터는 차지백이 검토 중이며 24시간 안에 의견을 제시할 수 있다는 메시지도 전달합니다. 이 마지막 메시지야말로 실제로 Google Play 환불 방어가 이루어지는 유일한 지점입니다. 피드에 있는 나머지는 모두 Google이 이미 결정한 사항을 알려주는 것일 뿐입니다.

그래서 누군가 환불 방어를 위해 Google Play 실시간 개발자 알림과 연동되는 도구가 무엇이냐고 물을 때, 사실 두 가지를 묻는 셈입니다. 어떤 도구가 피드를 수신할 수 있는지, 그리고 어떤 도구가 그에 응답할 수 있는지 말이죠. Apple 쪽 문제는 저희의 CONSUMPTION_REQUEST 설명 글에서 iOS에서 동일한 문제를 다룹니다.

핵심 요약

• Google Play RTDN은 Pub/Sub 토픽입니다. Google이 게시하면 개발자가 구독합니다.

• 반박이 가능한 RTDN 유형은 PendingRefundReviewNotification 단 하나뿐입니다. 차지백 발생 시 전송되며 24시간의 시간을 줍니다.

• 2026년 8월 3일부터는 차지백 비용을 개발자가 직접 부담합니다. 구매 금액에서 Google 수수료를 뺀 금액에 $15~$25의 은행 수수료가 추가됩니다.

• 대부분의 구독 플랫폼은 Google Play 환불 알림을 수신합니다. 하지만 무언가를 응답으로 보내는 곳은 극소수입니다.

• RevenueCat은 차지백 검토에 응답하지만, 자체 문서에 따르면 소비 데이터는 전송하지 않습니다. 단지 선호도와 플래그 하나만 보냅니다.

• 24시간을 놓치면 Google은 개발자로부터 아무것도 받지 못한 채 분쟁을 진행합니다.

Google Play RTDN이 실제로 전송하는 것

실시간 개발자 알림은 개발자가 소유한 Google Cloud Pub/Sub 토픽으로 도착합니다. 각 메시지는 다섯 가지 페이로드 중 하나를 담은 base64 블롭입니다. 구독 이벤트, 일회성 상품 이벤트, 테스트 핑, 그리고 여기서 중요한 두 가지가 있습니다.

VoidedPurchaseNotification은 전형적인 Google Play 환불 알림입니다. 구매가 환불되거나 차지백되거나 그 외 방식으로 무효화되었음을 나타냅니다. purchaseToken, orderId, productType, refundType이라는 네 가지 필드를 포함합니다. 접근 권한을 회수하는 데는 유용하지만, 이미 돈이 빠져나간 뒤이기 때문에 이의를 제기하는 데는 쓸모가 없습니다.

PendingRefundReviewNotification은 새로 추가된 유형입니다. Google의 RTDN 레퍼런스에 따르면 "사용자가 구매에 대한 차지백을 요청했고, 해당 요청이 개발자 검토를 필요로 할 때" 전송됩니다. pendingRefundToken, orderId, 그리고 현재는 항상 7(즉 CHARGEBACK을 의미)인 refundReason을 받게 됩니다. 그러면 24시간짜리 시계가 시작됩니다.

그러니 Google Play RTDN 환불 알림은 두 가지 유형으로 나뉘는 셈입니다. 하나는 영수증이고, 다른 하나는 질문입니다.

24시간이라는 기간이 갑자기 중요해진 이유

수년간 Android에서 발생하는 차지백은 Google의 문제였습니다. 사용자가 은행에 결제를 이의 제기하면 Google이 그 비용을 부담했고, 개발자는 무효화된 구매 알림을 받고 넘어가면 그만이었습니다.

2026년 8월 3일 이후에 이루어진 주문부터는 이 관행이 끝났습니다. 이제 개발자는 구매 금액에서 Play 서비스 수수료를 뺀 금액과 은행이 부과하는 차지백 수수료를 부담해야 합니다. Google은 자체 서비스 수수료만 부담할 뿐 그 외에는 책임지지 않습니다.

카드 네트워크 수수료는 건당 $15~$25 수준이며, 때로는 그 이상입니다. 즉 $4.99짜리 코인 팩이 차지백되면 약 $3.50의 매출 손실에 $20의 수수료가 더해집니다. 4달러짜리 판매에서 23달러가 사라지는 셈입니다.

그 대신 Google은 ReviewRefund API를 공개했습니다. PendingRefundReviewNotification이 도착하면 토큰, refundPreference(DECLINE, APPROVE, NEUTRAL 중 하나), 샘플 제공 여부, 밀리유닛 단위의 소비 비율, 그리고 최대 1,000개의 사용 이벤트를 담아 orders.reviewrefund에 POST 요청을 보냅니다. Google이 이를 대신 은행에 제출합니다.

기한을 놓치면 Google은 빈손으로 들어가게 됩니다. 업계 수치에 따르면 증거 없이 진행되는 차지백 승률은 약 20~30%입니다. 증거가 있으면 일부 벤더는 80%까지도 주장합니다. 두 수치 모두 어느 정도 감안해서 봐야 하지만, 방향성만큼은 명확합니다.

실제로 무엇을 하는지에 따라 정리한 도구들

많은 제품이 "Google Play RTDN을 지원한다"고 말합니다. 하지만 거의 대부분은 토픽을 구독한다는 의미일 뿐, 실제로 응답한다는 의미인 경우는 매우 드뭅니다.

Refund Sensor. 바로 이 작업을 위해 만들어졌습니다. Cloud 프로젝트에 Pub/Sub 토픽을 프로비저닝하고 Play Console에 등록한 뒤, PendingRefundReviewNotification이 도착하면 Review Refund API를 통해 배송 및 소비 증거와 함께 DECLINE 권고를 제출합니다. 설정은 Google 로그인과 두 가지 Play Console 권한만 있으면 되며 SDK는 필요 없습니다. 이 글을 쓰는 시점 기준으로, 단순한 선호도가 아니라 실제 증거를 제출하는 몇 안 되는 도구 중 하나입니다. 자세한 내용은 Google Play 방어 페이지에서 확인할 수 있습니다.

RevenueCat. RTDN을 수신하고, Voided Purchases API를 폴링하며, 환불 시 권한을 회수합니다. 2026년 7월에 Refund Control에 Google을 추가하여 이제 차지백 검토에 응답합니다. 하지만 자체 문서를 읽어보면, Google 쪽에서는 토큰, true로 설정된 sampleContentProvided, 그리고 선호도만 전송합니다. 문서에는 이렇게 적혀 있습니다. "RevenueCat은 현재 소비 비율이나 사용 이벤트를 수집하거나 전송하지 않습니다." 투표는 하지만 논거는 없는 셈입니다. 이미 사용 중이라면 괜찮지만, 완전한 방어책은 아닙니다.

Adapty. 탄탄한 RTDN 수신기입니다. 문서에서는 토픽 이름을 Play Console에 붙여넣고 테스트 버튼을 누르는 과정을 안내합니다. 환불은 이벤트 피드에 표시되고 webhook을 발생시킵니다. 하지만 제가 찾아본 바로는 ReviewRefund 연동은 없습니다. 수신만 할 뿐입니다.

Qonversion, Glassfy, 그리고 나머지. 마찬가지입니다. 이들은 구독 상태를 최신으로 유지하기 위해 Google Play 실시간 개발자 알림을 소비합니다. 공개된 문서에 따르면 그중 어느 것도 차지백 검토에는 관여하지 않습니다.

직접 만드는 백엔드. 언제나 선택 가능한 방법입니다. Pub/Sub 구독, 디코더, 주문 조회, 사용량 쿼리, 인증된 POST 요청 하나면 됩니다. 어려운 부분은 코드가 아닙니다. 알림이 일요일 새벽 2시에 도착해도 시계는 개의치 않는다는 점입니다.

Google Play 차지백 관리 소프트웨어를 알아보고 있다면, 모든 벤더에게 한 가지만 물어보세요. 검토 알림이 들어왔을 때 정확히 무엇을 회신하느냐고요. "선호도"는 시작에 불과합니다. 소비 데이터야말로 진짜 방어책입니다.

환불 방어를 위해 직접 Google Play RTDN을 연동하는 방법

구매보다 직접 구축하는 쪽을 선택한다면, 다음 순서를 따르면 됩니다.

Google Cloud 프로젝트에서 Cloud Pub/Sub API를 활성화합니다. 토픽을 생성합니다. 해당 토픽에 [email protected]에게 Pub/Sub Publisher 역할을 부여합니다. 이 역할을 빠뜨리면 아무것도 도착하지 않습니다. RevenueCat 포럼에서 가장 흔한 불만 사항입니다.

Play Console에서 수익 창출(Monetize)로 이동한 뒤 수익 창출 설정(Monetization setup)을 선택합니다. "실시간 알림 사용(Enable real-time notifications)"을 체크하고 전체 토픽 이름(projects/your-project/topics/your-topic)을 붙여넣은 다음 테스트 알림 전송(Send test notification)을 누릅니다. 알림이 도착하면 파이프가 정상적으로 작동하는 것입니다.

push 또는 pull 방식으로 Pub/Sub 구독을 생성합니다. data 필드를 디코딩합니다. 페이로드에 따라 분기 처리합니다.

PendingRefundReviewNotification의 경우: 주문을 조회하고, 실제 사용량을 가져오고, 선호도를 결정한 뒤 pendingRefundToken과 함께 reviewrefund에 POST 요청을 보냅니다. 24시간 안에 해야 하며, 그렇지 않으면 의미가 없습니다. VoidedPurchaseNotification의 경우: 접근 권한을 회수합니다. 저희가 쓴 환불 후 접근 권한 관련 글에서 Google에서 특히 이 단계를 잘못 처리하기 쉬운 이유를 다룹니다.

모든 것을 로그로 남기세요. 응답률과 승률은 서로 별개의 수치입니다.

Google이 제공하지 않는 한 가지가 있습니다. 바로 테스트용 PendingRefundReviewNotification입니다. 연동을 구성한 뒤 실제 차지백이 발생하기를 기다려야 합니다. 호스팅 도구들이 녹색 체크 표시 대신 "첫 환불 이벤트 대기 중"이라고 표시하는 이유가 바로 여기에 있습니다.

순위를 매겨야 한다면, Google Play RTDN 연동에 가장 적합한 도구

구체적으로 Google Play 환불 방어, 즉 증거를 갖고 차지백 검토에 응답하는 것을 기준으로 보면 목록은 짧습니다. Refund Sensor는 코드 작성 없이 소비 데이터로 이를 해냅니다. RevenueCat은 선호도만으로 처리하는데, 아무것도 안 하는 것보다는 낫지만 큰 차이는 없습니다. 나머지는 모두 피드를 지켜보기만 할 뿐입니다.

일반적인 RTDN 인프라 구축과 권한 동기화 측면에서는 RevenueCat과 Adapty 모두 성숙하고 문서화가 잘되어 있습니다.

이런 문제 자체를 아예 다루고 싶지 않다면, 웹 스토어에서 Tebex나 Xsolla 같은 merchant of record를 이용하면 책임을 장부에서 덜어낼 수 있습니다. 다만 이는 구매 자체를 Play 밖으로 옮기는 것이며, Play에 남아 있는 구매에 대해서는 아무런 도움이 되지 않습니다.

본인이 겪고 있는 문제가 무엇인지에 따라 선택하세요.

결론

Google Play RTDN은 원래 개발자에게 정보를 알려주기 위해 만들어졌습니다. 개발자에게 질문을 던지기 시작한 것은 최근의 일입니다. PendingRefundReviewNotification은 Google이 Android에서 처음으로 환불 사연에 대한 개발자 측 입장을 요구한 사례이며, 이는 Google이 패소한 건에 대해 비용을 부담시키기 시작한 것과 같은 시기에 등장했습니다.

이는 셈법을 바꿔놓습니다. 환불로 인한 손실이 단순히 판매 하나였을 때는 Google Play 환불 알림을 수신만 하는 도구로도 충분했습니다. 하지만 이제는 판매액에 은행 수수료까지 더해지며, 그 청구서와 개발자 사이를 가로막는 유일한 것은 24시간 이내의 POST 요청뿐입니다.

토픽을 설정하세요. 사용 중인 플랫폼이 실제로 무엇을 회신하는지 확인하세요. 답이 아무것도 없거나 단순한 선호도뿐이라면, 다음 차지백이 그 빈틈을 발견하기 전에 메워두세요.