Ваши данные о потреблении информируют решение Apple о возврате, но не управляют им

Клиент нажимает возврат, и в течение минуты ваш сервер получает CONSUMPTION_REQUEST от Apple. У вас есть 12 часов, чтобы ответить данными о потреблении, и возникает соблазн прочитать этот ответ как право вето: отправьте предпочтение отклонить, оставьте деньги себе. Это не вето. Собственная документация Apple говорит, что App Store использует множество факторов для определения того, будет ли запрос на возврат одобрен или отклонен, и что предоставленные вами данные о потреблении служат для информирования его решений о возврате. Информировать, а не решать. Этот пост разбирает, что на самом деле меняют ваши данные о потреблении, почему покупка, для которой указано предпочтение отклонить, все равно может быть возвращена, и чего стоит все это упражнение, когда вы учтете уже потраченные деньги.

Что Apple на самом деле делает с вашими данными о потреблении

Эндпоинт Send Consumption Information существует, чтобы вы могли передать Apple контекст в момент, когда возврат под вопросом. Он не передает вам само решение. Чтение этого потока в правильном порядке, это разница между разумными ожиданиями и заведением бага на поведение, которое задокументировано.

App Store решает, а вы рекомендуете

Apple явно разделяет роли. В справочнике по Send Consumption Information Apple пишет, что App Store использует множество факторов для определения того, будет ли запрос на возврат одобрен или отклонен, и что он использует предоставленные вами данные о потреблении для информирования своих решений о возврате. О самом поле refundPreference Apple заявляет, что ваше предпочтение по возврату, это один из множества факторов, которые App Store использует для информирования своих решений о возврате. Значит, самый сильный сигнал, который вы можете отправить, прямое предпочтение отклонить, все равно остается одним входным параметром в модели, которую вы не контролируете. История клиента, указанная им причина, тип продукта и собственные сигналы Apple о мошенничестве, все это находится в той же модели рядом с вашим ответом.

CONSUMPTION_REQUEST теперь охватывает подписки, а не только расходуемые покупки

Раньше это была история про расходуемые покупки. Начиная с WWDC24 уведомление CONSUMPTION_REQUEST срабатывает, когда клиент запрашивает возврат за расходуемую внутреннюю покупку или автопродлеваемую подписку. Это большое расширение охвата. Тот же 12-часовой ответ теперь применяется и к возвратам по подпискам, где ваше влияние иное, потому что Apple сама рассчитывает потребление для автопродлеваемых подписок и не примет от вас предпочтение пропорционального возврата. Читайте тип продукта в каждом запросе, прежде чем решать, насколько сильно может давить ваш ответ.

Пять входных параметров, которые вам разрешено отправлять

Тело запроса V2, которое принимает Apple, невелико, работу делают пять полей, и три из них обязательны. Каждый из них, это входной параметр, который Apple взвешивает, а не переключатель, форсирующий исход. Вот что вы можете вложить в ответ и что это сообщает Apple.

12-часовое окно и барьер согласия, который пропускает большинство команд

Две механики решают, будет ли ваш ответ вообще учтен. Одна, это часы. Другая, это флаг согласия, который останавливает множество благих ответов прямо на пороге.

Ответьте в течение 12 часов или момент упущен

Инструкция Apple проста: ответьте в течение 12 часов после получения уведомления CONSUMPTION_REQUEST. Это все окно. Запрос на возврат не ждет вашего следующего рабочего дня, а ответ о потреблении, который приходит с опозданием, это ответ, который Apple так и не взвесила. Если вы отвечаете на них вручную, 12-часовые часы, это то, что тихо отказывает первым, по выходным, по праздникам и в 3 часа ночи по вашему часовому поясу. Ответ должен быть автоматизирован, чтобы быть надежным, потому что окну все равно, когда бодрствует ваша команда.

Вы не можете отправить данные, пока клиент не дал согласия

Вот барьер, о который спотыкаются команды. Apple отклоняет запрос Send Consumption Information, у которого значение customerConsented не равно true. Словами Apple: если клиент дал согласие, ответьте, вызвав API и отправив данные о потреблении; если нет, не отвечайте на уведомление CONSUMPTION_REQUEST. Apple также прямо возлагает ответственность на вас: вы должны получить действительное согласие клиента перед передачей его персональных данных, и вы, разработчик, несете единоличную ответственность за его получение. Значит, первый вопрос по каждому запросу не в том, сколько они использовали, а в том, согласился ли этот клиент, чтобы мы рассказали Apple. Нет согласия, нет ответа, и возврат решается на основании всего, кроме вашей версии истории.

Что на самом деле меняет решение Apple о возврате

Если ответ, это рекомендация, честный вопрос в том, насколько сильно она рекомендует. Ответ таков: ваши данные значат больше всего именно там, где человек колебался бы, и меньше всего там, где исход и так не вызывал сомнений.

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

Разработчики сообщают, что отправляют предпочтение отклонить по покупке, которую клиент полностью использовал, и видят, как Apple все равно возвращает за нее деньги. Это не сломанный API. Apple сказала вам, что взвешивает множество факторов, и в любом конкретном запросе некоторые из этих факторов могут перевесить полностью использованную расходуемую покупку: клиент с чистой историей, названная причина, которую Apple считает весомой, небольшая сумма, первый запрос. Ваш ответ давил против возврата. Другие входные параметры давили сильнее. Урок не в том, чтобы перестать отвечать, а в том, чтобы перестать ожидать, что чистая расходуемая покупка всегда уцелеет. Там, где сигнал действительно неоднозначен, статус частичного использования, задокументированная проблема с доставкой и честное предпочтение, это входные параметры, которые могут склонить пограничный случай в вашу пользу.

Сколько стоит рекомендация в деньгах

Возврат, это не цена продажи. Это цена продажи плюс все, что вы уже потратили на ее доставку, а ответ о потреблении затрагивает только первую часть.

К моменту прихода запроса деньги уже потрачены

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

• Цена продажи: ваша чистая выручка после комиссии Apple, отменяемая, если возврат одобрен. Это единственная часть, на которую может повлиять ваш ответ.
• Стоимость доставки: вычисления, вызовы API, хранилище и любая выплата, которую вы уже сделали по покупке. Ушла независимо от решения.
• Время персонала: каждый возврат, обработанный вручную, это минуты чьего-то дня, а 12-часовое окно означает, что эти минуты выпадают на неудобные часы.
• Пропущенная закономерность: клиент, который возвращает снова и снова, это затрата, которую вы видите только если отслеживаете потребление и историю по всем запросам, а не рассматриваете каждый как разовый.

Как Google Play решает тот же вопрос

Apple, это не единственный магазин, который просит вас высказаться, а затем решает сам. Google Play запускает параллельный поток для банковских чарджбэков, и форма та же: вы отправляете доказательства, магазин решает. Различия, в часах и в том, что вам разрешено отправлять.

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

RefundHalt перехватывает CONSUMPTION_REQUEST в момент, когда Apple его отправляет, проверяет согласие, собирает статус потребления, статус доставки и основанное на доказательствах предпочтение по возврату и отвечает в пределах 12-часового окна, при этом никто в вашей команде не следит за часами. То же самое он делает для проверки чарджбэков Google Play в пределах ее 24-часового окна. Вы не можете заставить Apple решить в вашу пользу. Вы можете сделать так, чтобы Apple никогда не решала без вашей версии истории, по каждому возврату, вовремя.