Apple 은 이미 승인한 환불을 되돌릴 수 있으며, 서버가 무시한 되돌려진 환불은 돈을 낸 고객을 차단한다

환불이 항상 마지막 말은 아닙니다. App Store 는 고객이 이의를 제기한 후 이미 승인한 환불을 되돌릴 수 있으며, 그 되돌려진 환불이 여러분의 서버에 도착할 때 그것은 하나의 지시를 담고 있습니다. 접근 권한을 돌려주라는 것입니다. 대부분의 팀은 단순한 REFUND 알림을 연결하고, 고객을 차단하고, 거기서 멈춥니다. 그들은 나머지 절반을 결코 만들지 않습니다. 그래서 되돌림이 도착해도 아무것도 실행되지 않고, 다시 돈을 내고 있는 고객은 자신이 구매한 것에서 차단된 채로 남습니다. App Store 와 Google Play 에서 환불 알림의 전체 집합이 어떻게 작동하는지, 그리고 이를 무시할 때 각각 여러분에게 어떤 대가가 따르는지 설명합니다.

App Store 는 환불 알림을 하나가 아니라 세 개 보낸다

대부분의 환불 처리는 단일 이벤트를 위해 만들어집니다. 돈이 돌아갔으니 고객을 차단하라는 것입니다. App Store Server Notifications V2 피드는 실제로 세 가지 별개의 환불 결과를 전달하며, 그것들은 세 가지 다른 것을 요구합니다. 그중 둘은 고객이 접근할 수 있는 것을 바꿉니다. 하나는 첫 번째 것을 되돌립니다. 다음은 Apple 자신의 표현으로 된 전체 집합입니다.

REFUND, 모든 팀이 처리하는 것

App Store 가 환불을 처리하면, 여러분이 설정한 URL 로 REFUND 알림을 보내며, Apple 의 정의는 명료합니다. 그것은 「App Store 가 소비형 In-App Purchase, 비소비형 In-App Purchase, 자동 갱신 구독, 또는 비갱신 구독에 대한 거래를 성공적으로 환불했음을 나타냅니다」. 여러분은 환불된 거래를 저장하고, 그것이 구매한 것을 취소하며, Apple 은 앱 내의 맥락에 맞는 메시지로 무엇이 바뀌었는지를 고객에게 알리도록 요청합니다. 이것은 모두가 가장 먼저 연결하는 알림이며, 종종 유일한 것입니다.

REFUND_DECLINED, 여러분에게 아무것도 요구하지 않는 것

REFUND_DECLINED 는 말 그대로의 의미입니다. 「App Store 가 환불 요청을 거절했습니다」. 고객이 요청했고, Apple 이 아니라고 했으며, 거래는 그대로 유지됩니다. 고객의 접근 권한에 관해서는 아무것도 바뀌지 않으므로, 여러분의 권한 로직은 여기서 아무것도 하지 않습니다. 이 알림의 가치는 기록에 있습니다. 그것은 여러분이 CONSUMPTION_REQUEST 로 응답했을 수도 있는 환불 요청의 고리를 닫고, 고객이 여전히 지불한 것을 가지고 있음을 확인합니다. 그것을 행동이 아니라 기록으로 다루세요.

REFUND_REVERSED, 팀의 허를 찌르는 것

이것은 대부분의 환불 파이프라인이 결코 처리하지 않는 알림입니다. Apple 의 정의는 명백합니다. REFUND_REVERSED 는 「App Store 가 고객이 제기한 분쟁으로 인해 이전에 승인한 환불을 되돌렸음을 나타냅니다. 여러분의 앱이 관련 환불의 결과로 콘텐츠나 서비스를 취소했다면, 그것을 복원해야 합니다」. 그것을 두 번 읽으세요. Apple 이 고객에게 환불을 주었고, 여러분이 접근 권한을 취소했으며, 그런 다음 Apple 이 그 환불이 유지되어서는 안 된다고 판단하여 그것을 회수했습니다. 청구가 다시 유효합니다. 고객은 지불했고, 여러분의 서버가 취소하는 법만 안다면, 그들은 여전히 차단된 상태입니다. 되돌려진 환불은 접근 권한을 다시 더해주는 유일한 환불 이벤트이며, 거의 아무도 대비해 만들지 않는 것입니다.

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

놓친 되돌림은 반올림 오차가 아닙니다. 돈을 양방향으로 따라가 보세요. 어느 쪽 절반을 틀려도 대가가 따르기 때문입니다.

되돌림을 놓치면 돈을 내는 고객을 차단한 채로 둡니다. Apple 이 청구를 복원했으므로 고객은 다시 자기 돈을 썼고, 여러분의 앱은 그가 구매한 것을 거부하고 있습니다. 즉각적인 대가는 지원 시간과, 이제 여러분이 직접 발행해야 할지도 모르는 선의의 환불이며, 이번에는 그것을 완화해 줄 스토어 수수료의 반환이 없습니다. 더 느린 대가는 리뷰와 이탈이며, Google Play 에서는 바로 그 차단으로 인한 불만이 지불 거절로 바뀝니다.

원래 환불을 놓치면 아무것도 지불하지 않은 고객에게 계속 제공하게 됩니다. 거울처럼 반대되는 실수는 아예 취소하지 않는 것입니다. 환불받고도 여전히 이미지를 생성하고, 여러분의 API 를 호출하고, 여러분의 저장소를 채우는 고객은, 되돌려진 판매에 대해 실제 비용을 쌓아 올립니다. 연산, 서드파티 호출, 저장소는 여러분이 이미 쓴 돈이며, 그중 어느 것도 환불과 함께 돌아오지 않습니다.

• 지원 비용. 여러분 자신의 코드가 제거하고 결코 복원하지 않은 접근 권한에 대한 티켓에 응답하는 사람.
• 선의의 환불. 잘못 차단한 고객에게 돈을 다시 발행하는 것. 수동적인 조치에는 스토어 수수료의 반환이 없습니다.
• 낭비된 지출. 결코 차단하지 않은 환불된 계정이 소비한 연산, API 호출, 저장소.
• 지불 거절 위험. Google Play 에서는 이중으로 청구되었다고 느끼는 고객이 이의를 제기할 수 있으며, 패한 분쟁은 이제 여러분에게 떨어집니다.

되돌려진 환불과 단순한 환불은 반대 방향을 가리키는 동일한 webhook 피드입니다. 하나를 처리하고 다른 하나를 건너뛰면, 양쪽 끝에서 대가를 치릅니다.

Apple 이 환불을 되돌리는 이유, 그리고 revocationReason 읽는 법

되돌림은 무작위가 아닙니다. Apple 은 그것을 「고객이 제기한 분쟁」에 연결하는데, 이는 고객이 사후에 환불 결정에 이의를 제기하는 것입니다. 환불이 처음 승인되었을 때, 거래에는 revocationDate 와 revocationReason 이 실려 있었으며, 하류의 무언가가 그것에 따라 작동하기 전에 그 이유를 읽어볼 가치가 있습니다.

• revocationReason 1. App Store 가 「여러분의 앱 내부의 실제 또는 인지된 문제로 인해」 환불했습니다. 그것은 이 고객만이 아니라 여러분의 제품에 관한 신호입니다.
• revocationReason 0. App Store 가 「다른 이유로, 예를 들어 실수 구매로 인해」 환불했습니다. 앱 품질에 관한 신호는 붙어 있지 않습니다.

그 거래에 REFUND_REVERSED 가 도착하면, 취소가 되돌려지고 있는 것입니다. 여러분의 복원 로직은 원래 거래 id 를 조회하고, 여러분이 그것을 취소했음을 확인하고, 권한을 있던 그대로 정확히 되돌려 놓아야 합니다.

Google Play 는 되돌림을 보내지 않으므로, 대신 대조한다

Google Play 의 모델은 다르며, 두 스토어를 하나의 webhook 핸들러로 처리한다면 그 차이는 중요합니다. REFUND_REVERSED 에 상응하는 Google 의 것은 없습니다. Google 의 실시간 개발자 알림은 환불 이벤트를 두 개의 메시지로 나누며, 되돌림은 푸시가 아니라 대조로 처리됩니다.

무효화된 구매 알림

Google Play 구매가 무효화되면, 여러분의 서버는 VoidedPurchaseNotification 을 받습니다. 그것은 purchaseToken 과 orderId, 구독 또는 일회성의 productType, 그리고 전체 무효화이거나 다중 수량 구매에 대한 수량 기반 부분 환불 중 하나인 refundType 을 명시합니다. Google 은 그 데이터가 올바른 구매를 찾아 권한을 조정하기에 충분하다고 말합니다. 그 이상에 대해서는, 여러분이 조회하는 타임스탬프 범위 내의 무효화된 주문을 나열하는 풀 모델인 Voided Purchases API 로 안내합니다.

지불 거절 심사, 그리고 그 24 시간 시계

지불 거절은 다른 메시지, PendingRefundReviewNotification 을 통해 도착합니다. 고객이 자신의 은행에 청구를 이의 제기하면, Google Play 는 이 알림을 보내고 시계를 시작합니다. 여러분에게는 Google 이 여러분을 대신하여 부당한 지불 거절에 이의를 제기할 수 있도록, 환불 선호와 어떠한 사용 증거든 함께 orders.reviewrefund 를 호출할 24 시간이 있습니다. Google 은 여러분의 첫 번째 호출을 기록하고 나머지는 무시합니다. 이것은 Apple 의 CONSUMPTION_REQUEST 에 대한 Google 의 대응물이며, 분쟁에서 여러분 쪽이 중요해지는 유일한 창입니다.

되돌림 푸시가 없기 때문에, Google 이 다투어 이긴 지불 거절은 깔끔한 복원 이벤트로 도착하지 않습니다. 여러분은 그것을 Voided Purchases API 와 여러분 자신의 기록에 대조합니다. 교훈은 App Store 와 같습니다. 무효화된 주문이 항상 영구적인 것은 아니며, 여러분의 권한 상태는 앞으로만이 아니라 뒤로도 움직일 수 있어야 합니다.

아무도 차단하지 않고 모든 환불 알림을 처리하는 방법

스토어마다 별도의 파이프라인은 필요하지 않습니다. 필요한 것은 권한을 양방향으로 움직일 수 있고 모든 메시지를 중복되었을 가능성이 있는 것으로 다루는 핸들러입니다.

• 취소만이 아니라 복원을 만드세요. REFUND 에서 접근 권한을 제거하는 모든 경로에 대해, 같은 거래 id 에 연결하여 REFUND_REVERSED 에서 그것을 복원하는 역방향을 작성하세요.
• 멱등하게 만드세요. 두 스토어 모두 같은 알림을 두 번 이상 전달할 수 있으므로, 각 취소와 복원을 거래 또는 orderId 에 연결하고 반복을 아무 작업도 하지 않는 것으로 만드세요.
• 행동하기 전에 이유를 읽으세요. revocationReason 을 사용하여 앱 품질 환불을 실수 환불과 구별하고, 앱 품질에 해당하는 것을 제품 품질 담당자에게 전달하세요.
• 증거 창에 제때 응답하세요. CONSUMPTION_REQUEST 로부터 12 시간 이내에 Apple 의 소비 데이터를 보내고, PendingRefundReviewNotification 으로부터 24 시간 이내에 orders.reviewrefund 를 호출하세요.
• 모든 이벤트를 저장하세요. REFUND_DECLINED 와 원시 알림을 보관하여, 나중에 도착하는 되돌림을 그것이 되돌리는 환불에 맞출 수 있게 하세요.

이 중 어느 것도 환불이 일어나는지 여부를 바꾸지는 않습니다. 그것이 바꾸는 것은, 되돌려진 환불의 반대편에 있는 고객이 여러분의 서버가 틀렸다는 것을 언젠가 알아차리는지 여부입니다.