빠른 답변: 고객이 인앱 구매나 구독에 대해 Apple에 환불을 요청하면, App Store는 서버로 CONSUMPTION_REQUEST 알림을 보내고 Send Consumption Information 엔드포인트를 통해 소비 데이터로 응답할 수 있는 시간을 약 12시간 제공합니다. Apple은 이 데이터를 결정에 반영합니다. 제시간에 응답하지 않으면 Apple이 여러분의 의견 없이 결정을 내리며, 부당한 환불도 기본적으로 승인되는 경우가 많습니다. 이 응답을 자동화하면 매번 모든 요청이 기한 내에 답변됩니다.
요약
Apple은 결제 인프라를 소유하고 있습니다. 누군가 여러분의 앱에서 구독이나 인앱 구매를 하면 Apple이 대금을 수령하고, 수수료를 가져가며, 환불을 처리합니다. 수년간 개발자는 환불 결정에 대해 어떠한 발언권도 없었습니다.
이제는 달라졌습니다. Apple은 이제 소비 정보, 즉 고객이 구매한 항목을 어떻게 사용했는지에 대한 구조화된 증거를 보낼 수 있게 해주며, 이를 환불 결정에 반영합니다. 여러분이 직접 환불을 승인하거나 거부할 수는 없으며, 최종 결정은 여전히 Apple이 내립니다. 하지만 아무 응답도 하지 않으면 Apple은 참고할 자료가 전혀 없게 되고, 잘 작성된 응답은 맥락을 제공합니다.
문제는 타이밍과 일관성입니다. 응답 기한은 짧고 예측할 수 없는 시간에 시작되며, 실질적인 규모에서 이를 수작업으로 처리하는 것은 불가능합니다. 이것이 바로 애플 환불 자동화가 해결하는 문제입니다.
Apple 환불 흐름이 실제로 작동하는 방식
전체 과정은 다음과 같습니다.
고객이 환불을 요청합니다. 고객은 reportaproblem.apple.com에 접속해 구매 항목을 선택하고, 사유를 고른 뒤 제출합니다.
Apple이 서버에 알립니다. 환불 가능한 구매의 경우, App Store는 App Store Server Notifications V2를 통해 CONSUMPTION_REQUEST 알림을 보냅니다. 페이로드에는 구매를 식별하는 서명된 거래 데이터가 포함됩니다. 이러한 app store server notifications가 자동화된 워크플로를 실행시키는 트리거입니다.
소비 데이터로 응답합니다. 원본 거래 ID와 전달, 사용, 동의, 환불 선호도를 설명하는 구조화된 ConsumptionRequest 본문을 담아 Send Consumption Information을 호출합니다. send consumption information 엔드포인트는 이 과정에서 핵심적인 API 단계입니다.
Apple이 결정합니다. Apple의 환불 결정 시스템은 여러분이 보낸 데이터를 고객의 이력 및 기타 요소와 함께 고려하여 결정을 내립니다.
결과가 통보됩니다. REFUND 알림은 환불이 승인되었음을, REFUND_DECLINED 알림(StoreKit API를 통해 시작된 요청의 경우)은 환불이 거부되었음을 의미합니다.
CONSUMPTION_REQUEST에 담긴 내용과 여러분이 보내야 할 응답
알림 자체에는 서명된 거래 정보와 고객이 밝힌 사유(consumptionRequestReason)가 담겨 있습니다. 실제로 중요한 작업이 이루어지는 곳은 여러분의 응답입니다. Apple은 다음과 같은 필드를 포함하는 구조화된 ConsumptionRequest를 정의합니다.
필드 | Apple에 전달하는 정보 |
customerConsented | 고객이 이 데이터를 공유하는 데 동의했는지 여부입니다. 반드시 true여야 하며, 그렇지 않으면 Apple이 제출을 거부합니다. |
consumptionStatus | 구매한 콘텐츠가 소비되지 않았는지, 일부 소비되었는지, 완전히 소비되었는지를 나타냅니다. |
deliveryStatus | 인앱 가치나 서비스가 실제로 제공되었는지를 나타냅니다. |
accountTenure | 고객이 여러분의 서비스에서 계정을 보유한 기간입니다. |
playTime | 고객이 앱에서 보낸 시간입니다. |
lifetimeDollarsPurchased | 고객이 여러분의 앱 전체에서 지출한 총액입니다. |
lifetimeDollarsRefunded | 이전에 고객에게 환불된 총액입니다. |
sampleContentProvided | 고객이 구매 전에 콘텐츠를 체험해볼 수 있었는지 여부입니다. |
userStatus | 고객 계정의 현재 상태입니다(활성, 정지 등). |
refundPreference | Apple에 대한 여러분의 권장 사항입니다: 미선언, 승인 선호, 거절 선호. |
각 필드는 하나의 신호입니다. 비워두면 Apple은 그 맥락을 전혀 얻지 못합니다. 모든 필드와 허용 값에 대한 자세한 설명은 CONSUMPTION_REQUEST 알림이란 무엇인가? 필드별 상세 분석에서 확인할 수 있습니다. 애플 환불 API를 검토 중인 개발자라면 이러한 필드가 전체 환불 워크플로에서 어떻게 작동하는지도 이해해야 합니다.
12시간의 응답 기한
프로덕션 환경에서 CONSUMPTION_REQUEST에 응답할 수 있는 시간은 약 12시간입니다. 이 기한을 놓치면 의견을 제시할 기회를 잃게 되며, Apple은 이미 가지고 있는 정보만으로 결정을 내립니다.
문제는 기한의 길이가 아니라 언제 시작되는지입니다. 환불 요청은 업무 시간을 기다려주지 않습니다. 기한은 밤사이, 주말, 또는 휴일에도 시작될 수 있으며, 누군가가 상시 대기하지 않는 한 수작업 검토 큐로는 이를 감당할 수 없습니다. 이는 개발자가 충분히 대응할 수 있었던 환불을 놓치는 가장 흔한 이유입니다. 잘못된 응답 때문이 아니라 응답 자체가 없었기 때문입니다. 이 내용은 12시간의 응답 기한: 대부분의 개발자가 기본적으로 환불을 잃는 이유에서 더 자세히 다룹니다.
동의 요건, 절대 건너뛰지 마세요
이 부분에서 거의 모든 사람이 실수를 저지르는데, 이는 단순한 기술적 문제가 아니라 법적인 문제이기도 합니다.
Apple의 CONSUMPTION_REQUEST는 고객이 데이터 공유에 동의했는지 알려주지 않습니다. 이는 의도된 설계입니다. Apple은 소비 데이터가 전송되기 전에 동의를 수집하고 확인하는 주체가 서버가 아닌 여러분의 앱이어야 한다고 기대합니다. API 호출에서 customerConsented를 true로 설정해야 하며, 사용자로부터 수집한 데이터를 공유하는 주체가 여러분이기 때문에 유효한 동의를 받았는지에 대한 책임은 전적으로 개발자인 여러분에게 있습니다.
이를 잘못 처리하면 제출이 거부될 위험뿐 아니라 GDPR이나 DPDP 규정 준수 문제까지 감수해야 합니다. 무엇이든 자동화하기 전에 앱의 이용약관과 구매 흐름에서 동의를 제대로 처리하세요. 정확히 어디서, 어떻게 처리해야 하는지는 고객 동의와 Consumption API: Apple이 실제로 요구하는 것에서 다룹니다.
이를 자동화하는 데 실제로 필요한 것
이론상으로는 응답을 자동화하는 일이 주말 프로젝트처럼 들립니다. 알림을 받아서, 필드를 채우고, 엔드포인트를 호출하면 됩니다. 하지만 실제 프로덕션에서는 상시 운영되는 인프라가 필요하며, 실제로 무엇이 필요한지 이해하는 것이 "직접 구축하겠다"와 "포기하겠다"를 가르는 차이가 됩니다.
신뢰할 수 있는 사내 응답 시스템을 구축하려면 Apple의 서명된 알림을 수신하고 검증해야 하고, 요청이 도착하는 즉시 각 고객의 정확한 최신 사용 및 결제 데이터를 가져와야 하며, 그 데이터를 Apple의 정확한 ConsumptionRequest 값에 매핑해야 하고, 사람이 지켜보지 않아도 언제든 약 12시간의 기한 내에 제출할 수 있어야 합니다. 이뿐만 아니라 기한을 놓치지 않는 재시도 로직, 실패 처리, 감사 가능한 로깅, 문제 발생 시 알 수 있는 모니터링, 그리고 Apple이 페이로드나 필드를 변경할 때마다 필요한 지속적인 유지보수까지 필요합니다. 이 중 어느 것도 여러분의 제품 자체는 아닙니다. 앱이 실제로 하는 일과는 아무 관련이 없는 워크플로를 위해 무기한으로 소유해야 하는 인프라일 뿐입니다. (알림 계층에 대해서는 App Store Server Notifications V2 설정하기에서 더 자세히 다룹니다.)
대부분의 팀이 결국 내리는 결론은 이렇습니다. 작동 원리는 파악할 수 있지만, 규정을 준수하고 기한을 놓치지 않는 응답 시스템을 구축하고 계속 돌보는 일은 앱 자체에는 아무런 이점 없이 영구적으로 드는 비용이라는 것입니다. 이는 관리형 서비스가 존재하는 바로 그 이유인, 차별화되지 않는 배관 작업입니다.
RefundSensor가 바로 이 역할을 합니다. 웹훅 URL 하나만으로 App Store Connect 설정에 연결되며, SDK도, 코드 변경도, 앱 재제출도 필요 없습니다. 그런 다음 Apple의 기한 내에 모든 CONSUMPTION_REQUEST에 자동으로 응답하고, 여러분의 데이터를 필드에 매핑하며, 재시도와 모니터링을 처리하고, Apple의 변경 사항에 맞춰 최신 상태를 유지하며, 모든 결과를 하나의 dashboard에 기록합니다. 직접 구축하거나 유지보수하지 않고도 잘 만들어진 응답 시스템의 결과를 얻을 수 있습니다. Apple 환불 자동화 소프트웨어를 찾는 팀에게 이는 워크플로를 사내에서 직접 유지하는 대신 사용할 수 있는 관리형 대안입니다.
응답하면 실제로 환불이 줄어들까요?
네, 다만 결과는 상황에 따라 다르고 최종 결정은 언제나 Apple이 내립니다. 정확한 소비 데이터를 제출하면 Apple 시스템이 더 많은 맥락을 얻게 되며, 꾸준히 응답하는 개발자는 요청에 응답하지 않는 개발자보다 대체로 승인되는 환불 건수가 더 적습니다. 증거가 실제로 이를 뒷받침하는 경우 "거절 선호" 권장을 선택하는 것도 Apple이 고려하는 추가적인 입력값입니다. 이는 대규모로 구독 환불 워크플로를 관리할 때 특히 중요할 수 있습니다.
자동화가 할 수 있는 것과 할 수 없는 것
한계에 대해 스스로 솔직해질 필요가 있습니다.
보장할 수 없는 것은 특정 환불이 거절되는 것입니다. 최종 결정은 언제나 Apple이 내립니다.
CONSUMPTION_REQUEST를 아예 생성하지 않는 환불에는 이의를 제기할 수 없습니다. 모든 환불이 이를 생성하는 것은 아닙니다.
해당되는 모든 요청이 일관되고 정확한 데이터로 기한 내에 응답되도록 보장할 수는 있습니다. 이를 통해 단순히 아무도 알림을 보지 못했다는 이유로 환불을 놓치는 일이 없도록 할 수 있습니다.
이 마지막 부분이 핵심입니다. Apple의 결정을 뒤집는 것이 아니라, 여러분이 항상 발언할 차례를 놓치지 않도록 보장하는 것입니다.
세부 사항은 Apple의 공식 자료를 최종 기준으로 삼으시기 바랍니다.
업계는 개발자가 환불 과정에서 발언권을 얻기까지 15년이 걸렸습니다. 매번 그 발언권을 활용하세요. RefundSensor는 Apple CONSUMPTION_REQUEST 알림에 기한 내에 자동으로 응답하고, Apple과 Google Play 모두에서 모든 결과를 추적합니다.무료로 시작하기
자주 묻는 질문
고객이 환불 가능한 인앱 구매나 구독에 대해 환불을 요청할 때 Apple이 서버로 보내는 App Store Server Notification입니다. Apple이 환불 결정에 반영할 소비 데이터로 응답해야 한다는 신호입니다.
프로덕션 환경에서는 약 12시간입니다. 제시간에 응답하지 않으면 Apple이 여러분의 의견 없이 결정을 내리며, 응답하지 않은 요청은 기본적으로 승인되는 경우가 많습니다.
아니요. 거절을 권장하는 refundPreference를 보낼 수는 있지만, 최종 결정은 항상 Apple이 내립니다. 자동화는 매번 정확한 데이터가 제출되도록 보장함으로써 성공 확률을 높여줄 뿐, 거부권을 주는 것은 아닙니다.
네. 앱 내에서 유효한 동의를 받아야 하며 customerConsented를 true로 설정해야 합니다. Apple은 이 동의를 대신 수집해주지 않으며, 동의 없이 데이터를 전송하면 개인정보 보호 규정 준수 위험이 발생하고 그 책임은 개발자에게 있습니다.
아니요. CONSUMPTION_REQUEST에 대한 응답은 App Store Server Notifications와 Consumption API를 통해 서버 측에서 이루어집니다. RefundSensor를 사용하면 App Store Connect에 웹훅 URL 하나만 붙여넣으면 되며, SDK도, 코드 변경도, 재제출도 필요하지 않습니다.
Apple은 여러분의 데이터 없이 절차를 진행합니다. 맥락을 제공할 유일한 기회를 놓치게 되며, 부당한 환불을 포함해 환불이 승인될 가능성이 더 높아집니다.
