대부분의 "최고의 환불 도구" 목록은 실제로 연동해본 적 없는 사람들이 작성한 것입니다. 여기에서는 각 플랫폼이 실제로 Google에 전송하는 내용과 은근히 놓치는 부분을 바탕으로, 제가 원했던 버전을 소개합니다.
많은 사람이 헷갈려 하는 부분이니 간단히 짚고 넘어가겠습니다. Google Play 구독 환불(refund subscription) 이벤트와 차지백은 서로 다른 규칙을 따르며, 대부분의 플랫폼은 한쪽은 제대로 처리하고 다른 한쪽은 부분적으로만 처리합니다. 차지백은 이의를 제기할 수 있지만, 그 외의 모든 경우는 감지만 가능합니다.
비교를 건너뛰고 싶다면, Google Play 차지백 방어가 저희 제품 페이지이자 이 글의 요약본입니다.
핵심 요약
Google은 Review Refund API를 통해 약 24시간 이내에만 차지백에 이의를 제기할 수 있도록 허용합니다. 여기 소개된 모든 플랫폼은 이 제약 안에서 작동합니다.
Google은 APPROVE, DECLINE, NEUTRAL 세 가지 선호도만 허용합니다. 어떤 플랫폼에서든 API를 통한 부분 환불은 불가능합니다.
진짜 차별점은 증거(evidence)입니다. 일부 도구는 사용 데이터를 전송하지만, 일부는 선호도와 단일 불리언 값만 전송합니다.
Google은 결과를 알려주지 않습니다. 플랫폼들은 이를 직접 조회(poll)해야 하므로, 승률 보고는 어디서나 지연됩니다.
감지(detection)가 더 큰 공백입니다. 권한 회수 없는 환불, 부분 환불, 미승인(unacknowledged) 구매는 대부분의 스택에서 여전히 보이지 않습니다.
실제로 비교해야 할 것
네 가지입니다. 그 외의 것들은 가격 페이지에 적힌 잡음일 뿐입니다.
소비(consumption) 증거를 전송하는가, 아니면 단순히 선호도만 전송하는가? 이것이 Review Refund API의 핵심입니다. Google은 은행 측에 개발자의 입장을 주장할 수 있도록 배송 상태와 항목 소비 정보를 요청했습니다. APPROVE나 DECLINE만 제출하는 도구는 이 채널의 3분의 1 정도만 활용하는 셈입니다.
SDK가 필요한가? 필요하다면 환불 방어 기능이 구독 인프라와 결합됩니다. 이는 실질적인 결정이며, 항상 나쁜 것만은 아닙니다.
무엇을 감지하는가? 이의 제기는 Google Play 환불 관리의 절반에 불과합니다. 환불이 발생했음을 파악하고 접근 권한을 차단하는 것이 나머지 절반입니다.
Apple도 지원하는가? 대부분의 팀은 두 스토어를 모두 운영합니다. 하나의 업무에 두 개의 벤더를 쓰면 일이 누락되기 마련입니다.
RevenueCat Refund Control
구독이 이미 RevenueCat을 통해 운영되고 있다면 가장 강력한 선택지이며, 실제로 많은 앱이 그렇습니다.
Refund Control은 프로젝트 수준의 정책을 위에서 아래로 평가하는 방식을 사용합니다. 처음으로 일치하는 정책이 적용됩니다. Prefer full refund, Prefer no refund, Send consumption data only, Do not respond 중에서 선택할 수 있으며, Google의 orders.reviewrefund 엔드포인트를 대신 호출해줍니다.
여기서 두 번 읽어볼 가치가 있는 부분이 있습니다. RevenueCat의 공식 문서에 따르면, Google에 전송되는 본문(body)에는 pendingRefundToken, true로 설정된 sampleContentProvided, 그리고 refundPreference라는 세 가지 필드만 포함됩니다. RevenueCat은 아직 소비 비율이나 사용 이벤트를 전송하지 않는다고 명확히 밝히고 있습니다. 즉, 증거 채널이 아니라 선호도 채널만 얻게 되는 것입니다.
감지 한계에 대해서도 솔직하게 밝히고 있습니다. Play Console에서 회수(revoke) 옵션을 체크하지 않고 발행한 환불은 감지되지 않습니다. 부분 환불도 전달되지 않으며, 미승인 구매에서 발생한 환불도 포착되지 않습니다. 개발자가 아니라 Google이 승인한 항목은 표시되기까지 최대 24시간이 걸릴 수 있습니다.
RevenueCat이 확실히 앞서는 지점은 여기 소개된 다른 어떤 도구도 하지 못하는 기능입니다. 대시보드나 REST 엔드포인트를 통해 직접 Google Play 구독 환불을 발행할 수 있으며, 같은 호출에서 접근 권한도 함께 회수됩니다. 고객지원팀이 환불을 직접 처리한다면 이는 중요한 차이입니다.
Adapty Refund Saver
Refund Saver는 이제 Apple뿐만 아니라 Google Play도 지원하며, 이미 iOS에서 사용 중이었다면 기본적으로 활성화되어 있습니다.
차지백 검토 시 사용 증거를 실제로 전송하며, 이는 결과에 실질적으로 영향을 미치는 부분에서 RevenueCat보다 앞서는 지점입니다. Google Play 지원은 8월 3일 변경으로 차지백 비용이 비싸진 이후에 추가되었습니다.
Adapty의 공식 문서에 명시된 솔직한 한계가 두 가지 있습니다. Google은 decline, approve, no preference만 허용하므로, Apple 쪽의 Grant prorated에 대응하는 Google 옵션이 없어 Adapty는 대신 No preference를 전송합니다. 또한 Google은 검토가 완료되어도 알려주지 않으므로, Adapty는 결과가 확정될 때까지 주문 상태를 계속 조회합니다. Play의 결과는 Apple보다 늦게 나타납니다.
진짜 걸림돌은 SDK입니다. Refund Saver는 독립 제품이 아니라 플랫폼 내 기능입니다. 구독에 Adapty를 사용하고 있지 않다면 이를 얻기 위해 플랫폼 자체를 바꿔야 합니다. 일부 팀에게는 합리적인 거래지만, 대부분의 팀에게는 그렇지 않습니다.
Refund Sensor
저희 제품이니, 이를 감안하여 판단하시기 바랍니다.
SDK가 필요 없습니다. Google 계정으로 로그인하고 두 가지 Play Console 권한(재무 데이터 조회, 주문 및 구독 관리)을 부여하면, 사용자 본인의 Google Cloud 프로젝트에 Pub/Sub 토픽과 푸시 구독을 자동으로 구성합니다. Play Console에 붙여넣을 것도 없고, 앱을 새로 배포할 필요도 없습니다.
24시간 이내에 orders.reviewrefund를 통해 배송 및 참여(engagement) 증거와 함께 거부(decline) 권장을 제출하며, 이의를 제기할 수 없는 환불도 별도로 추적합니다. 이는 대부분의 팀이 전혀 파악하지 못하는 부분입니다. 두 스토어 모두 하나의 대시보드에서 확인할 수 있습니다.
솔직한 한계: RevenueCat이나 Adapty보다 출시된 지 얼마 되지 않았으며, 페이월, A/B 테스트, 구독 분석 기능이 없습니다. 그것이 저희 제품의 목적이 아니기 때문입니다. 구독 인프라가 필요하다면 다른 도구도 함께 사용해야 할 것입니다.
RefundHalt
일괄적인 선호도 대신 사례별 규칙을 원한다면 살펴볼 가치가 있습니다. SDK가 필요 없고 두 스토어를 모두 지원하며, 사용자 서버의 엔드포인트에서 사용 증거를 가져오므로 증거가 추정된 것이 아니라 개발자 본인의 데이터입니다.
한 가지 유의할 점이 있습니다. RefundHalt가 공개한 일부 비교 자료는 Refund Saver가 Google Play를 지원하기 이전에 작성된 것이므로, 비교 페이지보다는 최신 공식 문서를 확인하는 것이 좋습니다.
직접 구축하기
합리적인 선택이며, 이미 백엔드를 운영하고 있다면 보기보다 비용이 적게 듭니다.
Monetize 메뉴의 Monetization setup에서 RTDN을 활성화해야 합니다. Pub/Sub 토픽도 필요합니다. base64로 인코딩된 data 필드를 디코딩하고, 다섯 가지 알림 객체 중 어떤 것이 도착했는지에 따라 분기 처리하는 컨슈머(consumer)도 필요합니다. pendingRefundReviewNotification이 오면 pendingRefundToken을 저장하고 24시간의 시간 제한과 경쟁해야 합니다. 그 후 orders.reviewrefund를 한 번 호출하면 됩니다.
주말 동안 끝낼 수 없는 부분은 다음과 같습니다. 7주 전에 구매한 구독에 대한 실제 소비 데이터를 확보하는 것, Google이 재시도를 하므로 멱등성(idempotency)을 보장하는 것, 그리고 알림이 놓친 부분을 잡아내기 위한 야간 Voided Purchases 스윕(sweep)까지 필요합니다. Voided Purchases API versus real-time developer notifications에서 각 피드가 무엇을 담당하는지 다루고 있습니다.
이것이 바로 벤더를 쓰고 싶지 않은 개발자가 Google Play 환불을 자동화하는 방법에 대한 솔직한 답이기도 합니다. 결국 웹훅 컨슈머, 타이머, 그리고 데이터 문제로 귀결됩니다.
그렇다면 어떤 것을 선택해야 할까
이미 RevenueCat을 사용 중이고 주로 감지 기능과 선호도 전송이 필요하신가요? Refund Control입니다. 오늘 바로 활성화하세요.
이미 Adapty를 사용 중이고 추가 작업 없이 증거를 전송하고 싶으신가요? Refund Saver입니다. 이미 활성화되어 있을 가능성이 높습니다.
둘 다 사용하지 않고, 환불 방어를 위해 플랫폼을 바꾸고 싶지 않으신가요? Refund Sensor 또는 RefundHalt입니다.
분쟁 사례가 주로 사기(fraud)에 치우쳐 있고 사례별 로직을 원하시나요? RefundHalt를 사용하거나 직접 구축하세요.
어느 쪽도 아니고 환불 건수가 미미하신가요? 아직은 아무것도 하지 않아도 되지만, RTDN만큼은 연동해 두세요. 무료이며, 나중에 환불 건수가 늘어났을 때 이력 데이터가 필요해질 것입니다.
모든 플랫폼 페이지가 빠뜨리는 부분
Google Play 구독 환불을 어떻게 자동화할 것인가는 대부분의 앱에게 애초에 잘못된 첫 번째 질문입니다. 개발자 입장에서 Google Play 환불은 개발자가 영향을 미칠 수 있는 영역과 반응만 할 수 있는 영역으로 나뉘며, 후자의 목록이 더 깁니다.
이의를 제기할 수 있는 것은 차지백 검토뿐입니다. 그게 전부입니다. 고객지원 환불, 48시간 Play 환불, 미승인 체험판 전환은 모두 개발자의 개입 없이 결정됩니다. 이 영역에서 가능한 유일한 자동화는 이를 빠르게 감지하고 접근 권한을 차단하는 것뿐입니다.
즉, Google Play 환불 자동화는 사실상 트렌치코트를 뒤집어쓴 두 개의 제품입니다. 하나는 차지백 대응 엔진이고, 다른 하나는 그 외 모든 것을 위한 감지 엔진입니다. 대부분의 벤더는 둘 중 하나에만 강합니다. 지금 구매하려는 것이 어느 쪽인지 확인하세요. Google의 환불 보호 및 차지백 비용 공지는 선택하기 전에 읽어볼 가치가 있습니다. 대응 측면이 왜 갑자기 중요해졌는지 설명해주기 때문입니다.
출처
자주 묻는 질문
차지백(chargeback) 항목만 가능합니다. 고객이 은행에 이의를 제기하면 Google이 검토(review)를 시작하며, Review Refund API를 통해 응답할 수 있는 시간은 약 24시간입니다. 그 외 모든 환불 유형은 개발자의 개입 없이 결정되며, 오직 감지만 가능합니다.
이미 사용 중인 시스템에 따라 다릅니다. 구독이 RevenueCat에 있다면 RevenueCat을, Adapty SDK를 사용 중이고 사용 데이터를 자동으로 전송하고 싶다면 Adapty를 선택하세요. 플랫폼을 바꾸지 않고 환불 방어 기능만 원한다면 Refund Sensor나 RefundHalt가 적합합니다.
아니요. Google API는 APPROVE, DECLINE, NEUTRAL만 허용합니다. 비례 환불(prorated refund)은 Apple 쪽에만 존재하며 Google에는 이에 대응하는 옵션이 없으므로, 이를 제공하는 플랫폼들은 Play에서는 대신 'No preference'를 전송합니다.
RTDN과 orders.reviewrefund를 직접 구축해 연동하거나, Play Console 권한과 Google Cloud 프로젝트를 통해 연결되는 서비스를 사용하면 됩니다. 두 방법 모두 앱 바이너리를 건드릴 필요가 없습니다.
천천히 알게 됩니다. Google은 검토가 완료되어도 누구에게도 알려주지 않으므로, 플랫폼들은 주문 상태를 주기적으로 조회(poll)합니다. 결과 데이터는 지연될 수밖에 없으니, 당일 승률보다는 해당 도구가 응답 기한 내에 제출했는지를 기준으로 판단하세요.
2026년 8월 3일부터, 차지백에서 패소하면 구매 금액에서 Google 서비스 수수료를 제외한 금액에 은행 수수료가 추가로 부과됩니다. 저가 상품의 경우 이 수수료만으로도 판매 금액을 초과할 수 있습니다. 결정을 내리기 전에 자신의 주문 금액으로 직접 계산해 보세요.
