제가 처음으로 놓친 차지백은 토요일 밤 11시 40분에 발생했습니다. 월요일에 Pub/Sub 로그를 파헤치다가 아무도 구독하지 않는 토픽에 그대로 남아 있는 것을 발견하고서야 그 사실을 알게 되었습니다.
그것은 2026년 8월 3일 이전의 일이었습니다. 당시에는 한 건을 놓쳐도 해당 판매 금액 외에는 거의 손해가 없었습니다.
현재 Google Play는 해당 날짜 이후에 발생한 주문에 대한 차지백 비용을 개발자에게 전가합니다. 개발자는 Google의 서비스 수수료를 제외한 주문 금액을 떠안게 되며, 여기에 건당 $15~$25의 카드 네트워크 수수료가 추가됩니다. 대신 Google은 Review Refund API와 증거를 제출할 수 있는 약 24시간의 시간을 제공했습니다.
따라서 문제는 차지백을 처리하느냐 마느냐가 아닙니다. 자정에 누가(또는 무엇이) 그것을 처리하느냐가 핵심입니다. 설정 방법은 Google Play 차지백 방어 페이지에 있습니다. 이 글은 그 긴 버전으로, 네 가지 옵션을 다루며 그중 두 가지는 대부분의 팀에게 권하지 않습니다.
핵심 요약
Google Play 차지백 처리에는 입력 지점이 하나뿐입니다. 바로 Pending Refund Review Notification 수신 후 24시간 이내에 호출해야 하는 ReviewRefund API입니다.
Google은 첫 번째 호출만 기록하고 이후 호출은 모두 무시하지만, 여전히 OK를 반환합니다. 기회는 단 한 번뿐이며 수정은 불가능합니다.
이의 제기가 가능한 것은 차지백뿐입니다. 지원 환불, 48시간 Play 환불, 미승인 무료체험은 개발자의 개입 없이 결정됩니다.
실질적인 대안은 네 가지입니다. 직접 구축하기, 사용 중인 구독 플랫폼 활용하기, 소프트웨어 구매하기, 또는 손실을 그대로 감수하기입니다.
2026년 8월 3일부터 계산 방식이 바뀌었습니다. $99 연간 요금제에서 한 번만 대응 기한을 놓쳐도 주문 금액에 네트워크 수수료까지 추가로 들게 됩니다.
수동 처리는 실제로 어떤 모습일까요
공정하게 말하면 "수동"이라는 말에는 여러 수준이 있습니다. 한쪽 끝에는 공용 수신함과 생각날 때마다 Play Console을 확인하는 담당자가 있고, 다른 쪽 끝에는 순번표, Slack 채널, 분쟁 주문을 정리한 스프레드시트가 있습니다.
두 번째 방식이 더 낫습니다. 하지만 그래도 실패합니다. 노력과는 무관한 이유 때문입니다.
첫째, 시간을 눈으로 확인할 방법이 없습니다. 24시간은 PendingRefundReviewNotification이 Pub/Sub 토픽에 도착하는 순간부터 시작됩니다. 실시간 개발자 알림(real-time developer notifications)을 한 번도 활성화하지 않았다면, 리뷰가 열렸다는 사실을 알려주는 것은 아무것도 없으며 Play Console에도 별도의 표시가 뜨지 않습니다.
둘째, 사람들을 놀라게 하는 부분인데, Google은 첫 번째 ReviewRefund 호출만 기록하고 그 이후의 모든 호출은 무시하면서도 여전히 OK를 반환합니다. 겉으로는 성공한 것처럼 보입니다. 누군가 오전 9시에 수동으로 뽑아낸 데이터를 바탕으로 스크립트에 응답을 입력하다 보면, 되돌릴 수 없는 필드 오류가 생기는 것은 바로 이런 식입니다.
더 열심히 한다고 해서 이 두 가지 문제가 해결되지는 않습니다.
Google Play 차지백 처리 과정
대응 기한이 사람들이 생각하는 것보다 짧기 때문에 전체 과정을 정리해 둘 가치가 있습니다.
고객이 자신의 은행에 결제 금액에 대해 이의를 제기합니다. 개발자나 Google에 제기하는 것이 아닙니다.
Google은 해당 주문을 검토 대상으로 표시하고 RTDN을 통해 PendingRefundReviewNotification을 전송합니다. 여기에는 pendingRefundToken, orderId, 값이 7인 refundReason(즉 CHARGEBACK), 그리고 구매 시점에 설정해 두었다면 obfuscatedAccountId가 포함됩니다.
개발자에게는 preference와 수집 가능한 증거를 담아 ReviewRefund를 호출할 수 있는 약 24시간이 주어집니다.
Google은 이를 활용해 은행 측에 사건을 주장합니다.
패소하면, 2026년 8월 3일 이후에 발생한 주문의 경우 그 비용은 개발자가 부담하게 됩니다.
한 가지 짚어볼 만한 비대칭이 있습니다. Apple은 CONSUMPTION_REQUEST를 통해 일반 환불에 대해서도 의견을 묻습니다. 반면 Google Play는 차지백에 대해서만 리뷰를 엽니다. 그 외의 모든 사항은 개발자 없이 처리되며, 이를 알게 되는 것은 voided purchase를 통해서뿐입니다. 전체적인 작동 방식은 Google Play 차지백 설명에서 다룹니다.
옵션 1: 직접 핸들러 구축하기
Pub/Sub 토픽을 만들고, Monetize 메뉴의 Monetization setup에서 RTDN을 활성화합니다. 메시지를 신뢰하기 전에 검증하는 푸시 엔드포인트를 만듭니다. 그다음 base64로 인코딩된 data 필드를 디코딩하고, 다섯 가지 알림 객체 중 어떤 것이 도착했는지에 따라 분기 처리한 뒤, 주문을 사용자와 매칭하고, 증거를 수집하여 범위가 제한된 OAuth 토큰으로 ReviewRefund를 호출합니다.
구축 자체는 비용이 많이 드는 부분이 아닙니다. 웹훅 관련 작업을 해본 적이 있다면 2주 정도면 됩니다.
비용이 많이 드는 부분은 2년 차입니다. Google이 필드를 변경합니다. OAuth refresh 토큰이 일요일에 조용히 만료됩니다. 공교롭게도 핸들러가 멈춘 바로 그날 밤에 $200짜리 분쟁이 들어옵니다. 늘 그런 식으로 일어납니다. 가시성(observability), 재처리(replay) 기능, 그리고 아직 본 적 없는 형태의 알림에 대한 테스트가 필요해질 것입니다.
백엔드를 직접 운영하고 환불이 실제로 매출에 영향을 주는 수준이라면 직접 구축하세요. 오히려 그렇게 하기를 권합니다. 하지만 혼자서 제품을 만들어 출시하는 입장이라면, 한 달이라는 시간을 그렇게 쓰는 것은 좋은 선택이 아닙니다.
옵션 2: 이미 사용 중인 구독 플랫폼 활용하기
코드를 작성하기 전에 먼저 이것부터 확인하세요. RevenueCat은 Refund Control 기능 아래에 Google의 Review Refund API를 추가했고, Adapty는 Apple 쪽에 Refund Saver 기능을 제공합니다.
장점은 영수증, 권한(entitlements), 고객 매핑 데이터가 이미 그곳에 존재한다는 점입니다. 덕분에 증거를 모으기가 더 쉽고 계정 매칭 문제도 이미 해결되어 있습니다.
한계는 환불 대응이 이들 플랫폼의 핵심 제품이 아니라 하나의 부가 기능이라는 점입니다. IP 주소가 포함된 1,000개의 사용 이벤트가 아니라 preference와 몇 가지 플래그 정도만 기대할 수 있습니다. 많은 앱에는 이 정도로 충분하지만, 사기성 분쟁이 많은 경우라면 부족합니다.
옵션 3: 전용 Google Play 차지백 관리 소프트웨어
이 카테고리는 8월 3일 이전에는 거의 존재하지 않았습니다. 이는 이러한 유인이 얼마나 최근에 생겨났는지를 보여줍니다.
형태는 대체로 비슷합니다. 서비스가 사용자의 RTDN을 구독하고, 기한 내에 전달 및 사용 증거를 담은 거부 권고(decline recommendation)를 제출하며, 사건별로 결과를 추적합니다.
Refund Sensor는 하나의 계정으로 Google Play와 App Store 양쪽에서 이러한 작업을 수행합니다. Google로 로그인하고 두 가지 Play Console 권한(재무 데이터 조회, 주문 및 구독 관리)을 부여하면 Pub/Sub 토픽을 직접 프로비저닝합니다. SDK도 필요 없고, 코드를 변경할 필요도 없으며, 다시 제출할 것도 없습니다.
대신 감수해야 할 점은 또 하나의 벤더, 또 하나의 월간 비용입니다. 그 대가로 얻는 것은 밤새 깨어 있어야 하는 사람이 되지 않아도 된다는 점입니다.
옵션 4: 손실을 그대로 감수하기
일부 앱에는 이것이 합리적인 선택이며, 그렇지 않은 척하지는 않겠습니다. $1.99짜리 소모성 상품을 판매하고 연간 차지백이 4건 정도라면, 2주간의 엔지니어링 작업은 결코 그 비용을 회수하지 못합니다.
다만 먼저 숫자를 계산해 보세요. $99 연간 요금제에서 차지백 한 건을 패소하면 Google 서비스 수수료를 제외한 주문 금액에 $15~$25의 네트워크 수수료가 추가로 들어갑니다. 한 분기에 그런 일이 두 번만 일어나도 결론은 달라집니다.
Google Play 차지백 처리를 자동화하는 방법
옵션 1을 선택했다면, 다음은 구축 순서입니다. 순서는 사람들이 예상하는 것보다 더 중요합니다.
Play Console에서 RTDN을 활성화하고 Pub/Sub 토픽을 생성합니다. 파이프라인을 신뢰하기 전에 Send Test Message를 눌러 확인합니다.
data 필드를 디코딩하고 어떤 알림 객체가 도착했는지에 따라 분기 처리합니다. 메시지당 하나만 도착합니다. pendingRefundReviewNotification이 도착하면 pendingRefundToken을 저장하고 타이머를 시작합니다. 이메일이 아니라 타이머입니다.
orderId를 사용자와 매칭합니다. obfuscatedAccountId를 사용하는 것이 가장 빠른 방법이며, 이것만으로도 구매 시점에 이를 설정해 두어야 할 충분한 이유가 됩니다.
증거를 수집합니다: sampleContentProvided, consumptionPercentageMilliunits(45200은 45.2%를 의미합니다), 그리고 타임스탬프와 IP 주소가 포함된 최대 1,000개의 consumptionUsageEvents입니다.
orders.reviewrefund를 단 한 번 호출하며, refundPreference는 APPROVE, DECLINE, NEUTRAL 중 하나로 지정합니다. 호출, 페이로드, 응답을 모두 기록합니다.
별도로, 접근 권한 제거를 위해 voidedPurchaseNotification을 처리하고, 매일 밤 Voided Purchases API를 실행해 데이터를 대조합니다. 이 API는 하루 6,000회 호출로 제한되어 있습니다.
마지막 단계는 모두가 건너뛰는 부분입니다. 저도 몇 달 동안 건너뛰었습니다. 장애 발생 중에는 알림을 놓치기 쉬우며, 다운타임 동안 어떤 일이 있었는지 확인하려면 pull API를 사용해야 합니다. Voided Purchases API와 실시간 개발자 알림 비교에서 각 피드가 어떤 역할을 하는지 다룹니다.
Google Play 차지백 예방
위의 어떤 방법보다도 비용이 적게 들며, 예상하지 못한 분쟁에도 효과가 있습니다.
고객지원 창구에 먼저 연락한 고객은 은행에 연락하지 않습니다. 앱 내에 눈에 잘 보이는 연락 경로를 두고 하루 안에 답변을 주는 것만으로도 놀랄 만큼 많은 분쟁을 시작되기 전에 막을 수 있습니다.
그다음 갱신 정보를 명확하게 보여주세요. 가격, 기간, 갱신일을 구매 버튼과 같은 화면에 표시하는 것입니다. 지금까지 본 어떤 요인보다도 '놀람'이 분쟁을 더 많이 유발합니다.
충분히 주목받지 못하는 두 가지가 더 있습니다. 미승인 구매(unacknowledged purchases)를 주시하세요. 눈치채지 못한 사이에 전환된 무료체험은 한 달 뒤 차지백으로 돌아옵니다. 그리고 voidedReason을 사기 신호로 활용하세요. 여기에는 fraud, friendly_fraud, chargeback을 포함한 9가지 값이 있으며, 이런 계정은 반복됩니다. 또 다른 무료체험을 제공하기 전에 먼저 이들을 표시해 두세요.
차지백 비율을 Google의 기준치 이하로 유지하세요. 문제가 지속되면 계정 상태(account standing)에 영향을 미치며, 이는 개별 환불 건보다 훨씬 더 심각한 결과를 가져옵니다.
참고 자료
자주 묻는 질문
환불은 Google을 거쳐 진행되며, Google이나 Play Console에서 개발자가 직접 결정합니다. 차지백은 고객이 자신의 은행에 문제를 제기하는 것으로, 카드 네트워크 규정의 적용을 받게 됩니다. 개발자가 응답할 수 있는 리뷰가 열리는 것은 차지백뿐이며, 비용이 개발자에게 전가되는 것도 차지백뿐입니다.
PendingRefundReviewNotification이 전달된 시점부터 약 24시간입니다. 시간은 알림이 전달된 순간부터 시작되며, 개발자가 이를 확인한 시점부터 시작되는 것이 아닙니다.
Google이 개발자의 증거 없이 차지백에 대응하게 되는데, 이는 가장 불리한 상황입니다. 2026년 8월 3일 이후에 발생한 주문의 경우, 패소하면 서비스 수수료를 제외한 주문 금액과 네트워크 수수료가 비용으로 발생합니다.
아니요. Google은 첫 번째 ReviewRefund 호출만 기록하고 이후의 호출은 모두 무시하지만, 여전히 OK를 반환합니다. 프로덕션 환경에 적용하기 전에 테스트 구매로 먼저 확인해 보세요.
개발자가 깨어 있지 않아도 대신 응답을 제출해 주는 소프트웨어라면 무엇이든 괜찮습니다. 백엔드를 직접 운영하고 있다면 직접 구축하는 것도 합리적인 프로젝트입니다. 그렇지 않다면, 하나의 특수한 사례를 위해 Pub/Sub 컨슈머를 직접 작성하는 것보다는 Play Console 권한을 통해 연결되는 Google Play 환불 관리 소프트웨어를 사용하는 것이 더 낫습니다.
아니요. 이는 Google이 자체적으로 만든 Play Developer API를 통해 전달 및 사용 증거를 바탕으로 권고를 제출하는 것입니다. 이것이 바로 Google이 이를 위해 마련한 채널입니다.
