Три уведомления App Store о возврате приходят после решения Apple, а REFUND_REVERSED возвращает продажу вам

Apple принимает решение о вашем возврате, а затем продолжает говорить. Как только результат определён, App Store отправляет вашему серверу одно из трёх уведомлений о возврате, и каждое требует своего действия. REFUND говорит, что деньги ушли и вам следует убрать доступ. REFUND_DECLINED говорит, что клиент проиграл запрос и вы сохраняете продажу. REFUND_REVERSED говорит, что Apple отменила ранее предоставленный возврат, так что продажа снова ваша и вам нужно вернуть всё, что вы отняли. Большинство приложений подключают первое и тихо игнорируют остальные два. Именно так платящий клиент оказывается заблокированным от того, за что он заплатил.

Эти три отличаются от CONSUMPTION_REQUEST, единственного сообщения о возврате, которое просит вас ответить. Уведомления после решения не хотят спора. Им нужен HTTP 200 и правильное изменение доступа клиента. Вот что означает каждое из них, точные поля, которые несут факты, и где утекают деньги, когда вы обрабатываете их неправильно.

Четыре уведомления о возврате, и какое из них хочет ответа

App Store Server Notifications V2, это единый поток. Вы направляете его на один URL, и Apple отправляет туда каждый тип уведомления, так что вы уже получаете все четыре сообщения о возврате, обрабатываете вы их или нет. Четыре типа касаются возвратов, и только один из них является вопросом.

Что на самом деле сообщает уведомление REFUND

REFUND срабатывает, когда App Store успешно вернул деньги за транзакцию клиенту. Оно применяется к любому типу покупки: расходуемой, нерасходуемой, автообновляемой подписке и необновляемой подписке. Подписанная транзакция внутри уведомления теперь несёт два поля, которых не было до возврата, и эти два поля, это вся суть.

revocationDate и revocationReason несут факты

revocationDate, это время UNIX в миллисекундах, когда App Store вернул деньги за транзакцию или отозвал её. revocationReason сообщает вам категорию возврата и принимает ровно два значения.

Наличие revocationDate у транзакции само по себе является флагом. Если вы позже запросите транзакцию и у неё есть revocationDate, эта покупка была возвращена, с уведомлением или без. Читайте причину рядом с ней, чтобы волна возвратов со значением 1 на одном релизе не проскользнула мимо вас как шум.

Отзывайте по транзакции, а не по продукту

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

REFUND_DECLINED означает, что вы уже выиграли, так что не отменяйте это

REFUND_DECLINED приходит, когда App Store отклонил запрос клиента на возврат. Клиент попросил, Apple сказала нет, и вы сохраняете продажу. На первый взгляд делать нечего, и в этом суть. Ошибка, которую обнажает это уведомление, другая: ранний отзыв доступа.

Если ваш код реагирует на CONSUMPTION_REQUEST, убирая доступ клиента до того, как Apple вынесет решение, REFUND_DECLINED, это момент, когда это решение взрывается. Apple оставила ваши деньги, а вы заблокировали клиента, чей возврат был отклонён. Теперь этот клиент платит за продукт, которым не может пользоваться, открывает обращение в поддержку и запоминает это. Исправление, это правило, а не функция: отзывайте по REFUND, никогда по запросу. REFUND_DECLINED, это просто подтверждение Apple, что ранний отзыв был бы неверным решением.

REFUND_REVERSED, это уведомление, которое возвращает вам деньги

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

Проблема недель спустя

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

Где здесь деньги, если сделать всё правильно

Каждое из этих уведомлений соответствует реальному числу, и цена неправильной обработки, это не только цена продажи.

REFUND: перестаньте платить за обслуживание клиента, которому вернули деньги

Цена продажи потеряна в момент, когда приходит REFUND. Что вы всё ещё можете контролировать, это стоимость продолжения обслуживания. Каждый час, что возвращённое право доступа остаётся активным, вы продолжаете тратить на то, за что клиент больше не платит: вычисления, вызовы API моделей, хранилище и любые выплаты авторам или партнёрам, привязанные к его использованию. Своевременный отзыв по REFUND останавливает этот счётчик. Игнорирование уведомления означает, что вы финансируете продукт для того, с кем магазин уже рассчитался.

REFUND_DECLINED: не превращайте выигрыш в возврат доброй воли

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

REFUND_REVERSED: худшее сочетание, это когда потеряны и их деньги, и их доступ

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

Что нужно подключить

Обработка невелика, когда модель верна. Привязывайте права доступа к идентификатору транзакции, чтобы каждое уведомление указывало на одну покупку. На CONSUMPTION_REQUEST отправляйте свои данные в течение 12 часов. На REFUND отзывайте эту транзакцию. На REFUND_DECLINED не делайте ничего. На REFUND_REVERSED восстанавливайте. Быстро возвращайте HTTP 200 на все из них и делайте изменение доступа в своё время.

Для разрыва, который оставляют уведомления, используйте эндпоинт Get Refund History. Если ваш сервер был недоступен во время сбоя и пропустил REFUND, вызовите поиск возвратов App Store Server API по идентификатору транзакции по адресу /inApps/v2/refund/lookup/{transactionId} и прочитайте подписанные транзакции с их revocationDate и revocationReason. Он сверяет по одной транзакции за раз и постранично проходит по возвращённым покупкам клиента, так что пропущенный вебхук не становится навсегда неправильно установленным правом доступа.

Это та часть, которую RefundHalt выполняет за вас. Он слушает все четыре типа, отзывает по REFUND, оставляет доступ нетронутым по REFUND_DECLINED и автоматически восстанавливает по REFUND_REVERSED, каждый привязанный к точной транзакции. Отменённый возврат не лежит в очереди, пока платящий клиент остаётся заблокированным, а отклонённый никогда не запускает отзыв, который пришлось бы откатывать.