Новости и разборы
Корзина перед оплатой: показывать только подтверждённое состояние
Shopify уточняет результат записи и значение скидки, FastSpring ограничивает покупки по клиенту. Как проверить общий путь checkout.
На экране появилась скидка, но итог заказа остался прежним. Или акция ограничена одной покупкой, а клиент прошёл checkout с другого устройства. Такие ошибки возникают на разных уровнях состояния. Октябрьские изменения Shopify и сентябрьское добавление FastSpring полезно сопоставить перед выпуском правил предложения.
Принятый вызов не всегда означает применённую запись
Shopify 7 октября изменил cart mutations в POS UI extensions API 2026-10: неподтверждённая запись теперь приводит к отказу вызова. Отказ POS означает неизменную корзину, а неизвестный результат допускает частичное изменение и требует перечитать корзину перед повтором. Версии 2026-07 и раньше этим изменением не затронуты.
Для приложения важен понятный переход между намерением и результатом. Сотрудник нажал кнопку, система отправила запрос, затем получила подтверждение или другое состояние. Уведомление «применено» должно опираться на подтверждённую запись. Неизвестный результат нельзя автоматически превращать ни в успех, ни в безопасный повтор.
Тип значения тоже входит в договор
В отдельном обновлении Shopify от 7 октября POS 11.15 исправляет Discount.amount для Percentage: возвращается процент, а не денежная сумма. Поправка относится ко всем версиям API; FixedAmount и Code не меняются. Это другая граница версии, которую нужно проверять отдельно от cart mutations.
Общая связь внутри checkout конкретна: верно применённая скидка и верно прочитанное значение являются двумя необходимыми проверками. Если интерфейс воспринимает процент как деньги, успешная запись не исправляет ошибку отображения или вычисления.
Лимит покупателя шире одной корзины
FastSpring 28 сентября описал Purchase Limits, которые учитывают совокупные покупки одного клиента через заказы, сессии, устройства и способы оплаты. Этот предшествующий материал добавляет ещё один уровень состояния: правило предложения может зависеть от истории покупателя.
Сопоставление не объявляет продукты общей готовой интеграцией. Оно помогает сформулировать проектный вывод: экран checkout должен отражать подтверждённую запись, корректный тип значения и применимую историю клиента. Каждый уровень имеет свой источник факта.
Для приёмки подготовьте пример скидки, повторный запрос и вторую покупку с другого устройства. Проверьте отображение после отказа, неизвестного исхода и повторного чтения. Сравните сумму и процент по типу, а лимит по согласованной идентичности покупателя. Убедитесь, что команда может объяснить клиенту причину ограничения.
Бизнес-правила помогают описать состояния. Проект приложения для аренды даёт контекст клиентского пути без заявления о подключении этих платежей. Для вашего продукта обсудите подтверждения и ограничения checkout.