Есть один эндпоинт, который возвращает всю историю возвратов клиента в App Store, и вот что он выдаёт

Apple ведёт доступный для запросов учёт каждого возврата, который она одобрила по аккаунту клиента для вашего приложения, и один вызов возвращает его. Этот эндпоинт называется Get Refund History, он входит в App Store Server API и выдаёт вам полную историю возвратов этого клиента в App Store в виде списка подписанных транзакций. Вы передаёте идентификатор транзакции, получаете обратно то, что Apple вернула, и сверяете это с тем, что у вас всё ещё включено.

Вот зачем это нужно. Возврат, который вы не видите, это возврат, за который вы продолжаете платить. Деньги уже ушли, но аккаунт остаётся активным, и каждый час, пока это так, вы продолжаете тратить на вычисления, вызовы model API, хранилище и любые выплаты, привязанные к этому клиенту. Ваши уведомления о возвратах должны ловить это в момент, когда оно происходит. Get Refund History это подстраховка на случай, когда они не сработали: после сбоя, деплоя, который потерял вебхук, или обращения в поддержку, где вам нужна вся картина в одном вызове.

Что возвращает эндпоинт истории возвратов в App Store

Вы вызываете GET /inApps/v2/refund/lookup/{transactionId} к App Store Server API, подписав его тем же JWT, что и любой другой вызов к нему. Идентификатор транзакции в пути может быть любой транзакцией этого клиента. Apple читает его как идентичность, а не как фильтр, и возвращает возвращённые покупки этого клиента по всему вашему приложению: расходуемые, нерасходуемые, авто-возобновляемые и невозобновляемые подписки в равной мере. Более старая версия V1 этого эндпоинта возвращала до 50 возвратов в одном ответе и объявлена устаревшей. Текущая версия разбивает выдачу на страницы, поэтому вы обслуживаете клиентов с длинной историей без гигантского ответа.

Ответ состоит из трёх полей

Что говорит вам одна возвращённая транзакция

Каждая запись в signedTransactions это JWS. Проверьте её по цепочке сертификатов Apple, декодируйте, и вы получите обычную полезную нагрузку транзакции с заполненными полями возврата. Здесь важны именно эти поля.

Токен revision это то, как вы перестаёте перечитывать весь список

Наивный способ использовать этот эндпоинт это искать клиента и обходить каждую страницу каждый раз. Это работает, и на клиенте с пятьюдесятью возвратами это пятьдесят строк, которые вы уже знали, плюс одна новая. Токен revision существует, чтобы убрать эту трату. Каждый ответ несёт revision. Когда hasMore истина, вы передаёте его обратно, чтобы получить следующую страницу. Когда вы доходите до конца, вы сохраняете последний revision, который видели.

Чего этот эндпоинт делать не будет

Есть одно ожидание, от которого стоит отказаться, прежде чем строить на нём. Get Refund History работает по клиенту, а не по приложению. Вы не можете запросить у него все возвраты, которые ваше приложение получило на прошлой неделе. Он отвечает на один вопрос, какие возвраты есть у этого аккаунта, и вам нужно прийти с идентификатором транзакции этого аккаунта, чтобы задать его. Разработчики постоянно упираются в эту стену и идут искать эндпоинт возвратов по всему приложению, которого не существует.

Картина по всему приложению живёт в другом месте. Ваша лента App Store Server Notifications отправляет уведомление REFUND в момент, когда Apple одобряет каждый из них, а Get Notification History позволяет воспроизвести эту ленту с фильтром по типам возвратов за диапазон дат. Так что разделение чёткое. Уведомления и их история дают вам поток по всему приложению. Get Refund History даёт вам авторитетный список одного аккаунта по запросу, а это именно то, что вам нужно на стойке поддержки или после сбоя.

Во что вам обходится пропущенный возврат в деньгах

Эндпоинт это трубопровод. Счёт это причина, по которой вы прокладываете трубу. Каждый возврат в этом списке это деньги, уже возвращённые, и единственная переменная, оставшаяся в вашем контроле, это как долго вы продолжаете тратить на аккаунт, который больше не платит.

Вы продолжаете платить за обслуживание возвращённого аккаунта

Цена покупки уходит в тот же миг, когда Apple одобряет возврат. Что продолжает работать, так это стоимость доставки. Для приложения, которое делает реальную работу на пользователя, это вычисления, вызовы model API, хранилище и любая выплата автору или партнёру, привязанная к его использованию. Возвращённый клиент, чей доступ вы так и не отключили, это подписка, которую вы финансируете из своего кармана. Сверка по Get Refund History и отзыв по тому, что вы находите, это то, как вы выключаете этот счётчик, когда уведомление проскользнуло мимо.

Причина возврата 1 это замаскированный отчёт о дефекте

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

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

Чарджбэк окончателен с банком и, на другом сторе, теперь несёт комиссию, которую разработчик оплачивает сам. Возврат в App Store это не то же самое. Он завершён, но право доступа ваше, чтобы отозвать его в момент, когда вы узнаёте. Так что даже возврат, который вы находите с опозданием на дни через этот эндпоинт, стоит найти. Вы не можете вернуть деньги, но можете остановить трату, которая всё ещё шла позади него.

Как это стыкуется с уведомлениями и с Google

Думайте об этих частях как об одной системе. Уведомление REFUND это живой сигнал, отправляемый на ваш сервер по мере того, как Apple принимает решение. Get Refund History это источник истины по запросу для одного клиента, вызов, который вы делаете, когда push не сработал или когда человеку нужен полный аккаунт перед глазами. На стороне Google Play форма та же по идее, но с другими названиями: VoidedPurchaseNotification приходит в реальном времени, а Voided Purchases API это список, который вы вытягиваете. Оба стора дают вам поток и журнал. Ошибка в том, чтобы доверять только потоку, потому что потоки теряют данные.

Как настроить это способом RefundHalt

Цикл маленький, когда каждая часть на месте. Возьмите уведомление REFUND как триггер. Сверьте по Get Refund History, чтобы потерянный вебхук никогда не оставлял возвращённый аккаунт активным. Декодируйте каждую транзакцию, свяжите её по appAccountToken или transactionId назад к вашему пользователю, прочитайте revocationReason, чтобы дефектный возврат был помечен, а не просто подшит, и отзовите именно то право доступа, а не весь аккаунт. Листайте страницы с токеном revision, чтобы читать новые возвраты, а не старые.

Это та часть, которую RefundHalt берёт на себя. Он слушает уведомления о возвратах, откатывается на Get Refund History, когда ему нужен авторитетный список, проверяет каждую подписанную транзакцию, отзывает именно ту покупку и хранит revision, чтобы каждый проход читал только то, что изменилось. Вы получаете отключение доступа за секунды и чистую запись о том, кому оформлен возврат, за что и почему, без того чтобы поднимать опрос и проверку JWS самостоятельно.