Для обеспечения возможности оформления заказа пользователями необходимо реализовать интеграцию с функцией Native Checkout. Это включает в себя создание стандартного REST API, который позволяет Google программно управлять процессом оформления заказа с вашими серверами. Этот метод обеспечивает наиболее удобный для пользователей интерфейс. Первоначально Google будет отображать пользовательский интерфейс для покупателя, а в будущем планируется поддержка более гибкого взаимодействия.
Процесс оформления заказа
Для интеграции с нативными сервисами вам потребуется создать RESTful API, который Google сможет вызывать для создания и управления сессиями оформления заказа.
Общий ход событий выглядит следующим образом:
- Создание сессии оформления заказа: пользователь и, при необходимости, агент находятся в цикле, добавляя товары в сессию.
- Передача управления пользовательскому интерфейсу Google: Как только пользователь решит оформить заказ, агент (если он задействован) передает управление пользовательскому интерфейсу Google (передавая данные сессии оформления заказа).
- Ручная оплата: Теперь пользователь взаимодействует только с пользовательским интерфейсом Google для заполнения конфиденциальных данных о доставке и оплате, а также для отправки заказа. Агент не участвует в этой части, что обеспечивает детерминированность.
- Завершение и возврат: В пользовательском интерфейсе Google отображается страница «Спасибо» для подтверждения заказа. При желании пользователь может быть перенаправлен обратно к агенту, который, возможно, уже был уведомлен о завершении покупки.
Жизненный цикл статуса сессии оформления заказа
По мере продвижения пользователя по процессу оформления заказа необходимо обновлять status сессии оформления заказа, чтобы он отражал ее текущее состояние. Сессия проходит следующий жизненный цикл:
-
incomplete: Начальное состояние при создании сессии. Это указывает на то, что обязательная информация (например, способы доставки, налоги или данные пользователя) отсутствует или не рассчитана. -
ready_for_payment: Статус, который следует использовать после того, как пользователь обновит свой адрес доставки и вы рассчитаете варианты доставки и общую сумму, но до завершения обработки платежного инструмента. -
ready_for_complete: Статус, используемый во время полной загрузки объекта оформления заказа, после выбора способа оплаты и проверки всех данных заказа. -
completed: Окончательный статус, возвращаемый после успешной обработки платежа и оформления заказа. -
canceled: статус, возвращаемый в случае прерывания сеанса оформления заказа. -
error: Статус, возвращаемый в случае неустранимой ошибки бизнес-логики, препятствующей оформлению заказа. Этот статус доступен в версии UCP2026-04-08и более поздних версиях.
Процесс оформления заказа на несколько товаров:
Теперь Google поддерживает размещение нескольких отдельных позиций в одном заказе. Общий процесс выглядит следующим образом:
- Пользователь инициирует оформление заказа через интерфейс с поддержкой UCP (например, нажав кнопку «Купить сейчас» на товаре).
- Выполняется
POST /checkout-sessions, включающий все уникальные элементы из массиваline_items. Массивline_itemsбудет содержать отдельный объект для каждого уникального элемента, который оформляется на выдачу. - Пользователь может обновить свой платежный инструмент, данные о выполнении заказа или применить скидки, используя вызовы
PUT /checkout-sessions/{id}. - Когда пользователь нажимает кнопку "Оплатить через GPay", выполняется
POST /checkout-sessions/{id}/complete.
Аутентификация
Хотя аутентификация не требуется, Google поддерживает следующие параметры для использования при вызове конечной точки API оформления заказа компании.
ключи API
HTTP-заголовок: X-API-Key
Общее секретное значение, которое будет использоваться в заголовке HTTP-запроса клиента UCP API Google для аутентификации с конечной точкой оформления checkout .
OAuth 2.0 (рекомендуется)
Заголовок HTTP: Authorization: Bearer <Access Token>
В соответствии с RFC 6749 , агент платформы UCP от Google использует следующие свойства для запроса токенов доступа, необходимых для взаимодействия с конечной точкой оформления checkout .
| Свойство | Описание |
|---|---|
| Идентификатор клиента | Уникальная строка, представляющая клиент (например, клиент UCP API от Google). |
| Секрет клиента | Строковый пароль, используемый для аутентификации на сервере авторизации. |
| URL-адрес конечной точки авторизации | URL-адрес конечной точки API OAuth2 |
| Формат | Базовая аутентификация: заголовок HTTP или тело HTTP-запроса |
| Кодирование | Данные формы или JSON |
инструменты разработчика
Для помощи в реализации собственного API оформления заказа вы можете найти следующие ресурсы в репозитории Universal Commerce Protocol на GitHub:
- Репозиторий UCP на GitHub: Изучите основной репозиторий для получения исчерпывающей документации, спецификаций и ресурсов сообщества.
- SDK: Используйте комплекты разработки программного обеспечения (SDK) для ускорения интеграции. Доступны SDK для конкретных языков программирования, в том числе:
Тесты на соответствие: Проверьте соответствие ваших API-интерфейсов спецификации UCP с помощью набора тестов на соответствие.
Это помогает гарантировать, что ваша реализация соответствует требуемым стандартам и нормам поведения.
Мы настоятельно рекомендуем использовать эти инструменты для оптимизации процесса разработки и тестирования.
Целевые показатели уровня обслуживания
К конечным точкам REST API Native Checkout применяются следующие целевые показатели уровня обслуживания (SLO). От компаний, интегрирующихся с Google, ожидается выполнение этих целевых показателей производительности и доступности API.
| Конечная точка | Доступность | Задержка (50-й процентиль) | Задержка (95-й процентиль) |
|---|---|---|---|
POST /checkout-sessions (Создать) | >= 95% | <= 1 секунда | <= 4 секунды |
PUT /checkout-sessions/{id} (Обновить) | >= 95% | <= 1 секунда | <= 5 секунд |
POST /checkout-sessions/{id}/complete (Complete) | >= 95% | <= 6 секунд | <= 10 секунд |
Задержка на уровне 50-го процентиля указывает на то, что, как ожидается, не менее 50% запросов будут выполнены в течение этого времени. Задержка на уровне 95-го процентиля указывает на то, что, как ожидается, не менее 95% запросов будут выполнены в течение этого времени.
Следующие шаги
Просмотрите данные API оформления заказа и технические детали реализации для вашей версии UCP:
- Версия 2026-04-08 REST API для нативной процедуры оформления заказа
- Версия 2026-01-23 REST API для нативной формы оформления заказа
Для обеспечения возможности оформления заказа пользователями необходимо реализовать интеграцию с функцией Native Checkout. Это включает в себя создание стандартного REST API, который позволяет Google программно управлять процессом оформления заказа с вашими серверами. Этот метод обеспечивает наиболее удобный для пользователей интерфейс. Первоначально Google будет отображать пользовательский интерфейс для покупателя, а в будущем планируется поддержка более гибкого взаимодействия.
Процесс оформления заказа
Для интеграции с нативными сервисами вам потребуется создать RESTful API, который Google сможет вызывать для создания и управления сессиями оформления заказа.
Общий ход событий выглядит следующим образом:
- Создание сессии оформления заказа: пользователь и, при необходимости, агент находятся в цикле, добавляя товары в сессию.
- Передача управления пользовательскому интерфейсу Google: Как только пользователь решит оформить заказ, агент (если он задействован) передает управление пользовательскому интерфейсу Google (передавая данные сессии оформления заказа).
- Ручная оплата: Теперь пользователь взаимодействует только с пользовательским интерфейсом Google для заполнения конфиденциальных данных о доставке и оплате, а также для отправки заказа. Агент не участвует в этой части, что обеспечивает детерминированность.
- Завершение и возврат: В пользовательском интерфейсе Google отображается страница «Спасибо» для подтверждения заказа. При желании пользователь может быть перенаправлен обратно к агенту, который, возможно, уже был уведомлен о завершении покупки.
Жизненный цикл статуса сессии оформления заказа
По мере продвижения пользователя по процессу оформления заказа необходимо обновлять status сессии оформления заказа, чтобы он отражал ее текущее состояние. Сессия проходит следующий жизненный цикл:
-
incomplete: Начальное состояние при создании сессии. Это указывает на то, что обязательная информация (например, способы доставки, налоги или данные пользователя) отсутствует или не рассчитана. -
ready_for_payment: Статус, который следует использовать после того, как пользователь обновит свой адрес доставки и вы рассчитаете варианты доставки и общую сумму, но до завершения обработки платежного инструмента. -
ready_for_complete: Статус, используемый во время полной загрузки объекта оформления заказа, после выбора способа оплаты и проверки всех данных заказа. -
completed: Окончательный статус, возвращаемый после успешной обработки платежа и оформления заказа. -
canceled: статус, возвращаемый в случае прерывания сеанса оформления заказа. -
error: Статус, возвращаемый в случае неустранимой ошибки бизнес-логики, препятствующей оформлению заказа. Этот статус доступен в версии UCP2026-04-08и более поздних версиях.
Процесс оформления заказа на несколько товаров:
Теперь Google поддерживает размещение нескольких отдельных позиций в одном заказе. Общий процесс выглядит следующим образом:
- Пользователь инициирует оформление заказа через интерфейс с поддержкой UCP (например, нажав кнопку «Купить сейчас» на товаре).
- Выполняется
POST /checkout-sessions, включающий все уникальные элементы из массиваline_items. Массивline_itemsбудет содержать отдельный объект для каждого уникального элемента, который оформляется на выдачу. - Пользователь может обновить свой платежный инструмент, данные о выполнении заказа или применить скидки, используя вызовы
PUT /checkout-sessions/{id}. - Когда пользователь нажимает кнопку "Оплатить через GPay", выполняется
POST /checkout-sessions/{id}/complete.
Аутентификация
Хотя аутентификация не требуется, Google поддерживает следующие параметры для использования при вызове конечной точки API оформления заказа компании.
ключи API
HTTP-заголовок: X-API-Key
Общее секретное значение, которое будет использоваться в заголовке HTTP-запроса клиента UCP API Google для аутентификации с конечной точкой оформления checkout .
OAuth 2.0 (рекомендуется)
Заголовок HTTP: Authorization: Bearer <Access Token>
В соответствии с RFC 6749 , агент платформы UCP от Google использует следующие свойства для запроса токенов доступа, необходимых для взаимодействия с конечной точкой оформления checkout .
| Свойство | Описание |
|---|---|
| Идентификатор клиента | Уникальная строка, представляющая клиент (например, клиент UCP API от Google). |
| Секрет клиента | Строковый пароль, используемый для аутентификации на сервере авторизации. |
| URL-адрес конечной точки авторизации | URL-адрес конечной точки API OAuth2 |
| Формат | Базовая аутентификация: заголовок HTTP или тело HTTP-запроса |
| Кодирование | Данные формы или JSON |
инструменты разработчика
Для помощи в реализации собственного API оформления заказа вы можете найти следующие ресурсы в репозитории Universal Commerce Protocol на GitHub:
- Репозиторий UCP на GitHub: Изучите основной репозиторий для получения исчерпывающей документации, спецификаций и ресурсов сообщества.
- SDK: Используйте комплекты разработки программного обеспечения (SDK) для ускорения интеграции. Доступны SDK для конкретных языков программирования, в том числе:
Тесты на соответствие: Проверьте соответствие ваших API-интерфейсов спецификации UCP с помощью набора тестов на соответствие.
Это помогает гарантировать, что ваша реализация соответствует требуемым стандартам и нормам поведения.
Мы настоятельно рекомендуем использовать эти инструменты для оптимизации процесса разработки и тестирования.
Целевые показатели уровня обслуживания
К конечным точкам REST API Native Checkout применяются следующие целевые показатели уровня обслуживания (SLO). От компаний, интегрирующихся с Google, ожидается выполнение этих целевых показателей производительности и доступности API.
| Конечная точка | Доступность | Задержка (50-й процентиль) | Задержка (95-й процентиль) |
|---|---|---|---|
POST /checkout-sessions (Создать) | >= 95% | <= 1 секунда | <= 4 секунды |
PUT /checkout-sessions/{id} (Обновить) | >= 95% | <= 1 секунда | <= 5 секунд |
POST /checkout-sessions/{id}/complete (Complete) | >= 95% | <= 6 секунд | <= 10 секунд |
Задержка на уровне 50-го процентиля указывает на то, что, как ожидается, не менее 50% запросов будут выполнены в течение этого времени. Задержка на уровне 95-го процентиля указывает на то, что, как ожидается, не менее 95% запросов будут выполнены в течение этого времени.
Следующие шаги
Просмотрите данные API оформления заказа и технические детали реализации для вашей версии UCP:
- Версия 2026-04-08 REST API для нативной процедуры оформления заказа
- Версия 2026-01-23 REST API для нативной формы оформления заказа
Для обеспечения возможности оформления заказа пользователями необходимо реализовать интеграцию с функцией Native Checkout. Это включает в себя создание стандартного REST API, который позволяет Google программно управлять процессом оформления заказа с вашими серверами. Этот метод обеспечивает наиболее удобный для пользователей интерфейс. Первоначально Google будет отображать пользовательский интерфейс для покупателя, а в будущем планируется поддержка более гибкого взаимодействия.
Процесс оформления заказа
Для интеграции с нативными сервисами вам потребуется создать RESTful API, который Google сможет вызывать для создания и управления сессиями оформления заказа.
Общий ход событий выглядит следующим образом:
- Создание сессии оформления заказа: пользователь и, при необходимости, агент находятся в цикле, добавляя товары в сессию.
- Передача управления пользовательскому интерфейсу Google: Как только пользователь решит оформить заказ, агент (если он задействован) передает управление пользовательскому интерфейсу Google (передавая данные сессии оформления заказа).
- Ручная оплата: Теперь пользователь взаимодействует только с пользовательским интерфейсом Google для заполнения конфиденциальных данных о доставке и оплате, а также для отправки заказа. Агент не участвует в этой части, что обеспечивает детерминированность.
- Завершение и возврат: В пользовательском интерфейсе Google отображается страница «Спасибо» для подтверждения заказа. При желании пользователь может быть перенаправлен обратно к агенту, который, возможно, уже был уведомлен о завершении покупки.
Жизненный цикл статуса сессии оформления заказа
По мере продвижения пользователя по процессу оформления заказа необходимо обновлять status сессии оформления заказа, чтобы он отражал ее текущее состояние. Сессия проходит следующий жизненный цикл:
-
incomplete: Начальное состояние при создании сессии. Это указывает на то, что обязательная информация (например, способы доставки, налоги или данные пользователя) отсутствует или не рассчитана. -
ready_for_payment: Статус, который следует использовать после того, как пользователь обновит свой адрес доставки и вы рассчитаете варианты доставки и общую сумму, но до завершения обработки платежного инструмента. -
ready_for_complete: Статус, используемый во время полной загрузки объекта оформления заказа, после выбора способа оплаты и проверки всех данных заказа. -
completed: Окончательный статус, возвращаемый после успешной обработки платежа и оформления заказа. -
canceled: статус, возвращаемый в случае прерывания сеанса оформления заказа. -
error: Статус, возвращаемый в случае неустранимой ошибки бизнес-логики, препятствующей оформлению заказа. Этот статус доступен в версии UCP2026-04-08и более поздних версиях.
Процесс оформления заказа на несколько товаров:
Теперь Google поддерживает размещение нескольких отдельных позиций в одном заказе. Общий процесс выглядит следующим образом:
- Пользователь инициирует оформление заказа через интерфейс с поддержкой UCP (например, нажав кнопку «Купить сейчас» на товаре).
- Выполняется
POST /checkout-sessions, включающий все уникальные элементы из массиваline_items. Массивline_itemsбудет содержать отдельный объект для каждого уникального элемента, который оформляется на выдачу. - Пользователь может обновить свой платежный инструмент, данные о выполнении заказа или применить скидки, используя вызовы
PUT /checkout-sessions/{id}. - Когда пользователь нажимает кнопку "Оплатить через GPay", выполняется
POST /checkout-sessions/{id}/complete.
Аутентификация
Хотя аутентификация не требуется, Google поддерживает следующие параметры для использования при вызове конечной точки API оформления заказа компании.
ключи API
HTTP-заголовок: X-API-Key
Общее секретное значение, которое будет использоваться в заголовке HTTP-запроса клиента UCP API Google для аутентификации с конечной точкой оформления checkout .
OAuth 2.0 (рекомендуется)
Заголовок HTTP: Authorization: Bearer <Access Token>
В соответствии с RFC 6749 , агент платформы UCP от Google использует следующие свойства для запроса токенов доступа, необходимых для взаимодействия с конечной точкой оформления checkout .
| Свойство | Описание |
|---|---|
| Идентификатор клиента | Уникальная строка, представляющая клиент (например, клиент UCP API от Google). |
| Секрет клиента | Строковый пароль, используемый для аутентификации на сервере авторизации. |
| URL-адрес конечной точки авторизации | URL-адрес конечной точки API OAuth2 |
| Формат | Базовая аутентификация: заголовок HTTP или тело HTTP-запроса |
| Кодирование | Данные формы или JSON |
инструменты разработчика
Для помощи в реализации собственного API оформления заказа вы можете найти следующие ресурсы в репозитории Universal Commerce Protocol на GitHub:
- Репозиторий UCP на GitHub: Изучите основной репозиторий для получения исчерпывающей документации, спецификаций и ресурсов сообщества.
- SDK: Используйте комплекты разработки программного обеспечения (SDK) для ускорения интеграции. Доступны SDK для конкретных языков программирования, в том числе:
Тесты на соответствие: Проверьте соответствие ваших API-интерфейсов спецификации UCP с помощью набора тестов на соответствие.
Это помогает гарантировать, что ваша реализация соответствует требуемым стандартам и нормам поведения.
Мы настоятельно рекомендуем использовать эти инструменты для оптимизации процесса разработки и тестирования.
Целевые показатели уровня обслуживания
К конечным точкам REST API Native Checkout применяются следующие целевые показатели уровня обслуживания (SLO). От компаний, интегрирующихся с Google, ожидается выполнение этих целевых показателей производительности и доступности API.
| Конечная точка | Доступность | Задержка (50-й процентиль) | Задержка (95-й процентиль) |
|---|---|---|---|
POST /checkout-sessions (Создать) | >= 95% | <= 1 секунда | <= 4 секунды |
PUT /checkout-sessions/{id} (Обновить) | >= 95% | <= 1 секунда | <= 5 секунд |
POST /checkout-sessions/{id}/complete (Complete) | >= 95% | <= 6 секунд | <= 10 секунд |
Задержка на уровне 50-го процентиля указывает на то, что, как ожидается, не менее 50% запросов будут выполнены в течение этого времени. Задержка на уровне 95-го процентиля указывает на то, что, как ожидается, не менее 95% запросов будут выполнены в течение этого времени.
Следующие шаги
Просмотрите данные API оформления заказа и технические детали реализации для вашей версии UCP: