Новости и разборы
Изменение заказа и возврат: как связать запрос клиента с правилами магазина
Запросы изменения заказа и правила возврата Shopify: статусы, рынки, права API и проверка результата между кабинетом, складом и оплатой.
После покупки клиент просит убрать одну позицию. Служба поддержки видит сообщение, склад уже готовит отправление, а личный кабинет продолжает показывать прежний состав заказа. Если запрос сразу назвать «изменением заказа», покупатель может решить, что товар исключён и деньги уже пересчитаны, хотя магазин ещё ничего не выполнил.
Shopify добавил в API 2026-10 два разных набора возможностей: запросы покупателя на изменение заказа и чтение профилей правил возврата. Их объединяет необходимость согласовать клиентский интерфейс с внутренними действиями магазина. Но наличие правил возврата само по себе не разрешает изменение заказа, а регистрация запроса не означает, что изменение уже применено.
Запрос покупателя получает собственную запись
В анонсе buyer-requested order edits Shopify описывает запрос на удаление ещё не исполненных позиций заказа. Объект RequestedOrderEdit содержит статус, желаемые изменения и временные отметки. В GraphQL Admin API появились операции создания запроса, отметки ручного разрешения и отклонения; в Customer Account API покупатель может подать запрос через orderRequestEdit.
Это не универсальный механизм произвольного редактирования любой покупки. В описанной возможности речь идёт об удалении unfulfilled line items. Возвращать уже доставленный товар, менять адрес или добавлять позиции — другие сценарии, доступность которых нельзя выводить из этого анонса.
Shopify также описывает предварительный финансовый расчёт через requestedOrderEditCalculate. Такой расчёт полезен для объяснения ожидаемого результата, но интерфейсу следует отличать предварительную сумму от выполненной финансовой операции. Кнопка «Отправить запрос» должна сообщать, что произойдёт сейчас и когда магазин даст окончательный ответ.
Отделить принятую просьбу от исполненного изменения
Практическая схема магазина может иметь четыре состояния: просьба зарегистрирована, решение готовится, изменение подтверждено, запрос отклонён. Это проектная рекомендация; конкретное сопоставление со статусами API нужно сделать по документации используемой версии.
На каждом переходе определите владельца. Поддержка уточняет намерение покупателя, склад проверяет возможность остановить комплектование, уполномоченный сотрудник или приложение принимает решение. Состояние запроса нельзя использовать вместо фактического состояния заказа. Отметка ручного разрешения должна отражать выполненное действие, а не служить способом скрыть необработанную задачу.
В проектировании клиентских продуктов интерфейс рассматривается вместе с операционной системой. Здесь это особенно наглядно: полезный кабинет показывает не только форму просьбы, но и её текущий статус, срок ответа и причину отказа.
Новый поток стоит проверить на одновременное событие: покупатель отправляет запрос, а склад завершает подготовку. Нельзя обещать остановку отправления только потому, что API умеет хранить запрос. Нужны согласованные правила с системой исполнения и подтверждение того, что изменённые количества дошли до нужных участников.
Правила возврата относятся к другому решению
В отдельном анонсе return policy profiles Shopify описывает чтение структурированных правил для рынков в GraphQL Admin API версии 2026-10. Профиль содержит набор правил, а рынки ссылаются на него. Изменение общего профиля влияет на все связанные с ним рынки.
Самим профилям этот API не предоставляет mutations создания, изменения или удаления: их редактируют в Shopify admin. Через API можно читать профиль и управлять его привязкой к рынку. Для чтения требуется read_legal_policies, для изменения привязки — write_markets. Полномочия на запросы изменения заказа отдельно относятся к read_orders и write_orders; объединять эти доступы по сходству названий нельзя.
Для бизнеса это означает, что правила нужно учитывать как самостоятельный источник решения. Если товар уже получен и клиент просит возврат, сначала определяются рынок и применимые условия, затем отдельный процесс обработки. Профиль возврата не является автоматически выданным разрешением на предыдущее изменение неисполненного заказа.
Почему null требует внимательного разбора
Shopify уточняет: Market.returnPolicyProfile возвращает непосредственно назначенный профиль и не разрешает иерархию рынков. Значение null здесь означает отсутствие прямого назначения, а не отсутствие любых применимых условий. В анонсе также описан профиль по умолчанию для рынков без назначенного именованного профиля.
При этом null в returnRules или editRules имеет другой смысл: соответствующие ограничения выключены. В частности, источник объясняет отсутствие ограничений возврата при returnRules: null. Нельзя переносить такое толкование на любое nullable-поле или на законодательные обязательства магазина.
Сохраните вместе с решением идентификатор применённого профиля, релевантные условия и время проверки. Агрегированное поле updatedAt, по описанию Shopify, меняется при изменении частей профиля. Если общий профиль обновили между обращением и решением, сотруднику нужны понятные правила повторной проверки. Правовую оценку условий следует проводить отдельно от технического чтения API.
Согласовать заказ, остатки и деньги
После подтверждённого изменения требуется проверить три независимых результата: состав заказа, складское действие и финансовое отражение. Исключённая позиция не должна оставаться в задании на сборку; освобождение резерва не должно происходить дважды; интерфейс должен показывать подтверждённую сумму.
Описание складского учёта в Google Sheets полезно как контекст движения остатков и ответственности за исправления. Оно не подтверждает применение новых Shopify API. Для конкретного магазина связь заказа и склада придётся проектировать по его текущим правилам и ограничениям.
На границе систем нужны устойчивые идентификаторы заказа и запроса, явные ошибки и восстановление после частичного выполнения. Эти вопросы разобраны в подходе к API-интеграциям. Финансовую часть стоит дополнить сверкой платежей: сообщение об изменении заказа не доказывает, что денежное состояние уже согласовано.
Как выбрать первый этап
Начните с одного типа запроса и ограниченного участка исполнения. Проверьте незавершённый заказ, уже исполненную позицию, отклонение, изменение правил и расхождение между магазином и складом. Критерий приёмки — одинаковое понимание результата покупателем и сотрудниками.
Отдельно оцените трение в мобильной покупке: ясное описание последующих действий важно и после оплаты. Когда покупатель видит подтверждённое состояние, а команда знает следующий шаг, API становится частью полезного сервиса, а не ещё одной формой, за которой скрыта ручная переписка.