지난 몇 년 사이 CONSUMPTION_REQUEST에 관한 글을 읽어봤다면, 계정 사용 기간, 누적 구매 금액, 플레이 시간, 플랫폼 등 열두 개 필드로 된 목록을 본 적이 있을 것입니다.
그 목록은 구버전 엔드포인트의 것입니다. Apple의 현재 엔드포인트는 다섯 개 필드를 받고 그중 세 개가 필수이며, 원래 버전보다 더 많은 상품 유형을 다룹니다. 아직도 많은 실서비스 연동이 옛 구조를 기준으로 만들어져 있습니다.
그래서 이 글에서는 이 알림이 실제로 무엇인지, Apple이 지금 어떤 응답을 원하는지, 그리고 제대로 버티는 응답 경로를 어떻게 구축할지 차례로 살펴봅니다.
핵심 요약
• CONSUMPTION_REQUEST는 환불 검토 중에 정보를 요청하는 알림입니다. 환불도 아니고 결정도 아닙니다.
• 환불 결정은 Apple이 내립니다. 여러분의 응답은 그 결정에 반영되는 입력값 중 하나입니다.
• 현재 엔드포인트는 다섯 개 필드를 받으며 세 개가 필수이고, 모든 상품 유형을 다룹니다.
• 고객 동의는 필수입니다. 동의가 확인되지 않은 요청은 Apple이 거부합니다.
• Apple은 알림 후 12시간 이내 응답을 요구합니다.
• 엔드포인트는 두 가지 버전이 있습니다. 여러분의 연동이 어느 쪽을 호출하는지 확인하세요.
Apple CONSUMPTION_REQUEST란 무엇인가?
Apple CONSUMPTION_REQUEST는 고객이 환불을 요청했음을 서버에 알리고, 해당 구매에 대한 소비 정보를 보내도록 요청하는 App Store Server Notification입니다. 여러분이 설정한 알림 URL로 도착하고, 관련 트랜잭션 정보를 담고 있으며, 응답할 수 있는 시간은 제한되어 있습니다.
이것은 환불 알림이 아닙니다. 도착 시점에는 아무것도 결정되지 않은 상태입니다. Apple은 요청을 평가하는 도중이며, 마무리하기 전에 맥락을 수집하고 있는 것입니다. 개발자 입장에서 실질적인 의미는 단순합니다. 백엔드에 작업 하나가 막 도착했고, 기한이 있으며, 여러분의 시스템에만 있는 데이터가 필요하다는 것입니다.
Apple은 왜 CONSUMPTION_REQUEST를 보낼까?
Apple은 트랜잭션의 절반만 볼 수 있기 때문입니다.
Apple은 무엇을, 언제, 어느 계정이 구매했는지, 그리고 그 계정의 이력이 어떤지 알고 있습니다. 하지만 앱 내부는 볼 수 없습니다. 코인이 지급되었는지, 잠금 해제가 작동했는지, 고객이 환불을 요청하기 전에 얼마나 사용했는지는 알 수 없습니다.
여기서 “소비”란 고객이 구매한 것을 어디까지 사용했는지를 뜻합니다. 3주 동안 매일 사용한 구독과 한 번도 열어보지 않은 구독은 Apple에게는 똑같아 보입니다. 하지만 여러분에게는 다르게 보입니다.
한계도 분명히 해 둘 필요가 있습니다. Apple은 소비 수치만으로 승인하거나 거절하지 않습니다. 이 정보는 여러 요소를 함께 고려하는 결정에 반영되며, 높은 소비 비율이 곧 거절 버튼은 아닙니다.
Apple CONSUMPTION_REQUEST는 어떻게 작동할까?
순서는 다음과 같습니다.
고객이 환불을 요청합니다
↓
Apple이 환불 검토를 시작합니다
↓
CONSUMPTION_REQUEST가 알림 엔드포인트에 도착합니다
↓
알림을 검증하고 트랜잭션을 식별합니다
↓
동의 여부를 확인하고 사용 데이터를 수집합니다
↓
요건이 충족되면 소비 정보를 전송합니다
↓
Apple이 정보를 검토합니다
↓
Apple이 환불 결정을 내립니다
↓
결과에 따른 트랜잭션 상태를 추적합니다
한 가지 단서가 있습니다. Apple의 현재 문서는 이 알림을 모든 상품 유형의 환불 요청과 연관지어 설명하며, 이는 이전 문서가 시사했던 것보다 넓은 범위입니다. 하지만 Apple은 모든 경우에 알림이 도착한다고 보장하지 않으므로, 항상 요청이 온다고 가정하는 로직 대신 요청이 도착했을 때 응답하는 핸들러를 구축하세요.
Apple은 개발자에게 어떤 정보를 요청할까?
Apple의 현재 Send Consumption Information 엔드포인트는 다섯 개 필드를 받습니다. 세 개는 필수이고 두 개는 선택입니다.
필드 | 필수 | 의미 |
customerConsented | 예 | true여야 합니다. 그렇지 않으면 Apple이 요청을 거부합니다. |
deliveryStatus | 예 | 앱이 정상 작동하는 구매 항목을 전달했는지, 아니라면 그 이유. |
sampleContentProvided | 예 | 고객이 구매 전에 콘텐츠를 체험할 수 있었는지 여부. |
consumptionPercentage | 아니오 | 소비된 양을 밀리유닛으로 표시(50%는 50000). |
refundPreference | 아니오 | 전액 승인, 거절, 또는 비례 환불 — 결정이 아닌 여러분의 선호. |
두 가지 검증 규칙에서 많이 걸립니다. 전달 상태가 delivered가 아니면 소비 비율은 0이어야 하며, 그렇지 않으면 요청이 실패합니다. 그리고 밀리유닛은 퍼센트가 아닙니다. 절반을 소비했다면 50000입니다.
환불 선호는 가장 최근에 추가된 항목이자 가장 오해하기 쉬운 부분입니다. Apple에 전액 승인, 거절, 비례 환불 중 어느 쪽을 선호하는지 전달할 수 있고, Apple은 이를 다른 모든 요소와 함께 고려합니다. 결과는 달라질 수 있습니다. 비례 환불이 승인되면 취소된 부분이 트랜잭션 페이로드로 돌아오므로, 권한(entitlement) 로직이 부분 취소를 처리할 수 있어야 합니다.
확인해 볼 만한 버전 차이
Apple은 이 엔드포인트를 두 가지 버전으로 문서화하고 있으며, 이름 때문에 헷갈리기 쉽습니다. Send Consumption Information V1이 이전 버전으로, 대부분의 서드파티 글이 아직 설명하는 열두 개 필드 본문을 사용합니다. 해당 페이지의 Apple 안내에서는 일반 인앱 구매는 현재 엔드포인트를 사용하도록 하고, V1은 Advanced Commerce API를 사용하는 구매로 범위를 한정하고 있습니다.
| 현재 엔드포인트 | V1 엔드포인트 |
요청 필드 | 5개(3개 필수) | 12개 |
상품 유형 | 네 가지 유형 모두 | 소모성 및 자동 갱신 구독 |
사용 대상 | 일반 인앱 구매 | Advanced Commerce API 구매 |
연동이 이 변경 이전에 만들어졌다면, 여기서부터 시작하세요.
소비 정보란 무엇인가?
소비 정보는 고객이 구매한 이후 해당 구매에 어떤 일이 있었는지를 설명해 Apple에 보내는 데이터입니다. 전달되었는지, 사전에 체험할 수 있었는지, 얼마나 사용했는지가 포함됩니다.
이것이 중요한 이유는 전체 그림에서 Apple이 볼 수 없는 유일한 부분이기 때문입니다. 구독 앱이라면 고객이 구매 후 서비스를 사용했는지를 설명합니다. 소모성 상품이라면 잔액이 얼마나 사용되었는지, 비소모성 상품이라면 잠금 해제가 작동했는지를 설명합니다.
핵심은 정확성입니다. 이것은 공유 동의를 받아 여러분의 기록에서 가져온 데이터입니다. 여러분이 구성하는 논거가 아니며, 원하는 결과 쪽으로 왜곡하는 것은 확실한 이득 없이 실질적인 위험만 감수하는 일입니다.
개발자는 CONSUMPTION_REQUEST에 어떻게 응답해야 할까?
아홉 단계이며, 대부분의 작업은 요청이 도착하기 전에 이루어집니다.
1. 알림 수신
요청은 App Store Server Notifications V2용으로 설정한 URL로 도착합니다. Apple의 App Store Server Notifications 문서에서 설정과 페이로드 구조를 다룹니다. 엔드포인트가 잘못 설정되면 요청은 아무 표시 없이 조용히 도달하지 않습니다.
2. 알림 검증
페이로드는 서명되어 있습니다. 내용을 바탕으로 어떤 조치를 취하기 전에 Apple의 인증서 체인으로 검증하고 번들 ID를 확인하세요.
3. 관련 트랜잭션 식별
디코딩한 페이로드에서 트랜잭션 식별자를 추출해 구매 기록과 대조하세요. 저장된 기록이 없으면 조회도 불가능하고, 소비를 설명할 근거도 없습니다.
4. 동의 상태로 응답이 가능한지 확인
Apple은 고객 데이터를 공유하기 전에 유효한 고객 동의를 요구하며, 동의를 받는 것은 여러분의 책임입니다. 알림에는 동의 플래그가 없으므로 자체 기록으로 파악해야 합니다. Apple은 또한 App Tracking Transparency 프롬프트가 이 동의를 위한 수단이 아니라고 명시합니다. 앱 안에서 별도로 수집하는 동의입니다. 동의가 없다면 응답하지 않는 것이 Apple의 지침입니다. 이 조회를 가능하게 하는 식별 측면은 appAccountToken과 Apple 환불 방어에 관한 글에서 다룹니다.
5. 관련 소비 정보 수집
전달 상태와 사용량을 자체 시스템에서 읽어오세요. 소모성 잔액을 추적하고 있다면 그 숫자는 이미 존재합니다. 잠금 해제가 실패했다면 로그에 남아 있습니다.
6. 지원되는 응답 준비
필수 필드를 채우고, 실제 값이 있는 경우 선택 필드를 추가하고, 먼저 검증 규칙을 확인하세요.
7. Apple의 기한 내 제출
알림에 포함된 원래 트랜잭션 식별자를 사용해 소비 엔드포인트로 PUT 요청을 보내세요.
8. 응답 기록
무엇을, 언제 보냈고, 무엇이 돌아왔는지 저장하세요. 결과를 기록하지 않았다면 검증에 실패한 제출과 성공한 제출은 똑같아 보입니다.
9. 최종 환불 결과 추적
Apple은 결정을 별도의 알림으로 보냅니다. 트랜잭션과 고객에 연결해 기록하세요.
개발자는 얼마 안에 응답해야 할까?
Apple의 현재 문서는 알림 수신 후 12시간 이내 응답을 요구합니다.
12시간은 넉넉해 보이지만, 알림이 언제 도착하는지 생각해 보면 그렇지 않습니다. 요청은 한밤중, 주말, 연휴에도 들어오고 시계는 멈추지 않습니다. 금요일 밤 11시에 도착한 요청은 월요일이 되기 전에 만료됩니다.
Apple은 기한을 놓치면 자동으로 환불이 승인된다고 명시하지 않으며, 그렇게 주장하는 것은 잘못입니다. 실제 의미는 더 단순합니다. Apple이 고려할 의향이 있던 정보를 여러분이 제공하지 않았고, 결정은 그 정보 없이 내려진다는 것입니다.
개발자가 응답한 후에는 어떻게 될까?
Apple은 그 정보를 검토에 반영해 결정을 내립니다. 결과는 알림으로 확인할 수 있습니다. 승인, 거절, 또는 이전에 승인한 환불을 Apple이 취소하는 경우 나중에 번복될 수 있습니다.
그 다음부터는 여러분의 몫입니다. 환불이 승인되면 권한을 회수하고, 번복되면 복원하고, 트랜잭션의 일부만 돌아오는 비례 환불 사례를 처리하세요.
구독 상태에도 주의가 필요합니다. 환불된 기간은 보통 구독을 유지시키지 않고 종료시키며, 환불은 해당 기간의 매출 기록에 반영되어야 합니다.
역할 분담을 분명히 하자면, 여러분은 정보를 제공하고, Apple이 결정하며, 그 결과에 맞춰 여러분이 시스템을 동기화합니다. 세 가지 별개의 책임 중 Apple의 몫은 가운데 하나뿐입니다.
수동으로 CONSUMPTION_REQUEST를 처리하기 어려운 이유는?
이 워크플로의 모든 제약은 사람이 직접 처리하기에 불리하게 작용합니다.
알림은 24시간 내내 도착합니다. 기한은 12시간입니다. 요청마다 서명 확인, 트랜잭션 조회, 사용자 매칭, 동의 확인, 사용량 계산, 인증된 API 호출, 결과 기록이 필요합니다. 어느 것도 어렵지 않습니다. 하지만 모두 시간 제한이 있고 반복적이며, 제대로 됐을 때는 눈에 보이는 결과가 없습니다.
규모가 커지면 더 나빠집니다. 여러 앱, 한 시스템에 있는 트랜잭션 데이터와 다른 시스템에 있는 사용 데이터, 빈틈이 생기는 응답 로그, 아무도 모르게 트랜잭션 상태와 어긋나는 권한 상태. 수동 처리가 항상 비용을 발생시킨다는 뜻은 아니지만, 위험은 실재하며 조용히 누적됩니다.
Apple CONSUMPTION_REQUEST를 자동화할 수 있을까?
가능합니다. 거의 모든 단계가 결정론적이기 때문에 워크플로의 구조 자체가 자동화를 뒷받침합니다.
자동화로 알림을 모니터링하고 검증하고, 그중 소비 요청을 식별하고, 트랜잭션을 계정에 연결하고, 기록에서 응답을 구성하고, 기한을 추적하고, 제출하고, 결과를 로그에 남기고, 최종 결과를 기록하고, 권한 업데이트를 반영할 수 있습니다.
자동화가 할 수 없는 것은 Apple의 결정에 영향을 미치는 일입니다. 어떤 도구도 그것을 바꾸지 못하며, 그렇게 암시하는 제품은 프로세스를 잘못 설명하는 것입니다. 자동화가 바꾸는 것은 여러분 쪽 작업이 일관되게, 기한 안에 이루어지는지 여부입니다.
RefundSensor가 Apple 환불 워크플로 처리에 도움이 되는 방식
App Store 환불 관리가 이 작업이 속한 카테고리입니다. RefundSensor는 그중 개발자 쪽을 담당합니다. Apple 환불 관련 워크플로를 모니터링하고, 지원되는 CONSUMPTION_REQUEST 응답 경로를 처리하며, 환불 이벤트와 결과를 대시보드와 스프레드시트에 흩어 두는 대신 한곳에 모아 관리합니다.
실제로는 누군가 알림을 지켜보지 않아도 응답이 기한 안에 나가고, 볼륨이 늘어도 환불 기록이 정확하게 유지됩니다. 환불을 막아주지는 않으며 Apple의 특정 결정을 보장할 수도 없습니다. 수동 모니터링과 놓치는 단계를 줄여줍니다.
이 규칙들이 문서화된 곳
위 내용은 모두 세 가지 Apple 자료를 근거로 합니다. 직접 읽어보고, 주기적으로 다시 확인하세요. 이 영역은 최근에 바뀌었고 2차 자료는 뒤처져 있습니다.
Send Consumption Information — 현재 엔드포인트입니다. 동의 요건, 12시간 기한, 다섯 개 필드 요청 본문, 적용되는 상품 유형을 다룹니다. 일반 인앱 구매는 이 엔드포인트를 기준으로 구축하세요.
Send Consumption Information V1 — 열두 개 필드 본문을 사용하는 이전 엔드포인트입니다. 여러분의 연동이 어느 버전인지 파악하거나 Advanced Commerce API를 사용하는 팀에 유용합니다.
App Store Server Notifications — 알림이 백엔드에 도달하는 방식, 서명된 페이로드 형식, 그리고 CONSUMPTION_REQUEST와 환불 결과를 포함한 알림 유형을 다룹니다.
아직 수작업으로 처리하고 있다면
12시간 기한과 새벽 3시에 도착하는 알림은 누군가 대시보드를 확인하는 데 의존하는 프로세스와 맞지 않습니다.
여러분의 팀이 그런 상황이라면, RefundSensor가 이 워크플로의 개발자 쪽을 처리합니다. 알림을 모니터링하고, 기한 안에 응답을 준비해 제출하며, 결과를 권한 기록까지 추적합니다.
자주 묻는 질문
고객이 환불을 요청했으며 Apple이 해당 구매에 대한 소비 정보를 보내도록 요청하고 있음을 서버에 알리는 App Store Server Notification입니다. 환불 알림도 아니고 결정도 아닙니다. Apple은 여러분의 응답을 여러 요소 중 하나로 활용해 별도로 결정을 내립니다.
Apple은 앱 내부를 볼 수 없기 때문입니다. 트랜잭션과 계정 이력은 알지만, 콘텐츠가 전달되었는지, 제대로 작동했는지, 고객이 얼마나 사용했는지는 알 수 없습니다. 그 맥락은 여러분의 시스템에 있으며, Apple은 검토를 마무리하기 전에 이를 요청합니다.
고객이 환불을 요청하면 Apple이 검토를 시작하고, 설정된 엔드포인트로 알림이 도착합니다. 여러분은 알림을 검증하고, 트랜잭션을 식별하고, 동의를 확인하고, 사용 데이터를 수집한 뒤 기한 안에 소비 정보를 전송합니다. Apple은 이를 검토해 결정하고, 결과를 별도의 알림으로 보냅니다.
현재 엔드포인트 기준으로 다섯 개 필드입니다. 필수 세 개는 고객 동의, 전달 상태, 샘플 콘텐츠 제공 여부입니다. 선택 두 개는 구매 항목의 소비 비율과 여러분이 선호하는 환불 결과입니다. 이전 V1 엔드포인트는 열두 개를 요구했기 때문에 오래된 글에서는 훨씬 긴 목록을 설명합니다.
Apple의 현재 문서는 이 알림을 모든 상품 유형의 환불 요청과 연관지어 설명하며, 이는 이전 문서가 시사했던 것보다 넓은 범위입니다. 하지만 Apple은 모든 경우에 대한 보장을 명시하지 않으므로, 항상 요청이 온다고 가정하는 로직 대신 요청이 도착했을 때 응답하는 핸들러를 구축하세요.
Apple 문서는 알림 후 12시간 이내 응답을 요구합니다. 요청은 주말을 포함해 어느 시간에나 도착하므로, 수동 프로세스에서 가장 놓치기 쉬운 단계입니다. 오래된 연동에 의존하지 말고 Apple 페이지에서 현재 요건을 확인하세요.
정보를 제공할 수는 있지만 통제할 수는 없습니다. 정확한 소비 데이터는 Apple이 갖지 못한 맥락을 제공하며, 현재 엔드포인트에서는 환불 선호를 명시할 수 있습니다. Apple은 이를 다른 요소와 함께 고려하며 다르게 결정할 수도 있습니다. 개발자가 환불을 승인하거나 거절하는 메커니즘은 없습니다.
가능합니다. 알림 검증, 트랜잭션 식별, 동의 상태 확인, 기록에서 데이터 구성, 기한 준수, 제출, 결과 로그 기록은 모두 결정론적인 단계입니다. 사람이 해야 할 일은 앱 내 동의 흐름을 설계하고 환불 선호 정책을 결정하는 것입니다.
