Apple Send Consumption Information тепер запитує п'ять полів, а не дванадцять, і ось кожне з них

Перелік фактів, які Apple запитує у вас, коли клієнт хоче повернення коштів, значно скоротився. Корисне навантаження Send Consumption Information, єдина відповідь, яку розробник може подати в рішення про повернення коштів у App Store, раніше мало дванадцять полів. Тепер воно має п'ять. Apple скоротило його приблизно під час WWDC24 і згорнуло більшість старих запитань про профілювання облікового запису у два прості запитання та одне число. Менше полів це не дрібна правка. Це змінює, які докази Apple зважує, і змінює, у яких полях ви не можете дозволити собі помилку.

Ось чому це заслуговує на вашу увагу, а не є просто нотаткою про схему. Це корисне навантаження це єдиний момент у поверненні коштів Apple, коли ваша версія історії доходить до рішення. Повернення за витратну покупку скасовує дохід, на доставку якого ви вже витратили реальні гроші, а п'ять полів це те, як ви повідомляєте Apple, що продукт було доставлено та використано. Пропустите 12-годинне вікно чи заповните поле неправильно, і Apple вирішить лише на підставі претензії клієнта.

Що таке Send Consumption Information

Send Consumption Information це кінцева точка App Store Server API, яку ви викликаєте після того, як Apple надішле на ваш сервер сповіщення CONSUMPTION_REQUEST. Це сповіщення означає, що клієнт попросив Apple про повернення коштів за покупку в застосунку, і Apple хоче вашого внеску, перш ніж вирішити. Ви відповідаєте, надсилаючи невелике тіло JSON, ConsumptionRequest, методом PUT до кінцевої точки. Apple його читає, зважує щодо історії клієнта та ухвалює рішення. Ви ніколи не вирішуєте про повернення коштів. Ви надаєте факти.

Тіло це весь інтерфейс. Немає окремої форми, немає оскарження і немає другого подання, яке зараховується. Хоч би що ви надіслали в цьому єдиному корисному навантаженні, це вся ваша справа, тож значення кожного поля важить більше, ніж припускає кількість полів.

П'ять полів, які Apple тепер запитує

Поточний ConsumptionRequest має п'ять членів. Три обов'язкові, а два необов'язкові. Усе, про що Apple раніше запитувало щодо облікового запису клієнта, його стаж, його сукупні витрати, його сукупні повернення, його час гри, вилучено з того, що ви надсилаєте.

customerConsented це шлагбаум

customerConsented це Boolean, і це поле, яке вирішує, чи надсилаєте ви взагалі щось. Воно фіксує, чи клієнт погодився, щоб ви поділилися з Apple даними про споживання. Настанова Apple пряма: якщо клієнт не дав згоди, не надсилайте інформацію про споживання. Тож це не поле, яке ви перемикаєте на true, щоб посилити свою справу. Воно відображає справжнє так чи ні, яке ви вже маєте мати, а false тут означає, що решту корисного навантаження надсилати не слід.

deliveryStatus це поле, яке рухає повернення коштів

deliveryStatus це рядковий енум, і це найсильніший важіль, який ви маєте. Воно повідомляє Apple, чи ваш застосунок насправді доставив робочу покупку в застосунку. Одне значення каже так. Інші чотири кажуть ні, кожне з іншої причини, і кожне повідомляє Apple, що клієнт має законну скаргу.

sampleContentProvided відповідає на питання справедливості

sampleContentProvided це Boolean. Воно фіксує, чи ви дали клієнту безкоштовний зразок, пробну версію або чітку інформацію про те, що робить покупка, перш ніж він купив. True тут це невеликий сигнал справедливості: клієнт мав змогу знати, що купує. Само собою воно нічого не вирішує, але це одне з лише трьох обов'язкових полів, тож Apple явно хоче мати його в кожній відповіді.

consumptionPercentage тепер число, а не статус

Це поле, яке змінилося найбільше. Старе корисне навантаження мало consumptionStatus, чотириступеневий енум: UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. Нове корисне навантаження замінює його на consumptionPercentage, ціле число, виміряне в milliunits. 100,000 milliunits означає, що елемент повністю спожито, тож 50,000 це половина, а 0 це недоторкане. Точне число перевершує поділ на чотири кошики, бо дає змогу сказати, що клієнт витратив 90 відсотків пакета кредитів, замість округлення вниз до частково спожитого.

Одне застереження, на якому люди спотикаються. Для автоматично поновлюваних підписок Apple саме визначає споживання з часу, що минув, тож consumptionPercentage призначене для витратних та непоновлюваних покупок. Надсилайте його там, де воно застосовне, і дайте Apple вивести його там, де ні.

refundPreference виражає перевагу, а не вирок

refundPreference це необов'язковий рядок, і саме тут ви повідомляєте Apple, який результат ви б воліли. Воно теж змінило форму. Старе поле було числом зі значеннями на кшталт prefer-grant, prefer-decline та no-preference. Нове це іменований рядок із трьома значеннями.

Що Apple прибрало і чому це має значення

Старий ConsumptionRequest мав дванадцять полів. Сім із них зникли з того, що ви надсилаєте. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform та appAccountToken були профілювальною половиною корисного навантаження, полями, які просили вас розподілити клієнта за тим, як довго він мав обліковий запис, скільки витратив, скільки йому повернули та як довго він користувався застосунком.

Apple вирізало їх з причини, вартої уваги. Ці поля просили розробників передати профіль клієнта, і більшість розробників або лишали їх незадекларованими, або вгадували. П'ять, що лишилися, стосуються покупки та доставки, фактів, які ви справді можете перевірити з власних систем. Зсув іде від того, ким є клієнт, до того, що сталося з цією конкретною покупкою.

Кінцева точка і годинник

Ви надсилаєте корисне навантаження методом HTTP PUT до кінцевої точки Send Consumption Information, адресованої за ідентифікатором транзакції спірної покупки: PUT /inApps/v1/transactions/consumption/{transactionId}. Успіх повертає 202 Accepted, а тіло відповіді порожнє. Ця порожня відповідь очікувана, а не помилка. Вона підтверджує, що Apple поставило ваші дані в чергу, і нічого не каже вам про кінцевий результат, який надходить пізніше як сповіщення REFUND або REFUND_DECLINED.

Годинник це частина, яку ви не можете розтягнути. Apple дає вам 12 годин від CONSUMPTION_REQUEST на відповідь. Використовується лише ваша перша відповідь, тож перше корисне навантаження має бути повним і правильним. Apple може надіслати CONSUMPTION_REQUEST більш ніж один раз для тієї самої покупки, але термін кожного фіксований, а ручний розгляд рідко вкладається в 12 годин через часові пояси та вихідні.

У що вам обходиться неправильно оброблене поле

Гроші покинули будівлю раніше, ніж повернення коштів

Повернення за витратну покупку не є чистим скасуванням. На той час, коли клієнт просить свої гроші назад за пакет кредитів чи партію генерацій ШІ, ви вже витратилися на доставку: інференс GPU на кожен запит, виклики API сторонніх моделей, що тарифікуються за токен, сховище для того, що ви створили, і будь-яка виплата авторові чи партнеру, прив'язана до цього використання. Ціна з магазину повертається клієнту. Ваші витрати на доставку до вас не повертаються. Тож повернення, яке ви могли б оскаржити, не є подією без прибутку та збитку, це чистий збиток усього, що ви заплатили, щоб обслужити обліковий запис.

П'ять полів це те, як ви уникаєте платити двічі

deliveryStatus, встановлене на DELIVERED, і високе consumptionPercentage це два факти, які повідомляють Apple, що клієнт отримав і використав продукт. Вони є вашим доказом того, що обчислення, виклики API та сховище зробили свою роботу. Лишіть корисне навантаження ненадісланим, і Apple ніколи цього не почує. Воно вирішує з претензії клієнта, повернення ймовірніше пройде, а ви покриваєте і скасований дохід, і витрати на доставку за ним.

Зворотні платежі це гірші двері, а мовчання вказує на них

Клієнт, який не може досягти задоволення через процес повернення коштів Apple, усе ще може оскаржити списання у своєму банку. Зворотний платіж за карткою остаточний, він несе фіксовану комісію за спір і забирає рішення з рук Apple та ваших. Гарна відповідь на CONSUMPTION_REQUEST утримує спір усередині системи Apple, де ви маєте голос. Його ігнорування штовхає межові випадки до єдиного каналу, де голосу ви не маєте.

Як із цим справляється RefundHalt

П'ять полів здаються простими, доки вам не доведеться заповнити їх правильно, протягом 12 годин, на кожен CONSUMPTION_REQUEST, прив'язаних до правильної транзакції. RefundHalt перехоплює сповіщення, читає ваші власні записи про доставку та використання для цієї покупки і надсилає корисне навантаження автоматично, перш ніж вікно закриється. deliveryStatus відображає те, що насправді показують ваші журнали, consumptionPercentage походить із реального використання, а не з здогаду, а refundPreference слідує політиці, яку ви налаштовуєте один раз. Ви отримуєте оскаржуване повернення, розглянуте з доказами, а не пропущений термін і рішення, ухвалене без вас.