이제 모든 Apple 환불 요청에는 이유가 함께 오며, consumptionRequestReason 이 그것을 읽는 방법입니다

Apple 은 환불 요청이 여러분의 서버에 도착하는 방식을 바꿨지만, 많은 개발자가 전혀 눈치채지 못했습니다. WWDC24 에서 발표된 App Store Server Notifications 2.11 업데이트 이후, 모든 CONSUMPTION_REQUEST 알림은 consumptionRequestReason 이라는 필드를 담고 있습니다. 그것은 고객이 직접 밝힌 환불 사유입니다. 하나의 평범한 문자열, 다섯 가지 가능한 값이, 여러분이 이미 열두 시간에 걸쳐 답하게 되어 있는 바로 그 페이로드 안에 담겨 옵니다.

Apple 환불 요청 사유는 그 자체로는 아무것도 결정하지 않습니다. 그것이 하는 일은 여러분이 매우 다른 다섯 가지 상황 중 어디에 있는지를 알려 주는 것입니다. 그리하여 승인해야 할 환불과 다퉈야 할 환불에 같은 일반적인 소비 데이터를 보내는 일을 멈추게 됩니다. 여기서 이 필드가 무엇인지, Apple 이 보낼 수 있는 정확한 값, 각 값이 무엇을 신호하는지, 그리고 그것이 여러분이 돌려보내는 선호와 증거를 어떻게 바꿔야 하는지를 설명합니다.

consumptionRequestReason 은 실제로 무엇인가

consumptionRequestReason 은 CONSUMPTION_REQUEST 알림의 data 객체 안에 있는 문자열 필드입니다. Apple 은 WWDC24 의 환불 흐름 변경과 함께 App Store Server Notifications 버전 2.11 에서 이를 추가했습니다. 그 전에는 요청이 서명된 트랜잭션과 함께 도착했지만 동기에 관해서는 아무것도 없었습니다. 여러분은 눈을 가린 채 답했습니다. 이제 고객이 밝힌 사유가 요청과 함께 도착합니다.

'밝힌' 이라는 단어를 주의 깊게 읽으십시오. 이것은 고객이 Apple 에 신청할 때 선택한 사유이지, Apple 이 검증한 사실이 아닙니다. UNINTENDED_PURCHASE 는 그 구매가 사용되지 않았음을 증명하지 않고, UNSATISFIED_WITH_PURCHASE 는 제품이 망가졌음을 증명하지 않습니다. 이 값은 렌즈이지 판결이 아닙니다. 여러분은 여전히 그것을 자신의 전달 및 사용 기록과 함께 맞춰 봅니다.

그것은 여러분이 이미 처리하는 알림에 실려 온다

CONSUMPTION_REQUEST 는 Apple 이 개발자에게 증거를 요청하는 유일한 흐름입니다. Google Play 에서의 대응물은 orders.reviewrefund 를 통한 차지백 심사입니다. 하나가 도착하면, 여러분은 Send Consumption Information 을 호출해 답할 12시간이 있습니다. 그것은 트랜잭션 소비 엔드포인트로 보내는 PUT 입니다. consumptionRequestReason 은 이제 같은 알림의 일부이므로 새로 구독할 것은 없습니다. 이미 CONSUMPTION_REQUEST 를 파싱하고 있다면, 이 사유는 아마 여러분이 무시해 온 하나의 필드일 뿐입니다.

다섯 가지 사유, 그리고 각각이 무엇을 말하는가

Apple 은 정확히 다섯 개의 값을 문서화합니다. 요청마다 하나가 도착합니다. 여기에 전체 목록과 실무에서 각각을 어떻게 읽는지를 제시합니다.

UNINTENDED_PURCHASE 는 실수 탭 범주다

이것은 아이가 10,000 개의 코인을 산 뒤에 부모가 선택하는 사유이거나, 확인을 잘못 누른 성인이 선택하는 사유입니다. 그것은 한 번도 열리거나 사용되지 않은 구매와 상관관계가 있습니다. 바로 그래서 여러분 자신의 데이터가 중요합니다. 기록이 그 소모성 상품이 완전히 전달되고 많이 소비되었음을 보여 준다면, 비의도적 구매라는 주장과 다 써 버린 잔액은 서로 맞지 않으며, 그 간극은 consumptionPercentage 를 통해 보고할 가치가 있습니다.

FULFILLMENT_ISSUE 는 화살을 여러분에게 되돌린다

FULFILLMENT_ISSUE 는 고객이 아니라 부분적으로 여러분의 앱에 관한 유일한 사유입니다. 그것은 그들이 지불한 것을 받거나 사용할 수 없었다고 말한다는 뜻입니다. 반사적으로 이의를 제기하기 전에 전달 로그를 꺼내 보십시오. 여러분 자신의 서버가 권한이 한 번도 활성화되지 않았거나 크레딧이 한 번도 지급되지 않았음을 보여 준다면, 고객이 옳고 DECLINE 은 잘못된 선호입니다. 진짜 전달 실패와 다투는 것은 창을 낭비하고 고객을 은행으로 밀어붙일 수 있으며, 그곳에서 차지백의 대가는 본래의 환불보다 더 비쌉니다.

UNSATISFIED_WITH_PURCHASE 는 증거가 결정하는 곳이다

이것은 평범한 구매자의 후회이며, 여러분의 소비 데이터가 가장 크게 일하는 사유입니다. 제품은 작동했습니다. 고객은 그 일부 또는 전부를 사용했고 이제 돈을 돌려받고 싶어 합니다. 높은 consumptionPercentage, 정직한 DELIVERED 의 deliveryStatus, 그리고 DECLINE 또는 GRANT_PRORATED 의 refundPreference 가 바로 Apple 이 여러분에게 세우기를 요청하는 주장입니다. 논쟁이 아니라 숫자를 보내십시오.

LEGAL 과 OTHER

LEGAL 은 고객이 법적 또는 규제상의 권리를 원용했다는 뜻입니다. 분별 있는 사람들도 견해가 갈리지만, 원칙적으로 여기는 소송을 벌일 창이 아닙니다. 승인하고 넘어가십시오. OTHER 는 밝혀진 사유가 위 네 가지 어디에도 들어맞지 않을 때 Apple 이 쓰는 포괄 항목입니다. 그 자체로는 아무 신호도 없으므로, OTHER 는 사유가 전혀 없는 요청과 정확히 똑같이 다루십시오. 전달 상태와 사용 증거를 앞세우는 것입니다.

사유가 여러분의 답변을 필드별로 어떻게 바꾸는가

여러분은 ConsumptionRequest 본문을 붙여 Send Consumption Information 을 호출함으로써 CONSUMPTION_REQUEST 에 답합니다. 사유는 그 본문 안의 세 필드를 빚어야 합니다.

customerConsented 는 true 여야 한다

Apple 은 customerConsented 가 true 일 때, 즉 고객이 소비 데이터 공유에 동의했을 때에만 그 제출을 받아들입니다. 그 동의가 없다면, 사유가 무엇이든 여러분은 애초에 데이터를 보낼 수 없습니다. 동의 없음, 증거 없음, 그리고 요청은 여러분의 숫자 없이 결정됩니다.

deliveryStatus 와 consumptionPercentage 가 사실을 담는다

deliveryStatus 는 여러분이 작동하는 구매를 전달했는지를 말합니다. 그것이 DELIVERED 이외의 무언가라면, Apple 은 consumptionPercentage 가 0 이기를 요구합니다. 여러분이 실제로 전달했을 때, consumptionPercentage 는 milliunits 단위로 0 부터 100,000 까지의 정수이며, 100,000 은 고객이 구매 전체를 사용했음을 의미합니다. 이 한 쌍은 여러분의 사실적 핵심이며, 사유 그 자체가 아니라 FULFILLMENT_ISSUE 나 UNSATISFIED_WITH_PURCHASE 주장을 담아야 하는 것입니다.

refundPreference 는 여러분의 유일한 지렛대다

refundPreference 는 여러분이 원하는 바를 밝히는 곳입니다. Apple 은 세 가지 값을 문서화합니다. GRANT_FULL, GRANT_PRORATED, DECLINE 입니다. 사유를 읽고, 그것을 여러분의 데이터와 견주어 보고, 그런 다음 고르십시오. 로그에 전달 실패가 있는 FULFILLMENT_ISSUE 는 GRANT_FULL 로 기웁니다. 완전히 소비된 제품에서의 UNSATISFIED_WITH_PURCHASE 는 DECLINE 또는 GRANT_PRORATED 로 기웁니다. LEGAL 은 GRANT_FULL 로 기웁니다.

환불이 실제로 여러분에게 치르게 하는 대가

사유 필드가 중요한 이유는, 환불이 그 판매를 장부에서 지우는 것에 그치는 경우가 드물기 때문입니다. 이미 돌아간 소모성 상품에 대해 여러분은 그것을 이행하려고 돈을 냈습니다. 유료 추론 API 를 호출한 크레딧 팩, GPU 시간을 태운 생성 이미지 한 묶음, 저장 청구서에 눌러앉은 저장된 내보내기 파일, 이미 보낸 크리에이터 정산금. 이 비용들은 구매가 취소되어도 이미 쓰인 채로 남습니다. 스토어는 고객의 돈을 돌려줍니다. 그것은 여러분의 연산을 돌려주지 않습니다.

바로 그래서 사유는 읽을 가치가 있습니다. 어떤 고객이 각각 유료 API 호출을 일으키는 5,000 개의 크레딧을 사서 그중 4,000 개를 쓰고 나서 UNSATISFIED_WITH_PURCHASE 로 신청했다고 합시다. 여러분의 deliveryStatus 는 DELIVERED, 여러분의 consumptionPercentage 는 80,000 milliunits 이며, DECLINE 또는 GRANT_PRORATED 선호는 API 청구를 스스로 떠안는 것과 그 대부분을 되찾는 것 사이의 차이입니다. 이제 사유를 FULFILLMENT_ISSUE 로 뒤집고 크레딧이 한 번도 지급되지 않았음을 보여 주는 로그를 붙이면, 정직하고 더 저렴한 수는 고객이 은행으로 확대하기 전의 GRANT_FULL 입니다.

과잉 반응하지 않고 사유를 읽기

함정은 사유를 증거로 다루는 것입니다. UNINTENDED_PURCHASE 는 제품이 사용되지 않았다는 자백이 아니고, LEGAL 이 언제나 진짜 법적 주장인 것도 아닙니다. 사유는 상황을 좁힙니다. 그것을 해결하는 것은 여러분의 전달 로그와 소비 기록입니다. 그것들이 고객과 일치할 때는 일찍, 저렴하게 승인하십시오. 그것들이 고객과 모순될 때, deliveryStatus 와 consumptionPercentage 로 표현된 그 모순이 여러분이 보낼 수 있는 가장 강한 것입니다. RefundHalt 는 모든 CONSUMPTION_REQUEST 에서 consumptionRequestReason 을 읽고 그것을 여러분의 실제 사용 데이터와 자동으로 짝지어, 각 사유가 12시간의 창 안에서 마땅한 응답을 받도록 합니다.

이 변화는 작고 놓치기 쉽지만, 환불이라는 대화를 여러분에게 유리한 쪽으로 옮겼습니다. Apple 은 이제 여러분이 답하기 전에 이유를 말해 줍니다. 그것을 활용하십시오.