Прочитайте код причины возврата, который ваш сервер и так получает, и он подскажет, чинить приложение или спорить с клиентом

Когда Apple или Google возвращает деньги одному из ваших клиентов, деньги обычно уже ушли до того, как у вас появится голос. То, что попадает на ваш сервер потом, выглядит как чек, и большинство команд относятся к нему именно так. Это больше, чем чек. Каждый возврат несёт код причины возврата, и это единственная часть возврата, которую вы всё ещё можете прочитать после того, как решение принято. Google Play говорит вам, что возврат был чарджбэком, или запросом из-за того, что клиент передумал, или покупкой, которую ваше собственное приложение так и не подтвердило. Apple говорит вам, винит ли возврат что-то внутри вашего приложения. Прочитайте этот код, и возврат перестаёт быть строкой в отчёте и становится инструкцией: почини это, оспорь это или отпусти это. Вот что означает каждый код, как их сортировать и сколько стоит каждый.

Что на самом деле такое код причины возврата

Код причины возврата, это собственная метка магазина, объясняющая, почему покупка была отменена. Вы его не задаёте и не можете с ним спорить. Он приходит прикреплённым к возврату постфактум, и два магазина раскрывают его в разных формах и с очень разной детализацией.

Google Play проставляет причину и источник на каждой отмене

Voided Purchases API от Google Play возвращает одну запись на каждую отменённую покупку, и каждая запись несёт два целых числа, которые важны. voidedReason говорит, почему покупка была отменена. voidedSource говорит, кто это запустил. Вместе они превращают простой возврат в предложение: этот заказ был отменён из-за чарджбэка, инициированного Google, или отменён из-за того, что клиент передумал, инициированного пользователем. Вы читаете это, опрашивая API или подписавшись на уведомление для разработчиков в реальном времени, которое срабатывает, когда приходит отмена. В любом случае эти два числа, это та полезная нагрузка, которую стоит сохранять.

Apple даёт более узкий сигнал, но чёткий

Apple не выдаёт вам причину с девятью значениями. На возвращённой транзакции Apple задаёт revocationReason одному из двух значений. 1 означает, что App Store вернул транзакцию из-за реальной или предполагаемой проблемы внутри вашего приложения. 0 означает, что он вернул её по другой причине, например из-за случайной покупки. Поле появляется только на транзакциях, которые были возвращены или отозваны, рядом с revocationDate, внутри подписанной информации о транзакции в App Store Server Notification REFUND. Два значения, это немного, но то, которое важно, 1, это Apple говорит вам, что возврат был о вашем продукте, а не о том, что клиент передумал.

Девять причин, которые даёт вам Google Play

voidedReason от Google богаче из двух, и каждое значение стоит знать с первого взгляда, потому что каждое указывает в другое место. Вот полный набор, прямо из ресурса VoidedPurchase, с тем, что каждый код на самом деле велит вам сделать.

voidedSource говорит вам, кто нажал на спусковой крючок

Рядом с причиной стоит voidedSource, и он отвечает на другой вопрос: кто отменил это. 0 означает, что это сделал пользователь, через самообслуживание или банк. 1 означает, что это сделал разработчик, то есть вы или ваши собственные инструменты, выпустившие возврат. 2 означает, что это сделал Google по собственному решению, включая автоматический возврат за неподтверждённую покупку. Когда вы видите всплеск отмен, источник, это первый разрез. Стена из источника 2, это Google, действующий по вашему аккаунту, и обычно это сигнал, указывающий обратно на вашу интеграцию, а не на ваших клиентов.

Рассортируйте каждый возврат на починить, оспорить или принять

Причина, по которой код полезен, в том, что он говорит вам, какой из трёх ответов заслуживает возврат. Большинство команд относятся ко всем возвратам одинаково и тратят усилия на те, которые никогда не смогут выиграть. Коды делятся чётко.

Починить: возвраты, которые вызвал ваш продукт

Некоторые коды, это отчёты об ошибках в одежде возврата. Дефект (3) и не получено (2) у Google, и revocationReason 1 у Apple, все говорят одно и то же: клиент заплатил, а ваше приложение не доставило. Неподтверждённая покупка (8), самый чёткий из них, потому что вина полностью в вашем коде выставления счетов. Это самые дешёвые возвраты для устранения, потому что вы устраняете их, починив что-то своё, а не убеждая кого-либо. Растущее число в этой стопке, это дефект продукта с приложенной суммой в деньгах.

Оспорить: возвраты, которые кто-то обрабатывает

Мошенничество (5), дружественное мошенничество (6) и чарджбэк (7), это споры. Чистое мошенничество (5), это не ваш клиент и не доход, который вы когда-либо собирались удержать. Дружественное мошенничество (6), когда покупатель получил ровно то, за что заплатил, а затем оспорил это, это единственный спор, который ваши доказательства всё ещё могут сдвинуть, а чарджбэк (7), это место, где эти доказательства подаются. Когда один из них приходит, вы отзываете доступ, если ещё не сделали этого, и там, где открыто окно рассмотрения, вы отвечаете на него тем, что знаете об аккаунте.

Принять: возвраты, которые вы никогда не могли предотвратить

Передумал (1) и случайная покупка (4), это собственное изменение решения клиента. revocationReason 0 у Apple тоже здесь. Ни одна функция не отказала, и никакого мошенничества не произошло. Вы можете смягчить корзину случайных покупок более понятным подтверждением покупки, но вы не можете переспорить возврат из-за того, что клиент передумал, и время, потраченное на попытки, это время, отнятое у стопки починки, где на самом деле находятся деньги.

Ловушка 30 дней, из-за которой коды причин легко потерять

На стороне Google есть жёсткое ограничение, которое превращает это из функции отчётности в срок. Если вы не захватываете коды непрерывно, вы их теряете.

Voided Purchases API смотрит назад только на 30 дней

Google прямо заявляет: API может показать только отменённые покупки за последние 30 дней. Более старые отмены не возвращаются, какой бы startTime вы ни передали, а само значение startTime нельзя задать раньше, чем 30 дней назад. Хуже для наивной интеграции то, что окно в 30 дней измеряется по тому, когда системы Google видят покупку как отменённую, а не по тому, когда покупка была совершена, и даже не по voidedTimeMillis в записи. Так что код причины возврата, который вы не вытянули внутри этого окна, пропал, а ежемесячная задача экспорта с любым пробелом молча отбросит отмены, которые она была слишком медленной, чтобы поймать.

Сколько коды причин стоят в деньгах

Два кода несут конкретную цену, и их чтение, это то, как вы ставите число на проблемы, которые иначе прячутся внутри агрегированной доли возвратов.

Один код, это счёт, который вы выписали себе сами

voidedReason 8, неподтверждённая покупка, самый чистый пример возврата, который вызвали вы. Google Play требует, чтобы ваше приложение подтвердило покупку в течение трёх дней после предоставления права, и если вы этого не делаете, Google автоматически возвращает заказ и отзывает товар. Каждая отмена с отметкой 8, это реальная продажа клиенту, который хотел продукт, отданная обратно, потому что вызов для подтверждения покупки так и не сработал. Потерянная сумма, это полная цена продажи плюс вычисления, вызовы API и хранилище, которые вы уже потратили на её доставку. Это не возврат, о котором вы договариваетесь. Это ошибка, которую вы закрываете, и код, это то, как вы её находите.

Код чарджбэка теперь несёт сбор

voidedReason 7, чарджбэк, изменил стоимость 3 августа 2026 года. Для заказов Google Play, размещённых в эту дату или позже, проигранный чарджбэк стоит разработчику цену покупки за вычетом сервисного сбора Play, плюс банковский сбор за чарджбэк, тогда как Google покрывает только свой собственный сервисный сбор. Поскольку сборы за чарджбэк фиксированы, а цены продуктов нет, на дешёвой встроенной покупке один только сбор может превысить то, что заплатил клиент. Подсчёт ваших отмен с кодом 7 теперь, это подсчёт статьи расходов, а не просто потерянной продажи, и именно поэтому корзина чарджбэков заслуживает собственной строки в любом отчёте о возвратах, который вы строите.

Как выстраиваются Apple и Google

Два магазина отвечают на один и тот же вопрос с разной детализацией, поэтому межмагазинный отчёт о возвратах должен нормализовать их, а не ожидать, что они совпадут.

Магазины никогда не дадут вам один и тот же код для одного и того же возврата, и это нормально. Важно то, что оба выдают вам машиночитаемую причину, и оба вознаграждают команду, которая её читает. Единственный бит Apple говорит вам, когда возврат, это вина вашего продукта. Девять причин Google и его флаг источника говорят вам, какая ошибка продукта, какой спор и какой самому себе нанесённый пробел в выставлении счетов вы рассматриваете. Ни один код не останавливает возврат. Оба говорят вам, что делать, чтобы следующий не случился.

RefundHalt захватывает код причины на каждом возврате в момент его прихода, в обоих магазинах, и удерживает его с хорошим запасом внутри 30-дневного окна Google, чтобы ничего не ускользнуло. Он сортирует каждую отмену на починить, оспорить или принять, так что всплеск кода 3 дефект доходит до вас как оповещение о продукте, а всплеск кода 8 неподтверждённая доходит до вас как ошибка интеграции, а не как смутный спад дохода. Он отвечает на CONSUMPTION_REQUEST от Apple в течение 12 часов и на рассмотрение чарджбэка в Google Play в течение 24, и отзывает доступ в момент, когда приходит возврат или чарджбэк. Вы не можете изменить код, который магазин ставит на возврат. Вы можете убедиться, что читаете каждый из них и действуете по тем, которые действительно ваши, чтобы их починить.