Кожен запит на повернення від Apple тепер має причину, а consumptionRequestReason це те, як її прочитати
Від WWDC24 кожен запит Apple CONSUMPTION_REQUEST несе consumptionRequestReason, тобто зазначену самим клієнтом причину бажання отримати повернення. Є п'ять значень, від UNINTENDED_PURCHASE до LEGAL, і кожне має змінювати те, що ви надсилаєте у відповідь у своєму вікні 12 годин. Ось як прочитати кожне з них.
Головне
- Від App Store Server Notifications версії 2.11, оголошеної на WWDC24, кожне сповіщення CONSUMPTION_REQUEST містить consumptionRequestReason, рядок, який зазначає, чому клієнт попросив повернення.
- Є рівно п'ять значень: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL та OTHER. Apple надсилає одне на запит.
- Причина не вирішує повернення. Це контекст, який ви використовуєте, щоб обрати свій refundPreference і дані про споживання, перш ніж закриється вікно 12 годин.
- CONSUMPTION_REQUEST тепер спрацьовує також для автоматично поновлюваних підписок, не лише для витратних товарів, тож consumptionRequestReason досягає значно більшої частини ваших повернень, ніж до WWDC24.
- Причина FULFILLMENT_ISSUE це сигнал, що ваша власна доставка могла зазнати збою. Її оскарження спалює вікно й запрошує пізніший зворотний платіж. Її надання зазвичай є дешевшою відповіддю.
- Ви відповідаєте, викликавши Send Consumption Information протягом 12 годин з customerConsented, встановленим на true, і refundPreference зі значенням GRANT_FULL, GRANT_PRORATED або DECLINE. Apple розглядає вашу перевагу як один із вхідних даних, а не як команду.
- Повернення все одно коштує вам обчислень, викликів API, сховища та виплат, які покупка вже спожила. Поле причини це те, як ви витрачаєте свій захист лише на випадки, варті захисту.
Apple змінила те, як запити на повернення потрапляють на ваш сервер, і багато розробників цього так і не помітили. Від оновлення App Store Server Notifications 2.11, оголошеного на WWDC24, кожне сповіщення CONSUMPTION_REQUEST несе поле під назвою consumptionRequestReason. Це зазначена самим клієнтом причина, чому він хоче повернути свої гроші. Один простий рядок, п'ять можливих значень, доставлений у тому самому вантажі, на який ви й так маєте дванадцять годин, щоб відповісти.
Причина запиту на повернення від Apple сама по собі нічого не вирішує. Що вона робить, це каже вам, у якій із п'яти дуже різних ситуацій ви перебуваєте, аби ви перестали надсилати ті самі загальні дані про споживання і на повернення, яке варто надати, і на повернення, яке варто оскаржити. Ось що це за поле, точні значення, які може надіслати Apple, що сигналізує кожне з них і як воно має змінити перевагу та докази, які ви надсилаєте у відповідь.
Що насправді таке consumptionRequestReason
consumptionRequestReason це поле-рядок в об'єкті data сповіщення CONSUMPTION_REQUEST. Apple додала його в App Store Server Notifications версії 2.11, разом зі змінами WWDC24 у процесі повернення. До цього запит приходив із підписаною транзакцією і нічим щодо мотиву. Ви відповідали наосліп. Тепер зазначена клієнтом причина подорожує разом із запитом.
Прочитайте слово зазначена уважно. Це причина, яку клієнт обрав, коли подавав звернення до Apple, а не факт, перевірений Apple. UNINTENDED_PURCHASE не доводить, що покупка залишилася невикористаною, а UNSATISFIED_WITH_PURCHASE не доводить, що продукт був несправним. Значення це лінза, а не вирок. Ви все одно поєднуєте його з власними записами про доставку та використання.
Воно їде у сповіщенні, яке ви й так обробляєте
CONSUMPTION_REQUEST це єдиний процес Apple, який взагалі просить у розробника докази. Його відповідником у Google Play є перегляд зворотного платежу через orders.reviewrefund. Коли такий приходить, ви маєте 12 годин, щоб відповісти, викликавши Send Consumption Information, тобто PUT до кінцевої точки споживання транзакції. consumptionRequestReason тепер є частиною того самого сповіщення, тож немає нічого нового, на що підписуватися. Якщо ви вже парсите CONSUMPTION_REQUEST, причина це одне поле, яке ви, ймовірно, ігнорували.
П'ять причин і що кожна з них вам каже
Apple документує рівно п'ять значень. Одне приходить на запит. Ось повний набір і як прочитати кожне на практиці.
| Значення | Що зазначив клієнт | Що це зазвичай означає для вас |
|---|---|---|
| UNINTENDED_PURCHASE | Він не мав наміру це купувати | Часто випадковий або родинний дотик. Перевірте доставку та споживання, перш ніж вирішувати. |
| FULFILLMENT_ISSUE | Він не зміг це отримати чи використати | Вказує назад на вашу власну доставку. Перевірте свої логи, перш ніж оскаржувати. |
| UNSATISFIED_WITH_PURCHASE | Він був цим незадоволений | Каяття покупця. Ваші докази споживання мають тут найбільшу вагу. |
| LEGAL | Він послався на юридичну причину | Розглядайте це як надання. Оскарження юридичного запиту не варте вікна. |
| OTHER | Будь-яка причина, не наведена вище | Сама по собі без сигналу. Поверніться до своїх даних про доставку та використання. |
UNINTENDED_PURCHASE це кошик випадкових дотиків
Це причина, яку обирає батько після того, як дитина купила 10,000 монет, або дорослий, який помилково натиснув підтвердження. Вона корелює з покупками, які ніколи не відкривали й не використовували. Саме тому ваші власні дані мають значення. Якщо ваші записи показують, що витратний товар був повністю доставлений і активно спожитий, заява про ненавмисну покупку і повністю витрачений баланс не узгоджуються, і цю розбіжність варто повідомити через consumptionPercentage.
FULFILLMENT_ISSUE вказує назад на вас
FULFILLMENT_ISSUE це єдина причина, яка частково стосується вашого застосунку, а не клієнта. Вона означає, що клієнт каже, ніби не зміг отримати чи використати те, за що заплатив. Перш ніж рефлекторно оскаржувати, підніміть свої логи доставки. Якщо ваш власний сервер показує, що право доступу так і не активувалося або кредити так і не були зараховані, клієнт має рацію, а DECLINE це неправильна перевага. Боротьба зі справжнім збоєм доставки марнує вікно й може підштовхнути клієнта до його банку, де зворотний платіж коштує більше, ніж коштувало б повернення.
UNSATISFIED_WITH_PURCHASE це те, де вирішують докази
Це звичайне каяття покупця, і це причина, за якої ваші дані про споживання виконують найбільше роботи. Продукт працював. Клієнт використав частину чи все і тепер хоче повернути гроші. Висока consumptionPercentage, чесний deliveryStatus зі значенням DELIVERED і refundPreference зі значенням DECLINE або GRANT_PRORATED це справа, яку Apple просить вас побудувати. Надішліть цифри, а не аргумент.
LEGAL та OTHER
LEGAL означає, що клієнт скористався юридичним або регуляторним правом. Розсудливі люди не погоджуються між собою, але за правилом це не вікно для судових суперечок. Надайте й рухайтеся далі. OTHER це збірна категорія, яку Apple використовує, коли зазначена причина не відповідає жодній із чотирьох вище. Сама по собі вона не несе сигналу, тож розглядайте OTHER точно так само, як розглядали б запит зовсім без причини: починайте зі статусу доставки та доказів використання.
Як причина змінює вашу відповідь, поле за полем
Ви відповідаєте на CONSUMPTION_REQUEST, викликавши Send Consumption Information з тілом ConsumptionRequest. Причина має сформувати три поля в цьому тілі.
customerConsented має бути true
Apple приймає подання лише тоді, коли customerConsented дорівнює true, тобто клієнт погодився поділитися даними про споживання. Якщо ви не маєте цієї згоди, ви взагалі не можете надіслати дані, незалежно від причини. Немає згоди, немає доказів, і запит вирішується без ваших цифр.
deliveryStatus і consumptionPercentage несуть факти
deliveryStatus каже, чи доставили ви робочу покупку. Якщо це щось інше, ніж DELIVERED, Apple вимагає, щоб consumptionPercentage дорівнювало 0. Коли ви таки доставили, consumptionPercentage це ціле число в milliunits від 0 до 100,000, де 100,000 означає, що клієнт використав усю покупку. Ця пара це ваша фактична основа, і саме вона має нести справу FULFILLMENT_ISSUE чи UNSATISFIED_WITH_PURCHASE, а не сама причина.
refundPreference це ваш єдиний важіль
refundPreference це те, де ви зазначаєте, чого хочете. Apple документує три значення: GRANT_FULL, GRANT_PRORATED і DECLINE. Прочитайте причину, зважте її проти своїх даних, а потім оберіть. FULFILLMENT_ISSUE з невдалою доставкою у ваших логах схиляється до GRANT_FULL. UNSATISFIED_WITH_PURCHASE на повністю спожитому продукті схиляється до DECLINE або GRANT_PRORATED. LEGAL схиляється до GRANT_FULL.
Скільки насправді коштує вам повернення
Поле причини має значення, бо повернення рідко є лише продажем, що зникає з вашої книги обліку. За витратний товар, який уже вичерпався, ви заплатили, щоб його виконати. Пакет кредитів, який викликав платний API інференції, партія згенерованих зображень, яка спалила час GPU, збережений експорт, що лежить на вашому рахунку за сховище, виплата творцю, яку ви вже надіслали: ці витрати залишаються витраченими, коли покупку скасовують. Магазин повертає клієнту його гроші. Він не повертає вам ваші обчислення.
Ось чому причину варто прочитати. Скажімо, клієнт купив 5,000 кредитів, кожен із яких запускає платний виклик API, витратив 4,000 із них, а потім подав звернення під UNSATISFIED_WITH_PURCHASE. Ваш deliveryStatus це DELIVERED, ваша consumptionPercentage це 80,000 milliunits, а перевага DECLINE або GRANT_PRORATED це різниця між тим, щоб проковтнути рахунок за API, і тим, щоб повернути його більшу частину. Тепер переверніть причину на FULFILLMENT_ISSUE з логами, що показують, що кредити так і не були зараховані, і чесним, дешевшим кроком є GRANT_FULL, перш ніж клієнт ескалює до свого банку.
Читання причини без надмірної реакції
Пастка полягає в тому, щоб розглядати причину як доказ. UNINTENDED_PURCHASE це не зізнання, що продукт залишився невикористаним, а LEGAL не завжди є справжньою юридичною претензією. Причина звужує ситуацію. Ваші логи доставки та записи споживання її вирішують. Коли вони узгоджуються з клієнтом, надавайте рано й дешево. Коли вони суперечать клієнту, ця суперечність, виражена як deliveryStatus і consumptionPercentage, це найсильніше, що ви можете надіслати. RefundHalt читає consumptionRequestReason при кожному CONSUMPTION_REQUEST і автоматично поєднує його з вашими реальними даними про використання, тож кожна причина отримує відповідь, на яку заслуговує, у вікні 12 годин.
Зміна невелика й легко пропускається, але вона зсунула розмову про повернення на вашу користь. Apple тепер каже вам чому, перш ніж ви відповісте. Скористайтеся цим.
Поширені запитання
- Що таке consumptionRequestReason?
- consumptionRequestReason це поле-рядок, яке Apple включає в кожне сповіщення CONSUMPTION_REQUEST, додане в App Store Server Notifications версії 2.11 на WWDC24. Воно зазначає зазначену самим клієнтом причину запиту на повернення, даючи вам контекст, перш ніж ви відповісте даними про споживання у вікні 12 годин.
- Які можливі значення consumptionRequestReason?
- Їх п'ять: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL та OTHER. Apple надсилає рівно одне на запит про повернення. Кожне вказує на іншу ситуацію, від випадкового дотику до зазначеної юридичної причини, і кожне має сформувати refundPreference і дані про споживання, які ви надсилаєте у відповідь.
- Чи причина повернення вирішує, чи залишу я гроші?
- Ні. consumptionRequestReason це контекст, а не вирок. Apple усе одно вирішує повернення, зважуючи ваш refundPreference, ваш deliveryStatus і consumptionPercentage, а також історію клієнта. Причина каже вам, яку справу будувати. Ваші дані про доставку та використання це те, що її будує.
- Скільки часу я маю, щоб відповісти на CONSUMPTION_REQUEST?
- Ви маєте 12 годин від отримання сповіщення CONSUMPTION_REQUEST, щоб викликати Send Consumption Information. Виклик має встановити customerConsented на true, інакше Apple його відхилить. Пропустите вікно, і повернення буде вирішено без жодних ваших даних.
- Чи з'являється consumptionRequestReason при поверненнях за підписки?
- Так. Те саме оновлення WWDC24, яке додало consumptionRequestReason, також почало надсилати CONSUMPTION_REQUEST для автоматично поновлюваних підписок, не лише для витратних товарів. Для більшості застосунків це означає, що поле причини тепер досягає фінансово найважливіших повернень.
Джерела та додаткове читання
RefundHalt
Автопілот повернень для App Store і Google Play
Читайте далі
Перевірка зворотного платежу в Google Play дає тобі 24 години на захист, ось що надіслати
Коли банк повертає платіж у Google Play, Google надсилає на твій сервер PendingRefundReviewNotification і запускає 24-годинний таймер. Відповідай через API ReviewRefund з перевагою щодо повернення та реальним доказом споживання, інакше спір вирішать без тебе. Ось увесь процес, поле за полем.
Прикріплюйте appAccountToken до кожної покупки в App Store, інакше ви не зможете захистити повернення
Apple надсилає вашому серверу CONSUMPTION_REQUEST, коли клієнт просить повернення, але в транзакції немає даних про те, хто він. appAccountToken це UUID, який пов'язує покупку з вашим користувачем. Встановіть його, і ви зможете відповісти Apple реальними даними. Пропустіть, і вам залишиться лише гадати.