개발자가 환불 요청에 대응할 때 구매 데이터를 활용하는 방법

환불 요청 처리 방법을 다루는 대부분의 가이드는 알림이 오는 시점부터 시작합니다. Apple이 알림을 보내고, Google이 알림을 보내면, 이렇게 답하라는 식이죠. 틀린 말은 아니지만, 알림이 도착할 때쯤이면 정말 중요한 작업은 이미 끝났거나 이미 놓친 뒤입니다. 구매에 대해 무엇을 말할 수 있는지는 그 일이 일어났을 때 무엇을 기록해 두었는지에 달려 있기 때문입니다.

그래서 이 글은 더 이른 시점, 즉 결제 시점부터 시작합니다. 환불 요청이 들어왔을 때 어떤 구매 데이터가 중요한지, 그것을 어디에 보관해야 하는지, 그리고 그것이 스토어가 실제로 고려하는 답변으로 어떻게 이어지는지 다룹니다. 구매에 식별자를 연결해 본 적이 없다면, 먼저 appAccountToken과 환불 방어에 관한 글을 읽어보세요. 아래 내용은 모두 거래 ID를 특정 인물과 연결할 수 있다는 전제에서 출발하기 때문입니다.

핵심 요약

• Apple과 Google 모두 환불 여부를 자체적으로 결정하며, 두 플랫폼 모두 먼저 개발자에게 구매 데이터를 요청합니다. Apple은 12시간, Google은 24시간을 줍니다.

• 스토어가 원하는 것은 상세 로그가 아니라 대략적인 사실입니다. 전달되었는지, 얼마나 사용했는지, 샘플을 제공받았는지, 그리고 개발자가 선호하는 결정은 무엇인지입니다.

• 구매마다 네 가지를 기록해 두어야 합니다. 누구인지, 언제 전달되었는지, 언제 사용되었는지, 그리고 이 계정에 과거 환불을 해준 적이 있는지입니다.

• Apple에 따르면 대부분의 환불 요청은 구매 후 30일 이내에 발생합니다. 데이터는 최소한 그 기간만큼, 현실적으로는 90일 정도 보관하세요.

• 요청에 응답하기 시작한 앱은 환불율이 약 3분의 1 감소하지만, 이는 기록해 둔 데이터가 있을 때만 가능한 이야기입니다.

스토어가 실제로 요구하는 것

Apple의 요청 사항은 많지 않습니다. 고객이 인앱 구매에 대해 환불을 요청하면 CONSUMPTION_REQUEST를 받게 되고, 개발자는 Send Consumption Information 엔드포인트를 통해 다섯 가지 필드로 응답합니다. 고객이 데이터 공유에 동의했는지, 구매가 전달되었는지, 소비된 비율은 얼마인지(밀리유닛 단위이므로 100,000이면 전부 소비한 것), 무료 샘플이나 체험판을 먼저 사용했는지, 그리고 개발자의 환불 선호도입니다. Apple은 예전에 10여 개의 필드를 요구했지만 대부분을 없앴는데, 이는 Apple이 고객의 이력을 개발자보다 이미 더 잘 알고 있다고 판단했기 때문이라고 봅니다.

Google의 방식은 차지백을 위한 것으로, 조금 더 상세합니다. 환불 검토 대기 알림은 토큰과 함께 Real-time Developer Notifications를 통해 도착합니다. 개발자는 그 토큰과 동일한 샘플 콘텐츠 플래그, DECLINE·APPROVE·NEUTRAL 중 하나의 선호도, 선택적인 소비 비율, 그리고 타임스탬프가 포함된 사용 이벤트 최대 1,000개를 담아 orders.reviewrefund에 요청을 보냅니다. 2026년 8월 3일 이후 주문에 대해 Google이 개발자에게 차지백 비용을 청구하기 시작하면서 이 부분이 더욱 중요해졌습니다.

어느 스토어도 분석 데이터 전체를 원하지 않습니다. 이들이 원하는 것은 전달 여부, 소비, 샘플 제공, 선호도이며, 그 밖에 개발자가 저장하는 모든 데이터는 이 네 가지 항목을 정확하고 빠르게 채워 넣기 위해 존재하는 것입니다.

환불을 위한 구매 이력: 무엇을, 얼마나 오래 보관할 것인가

최소한으로 필요한 것은 다음과 같습니다.

결제 시점의 식별자. Apple에서는 appAccountToken, Google에서는 obfuscatedAccountId입니다. 이것이 없으면 환불 요청에 거래명은 있어도 그것이 누구의 것인지 알 수 없습니다. Apple 엔지니어들은 사용자마다 최소 하나의 originalTransactionId를 보관할 것도 권장하는데, 이 값만 있으면 Get Transaction History를 호출해 해당 고객이 앱을 아직 설치하고 있는지 여부와 관계없이 전체 구매 이력을 가져올 수 있기 때문입니다.

전달 기록. 코인을 지급했거나 레벨을 해제한 시점을 타임스탬프와 결과값으로 남겨 둡니다. 전달에 실패했다면 그렇다고 솔직하게 밝히세요. 이것이야말로 환불이 승인되기를 바라야 하는 유일한 경우이며, 그렇지 않은 척하면 나중에 필요할 신뢰를 잃게 됩니다.

소비 이벤트. 모든 탭을 기록할 필요는 없고, 구매가 실제로 사용되었음을 의미하는 이벤트만 기록하면 됩니다. 코인 사용, 챕터 열람, 내보내기 실행 같은 것들입니다. Google은 최대 1,000개까지 받습니다. Apple은 비율만 원하지만, 애초에 기록해 두지 않은 값으로는 비율을 계산할 수 없습니다.

제품별 샘플 플래그. 이 고객이 체험판, 미리보기, 무료 등급을 이용했는지 여부입니다. 두 스토어 모두 예/아니오로 답하면 되는데, 사람들이 이를 자주 놓칩니다.

해당 계정의 이전 환불 이력. Apple은 어차피 환불 이력을 자체적으로 고려하지만, 개발자 자신의 규칙을 위해서도 이 데이터가 필요합니다.

보관 기간과 관련해 Apple은 대부분의 환불 요청이 30일 이내에 들어온다고 밝히며, 그에 맞춰 소비 데이터를 저장하라고 안내합니다. 저희는 90일을 보관하는데, Google의 차지백은 그보다 더 늦게 들어올 수 있다는 점도 있고, 저장 비용은 저렴한 반면 기억에 의존해 주장하는 것은 그렇지 않기 때문이기도 합니다.

구매 이력이 환불 처리에 도움이 되는 방식

이것이 갖춰지면 환불 요청은 더 이상 판단의 문제가 아니라 조회의 문제가 됩니다.

전달 완료, 완전히 소비, 샘플 없음, 이전 환불 없음: 이런 경우는 DECLINE에 해당합니다. 전달 완료, 거의 사용하지 않음, 하루 안에 요청: GRANT_FULL을 선택해도 손해가 크지 않고, 거부하면 옹졸해 보일 수 있습니다. 개발자 측 전달 실패: 환불을 승인하고 버그를 고치세요. 몇 주에 걸쳐 일부만 사용: Apple에는 이를 위한 GRANT_PRORATED가 있고, Google에서는 소비 비율이 같은 역할을 합니다.

수치도 이를 뒷받침합니다. 구독형 오디오 앱인 Dipsea는 2024년 말부터 Apple의 요청에 응답하기 시작했고, 약 2주 만에 환불율이 3퍼센트에서 1.9퍼센트로 줄었습니다. 차지백과 관련해 Appcharge는 PocketGamer에 근거 없이 진행된 분쟁은 20~30퍼센트의 확률로 이기지만, 증거를 뒷받침한 경우는 80퍼센트 이상 이긴다고 밝혔습니다. Refund Sensor를 사용하는 800개 이상의 앱 전체로 보면, 방어 가능한 요청의 77퍼센트가 방어에 성공했으며, 실패한 경우는 대부분 기록된 데이터가 없는 경우였습니다.

구매 이력이 해 주지 않는 일은 이기면 안 되는 논쟁에서 이기게 해 주는 것입니다. 고객의 데이터가 앱을 단 한 번 열었다고 말해 준다면, 정직한 답은 환불입니다.

제한 시간 내에 환불 요청을 처리하는 방법

두 스토어 모두 환불 요청 처리 과정에 시간 제한이 있으므로, 이는 판단보다는 배관 작업, 즉 시스템 구축의 문제에 가깝습니다. 알림은 개발자가 등록해 둔 엔드포인트로 도착합니다. 서명을 검증하고, 거래 ID를 가져오고, 사용자의 전달 및 소비 기록을 조회하고, 비율을 계산하고, 미리 작성해 둔 규칙에 따라 선호도를 선택한 뒤 전송합니다. 무엇을 언제 보냈는지 기록해 두고 결과를 기다립니다. Apple의 경우 결과는 REFUND 또는 REFUND_DECLINED 알림으로 옵니다. REFUND인 경우 같은 시간 안에 접근 권한을 회수하세요. 환불받고도 콘텐츠를 계속 보유하는 고객은 또 그런 요청을 반복하는 경향이 있기 때문입니다.

사람들이 흔히 실수하는 부분이 두 가지 있습니다. 동의: Apple은 customerConsented가 true가 아니면 제출을 받아주지 않으므로, 첫 요청이 들어오기 전에 이용 데이터 공유에 대한 동의를 이용약관에 포함해야 합니다. 그리고 타이밍: 시간 제한은 주말이라고 멈추지 않으며, 놀랄 만큼 많은 요청이 밤사이에 들어옵니다. 환불 요청 관리는 결국 무언가가 항상 깨어 있도록 만드는 일입니다. 운영 측면을 더 깊이 다룬 Apple 환불 요청 관리 가이드를 참고하세요.

개발자를 위한 환불 처리 소프트웨어, 아니면 직접 구축할 것인가

백엔드 팀이 있다면 위에서 설명한 파이프라인은 일주일 정도의 작업이고, 그 이후로는 지속적인 유지 업무가 됩니다. 그리고 이 유지 업무가 비용이 많이 드는 부분입니다.

RevenueCat이나 Adapty를 사용하고 있다면, 두 서비스 모두 SDK가 이미 수집한 사용 데이터를 바탕으로 Apple의 소비 요청에 응답해 주며, Adapty는 Google의 검토도 함께 처리합니다. 어차피 SDK가 앱에 들어가 있다면 합리적인 기본 선택지입니다.

Refund Sensor는 SDK 없이 동일한 일을 합니다. App Store Connect API 키와 알림 URL을 연결하면, 요청을 받아 제한 시간 내에 답변을 보내고 사례별 타임라인을 관리해 줍니다. 설정은 몇 분이면 끝나고 요금제는 정액제입니다. 자세한 내용은 Refund Sensor 사이트에서 확인할 수 있습니다.

무엇을 선택하든, 아무것도 선택하지 않더라도, 데이터 계층은 전적으로 개발자의 몫입니다. 개발자를 위한 어떤 환불 처리 소프트웨어도 개발자가 남겨 두지 않은 전달 기록을 대신 만들어 낼 수는 없습니다.

결론

환불 방어는 흔히 대응의 문제로 이야기되지만, 사실은 기록의 문제에서 비롯된 결과입니다. 스토어는 네 가지 좁은 질문을 던지며, 이에 답할 수 있는지 여부는 누군가 환불을 원하기 훨씬 전, 결제와 전달 시점에 개발자가 내린 결정에 달려 있습니다.

식별자를 연결하고, 전달과 소비를 타임스탬프와 함께 기록하고, 샘플 여부를 표시하고, 이 모든 것을 90일간 보관하세요. 이것이 갖춰지면 환불 요청을 처리하는 방법은 규칙 하나와 크론 작업 하나로 정리되고, 환불율은 자연스럽게 알아서 개선되는 경향이 있습니다.