모든 Google Play 구매에 난독화 계정 id를 새겨라, 그렇지 않으면 지불 거절이 추적할 방법 없이 도착한다

Google Play 지불 거절 검토는 주문과 구매 토큰만 지목한 채 나타납니다. 고객이 누구인지는 알려 주지 않습니다. 그 구매에 당신 자신의 식별자를 새기지 않았다면, 당신은 이제 24시간의 시계 아래에서 맨 주문 id를 사용자 테이블에 맞춰 보아야 하고, 어쩌면 찾지 못할 사용 증거로 답해야 합니다. 난독화 계정 id가 그 해결책입니다. 그것은 결제 시 붙이는 짧은 문자열로, Google Play가 구매와 함께 저장했다가 나중에 당신에게 돌려주므로, 모든 주문을 그것을 한 바로 그 사용자까지 되짚을 수 있습니다. 아래에서는 이 필드가 무엇인지, 왜 그것이 분쟁에 답할 수 있는지 여부 자체를 좌우하는지, 그리고 패소한 지불 거절이 청구서가 된 지금 건너뛰는 대가가 무엇인지 설명합니다.

난독화 계정 id는 실제로 무엇인가

난독화 계정 id는 고객이 무언가를 살 때 Google Play 결제 흐름에 넘기는 선택적 문자열 하나입니다. BillingFlowParams 빌더의 setObfuscatedAccountId로 설정하며, Google이 구매와 함께 저장합니다. 그것은 고객의 이름도, 이메일도, Google 계정도 아닙니다. 그것은 당신 자신의 사용자에 대한 당신 자신의 식별자이며, Google이 그 사람이 누구인지 알지 못한 채 보관할 수 있는 형태로 쓰인 것입니다.

그것은 결제 시 설정하는 문자열이지 이름이 아니다

Google의 표현으로, setObfuscatedAccountId는 당신 앱에서 구매자의 사용자 계정에 고유하게 연결된 선택적 난독화 문자열을 지정합니다. '난독화'라는 단어는 실제 역할을 합니다. Google은 당신의 원시 사용자 id도, 그 사람을 식별하는 어떤 것도 원하지 않습니다. 원하는 것은 당신 쪽의 한 사용자와 일대일로 대응하는 안정적인 토큰뿐, 그 이상은 아닙니다. 이 필드는 64자로 제한되어 해시는 넉넉히 담지만 그 밖의 것은 별로 담지 못합니다.

Google은 먼저 자신의 사기 심사를 위해 그것을 읽는다

당신에게 쓸모 있기 전에, 이 필드는 Google을 위해 한 가지 일을 합니다. 결제 문서에는, Google Play가 이 값을 사용하여 짧은 시간 안에 같은 계정에서 여러 기기가 구매하는 것과 같은 비정상 활동을 감지할 수 있으며, Google은 이 데이터를 사용하여 의심스러운 행위를 감지하고 일부 유형의 사기 거래를 완료되기 전에 차단한다고 나와 있습니다. 그래서 설정의 첫 번째 보상은 상류에 있으며, 더 깨끗한 구매와, 나중에 무효화와 분쟁이 되는 사기 구매의 감소로 나타납니다. Google이 난독화 계정 id와 Voided Purchases API를 두 가지 핵심 남용 방지 도구로 나란히 꼽는 데에는 이유가 있습니다.

지불 거절 검토가 도착할 때 왜 중요한가

예상할 수 있는 환불은 쉽습니다. 어려운 경우는 은행 지불 거절입니다. 왜냐하면 그것은 고객이 당신에게 말을 거는 데서 시작하지 않기 때문입니다. 그것은 은행에서 시작하고, Google Play는 시계를 붙인 검토로 당신에게 전달합니다.

분쟁이 지목하는 것은 주문이지 사람이 아니다

고객이 은행에 청구를 이의 제기하고 Google이 당신의 의견을 필요로 할 때, Google Play는 PendingRefundReviewNotification을 보냅니다. 그 메시지가 식별하는 것은 주문입니다. 그것은 당신의 사용자 id를 담지 않는데, Google은 당신의 사용자 id를 가진 적이 없기 때문입니다. 가진 것은 당신이 구매에 새긴 것뿐입니다. 그것이 아무것도 아니었다면, 당신은 이제 맨 주문 id와 구매 토큰을 자기 기록에 역검색하며, 구매 시점에 그 토큰을 기록해 두었기를, 그리고 그 대조가 모호하지 않기를 바라야 합니다. 난독화 계정 id를 설정해 두었다면, 구매는 당신 자신의 해시를 지니고, 한 번의 쿼리로 사용자를 찾아, 신원 찾기가 아니라 증거 만들기로 넘어갑니다.

orders.reviewrefund가 실제로 당신에게 요구하는 것

분쟁에 답한다는 것은 24시간 안에 orders.reviewrefund 메서드를 호출하는 것입니다. Google은 당신의 첫 호출을 기록하고 나머지는 무시하므로, 첫 답이 유일한 답입니다. 다음은 그것이 원하는 필드이며, 증거 필드는 하나같이 주문이 어느 사용자의 것인지 당신이 이미 안다고 전제합니다.

건너뛰는 대가는 실제로 얼마인가

Google Play 역사의 대부분 동안, 방어할 수 없는 지불 거절은 매출 손실이자 어깨를 으쓱하고 넘길 일이었습니다. 그것이 바뀌었습니다. 2026년 8월 3일 이후에 발생한 주문의 경우, 패소한 지불 거절은 개발자에게 구매 가격에서 Google 서비스 수수료를 뺀 금액에 은행의 지불 거절 수수료를 더해 청구합니다. 당신이 답할 수 없는 그 분쟁은 이제 하나의 항목입니다.

주문 하나를 끝까지 따라가 봅시다. 고객이 $9.99 구매를 은행에 이의 제기합니다. Google Play가 검토를 보내고, 당신에게는 24시간이 있습니다. 구매에 태그를 달았다면, 사용자를 찾아 산 것의 대부분을 소비했음을 확인하고, DECLINE 선호와 소비 증거로 reviewrefund에 답하여 Google에게 부당한 분쟁을 다툴 실제 근거를 줍니다. 태그를 달지 않았다면, 제때 주문을 식별하지 못하거나 아무것도 없이 답하게 되고, 분쟁은 당신 쪽 의견 없이 판정되며, 8월 3일 이후 주문에서는 $9.99에서 Google 수수료를 뺀 금액을 돌려주고, 흔히 $20 가까이에 이르는 정액 은행 지불 거절 수수료를 냅니다. 소액 판매에서는 그 정액 수수료만으로도 당신이 남긴 순액보다 클 수 있습니다.

• 잃은 수익: 이 판매에서의 당신 순몫이 되돌려진다.
• 은행의 지불 거절 수수료: 카드 네트워크가 정하는 정액 비용. 2026년 8월 3일 이후에 발생한 주문에 추가로 부과되며, 일반 환불에는 결코 붙지 않는다.
• 낭비된 지출: 그 계정이 이미 쓴 연산, 서드파티 API 호출, 저장 공간. 답할 수 있었든 없었든 사라진다.
• 보이지 않는 패턴: 안정적인 계정 id가 없으면 같은 사용자가 거듭 이의 제기하고 있다는 것도 알 수 없어, 상습적 남용이 서로 무관한 일회성 손실로 읽힌다.

구매가 차단되지 않게 설정하는 방법

두 가지 규칙이 팀들이 이 필드에서 저지르는 거의 모든 실수를 덮습니다. id를 해시하고, 어디에나 설정하는 것입니다.

사용자 id를 해시하고, 절대 PII를 보내지 마라

이 필드에 이메일, 전화번호, 또는 어떤 원시 개인 정보도 넣지 마세요. Google은 이메일 같은 PII를 평문으로 저장하면 구매가 차단된다고 명시하며, 값 생성에는 단방향 해시나 암호화를 권장합니다. 깔끔한 방식은 내부 사용자 id의 단방향 해시를 매번 같은 방식으로 계산하여, 같은 사용자가 항상 같은 64자 문자열을 만들게 하는 것입니다. 그 사람의 Google 계정 id도, 당신의 개발자 id도 쓰지 마세요. 그 값은 오직 당신 시스템에만 의미가 있어야 합니다.

모든 구매에 설정하고, 서버에서 되읽어라

이 id를 일회성 상품이든 구독이든 모든 결제 흐름에 붙여, 라벨 없는 구매가 결코 생기지 않게 하세요. 구매 후에는 두 곳에서 되읽습니다. 클라이언트에서는 Purchase.getAccountIdentifiers가 객체를 반환하고, 그 getObfuscatedAccountId가 당신이 설정한 문자열을 줍니다. 백엔드에서는 서버 측 구매 레코드가 그것을 obfuscatedExternalAccountId 필드로 지니며, 믿어야 할 것은 서버 사본입니다. 분쟁은 기기가 아니라 당신 서버에 도착하기 때문입니다.

한 계정에 여러 프로필이 있을 때는 setObfuscatedProfileId를 사용하라

당신 앱이 한 계정에 여러 프로필을 둘 수 있게 한다면, 예컨대 스트리밍 가정이나 여러 캐릭터가 있는 게임이라면, setObfuscatedProfileId도 함께 설정하세요. 그것도 같은 종류의 해시된 64자, PII 없는 문자열이며, 구매를 한 프로필로 범위가 한정됩니다. Google은 프로필 id를 설정할 때 계정 id도 함께 넘기도록 요구한다고 밝히므로, 둘 다 보내세요. 그 결과 분쟁이 계정뿐 아니라 그 돈을 쓴 바로 그 프로필까지 대응됩니다.

iOS의 대응, 한 줄로

App Store는 다른 이름으로 같은 발상을 지니고 있습니다. iOS에서는 구매에 appAccountToken, 즉 UUID를 붙이며, 그것은 거래에, 그리고 고객이 환불을 요청할 때 Apple이 보내는 CONSUMPTION_REQUEST에 돌아옵니다. 문제의 형태는 두 스토어에서 동일합니다. 분쟁이나 환불 흐름은 거래를 참조하고, 당신 자신의 식별자가 바로 그것을 사용 내역을 보고할 수 있는 사용자에게 이어 주는 것입니다.

이 중 어느 것도 만들기 어렵지 않습니다. 건너뛰기는 쉽습니다. 결제 코드를 쓰는 날은 지불 거절이 도착하는 날이 아니고, 건너뛴 대가는 그때까지 보이지 않기 때문입니다. RefundHalt는 두 스토어에서 계정 식별자를 설정하고 추적하며, 구매와 사용자의 연결을 유지하여 분쟁이 언제나 실제 고객으로 해결되게 하고, 판매 시점에 기록한 소비 증거를 담아 Google Play의 orders.reviewrefund와 Apple의 CONSUMPTION_REQUEST에 각자의 기한 안에 답합니다. 24시간의 시계는 누가 그 물건을 샀는지 말할 수 없음을 깨달을 순간이 아닙니다.