Подготовьте настоящее подключение виджета
Для заведения используйте /venues/:venueId/settings/storefront, для бренда — /organizations/:organizationId/storefront. Настройка заведения требует venueSettings, организации — organization.manage. Опубликуйте проверенное представление, добавьте WIDGET-подключение, прикрепите точный нативный ресурс PREORDER, RESERVATION или QR и зарегистрируйте сайт встраивания как его WIDGET_PARENT binding. Подтвердите выданный DNS challenge и активируйте подключение только при текущей готовности.
Ответственный оператор настраивает HALLIFY_WIDGET_FRAME_ORIGIN как изолированный origin отдельно от хостов аккаунта и API cookies. Используйте этот точный frameOrigin и выданный parentBindingId; parent binding не является ID нативного ресурса. Правила бронирования, fulfillment, QR и эквайринга по-прежнему настраиваются в своих кабинетах. Публичный widget API не создаёт настройки, права сотрудников, платёжные ключи или sandbox.
Запустите виджет с публичными selectors
Вход SDK-модуля — /sdk/0.1.0/browser/index.mjs. Маршрут и source-пакет подготовлены этой реализацией; документация не подтверждает развёртывание версии на публичном origin или публикацию в npm. Перед использованием замените синтетические frame origin и UUID ниже значениями своего настоящего подключения.
Выберите flow reservation, preorder или table и locale en, ka или ru. widgetId — стабильный идентификатор из 1–64 букв, цифр, подчёркиваний или дефисов: сохраняйте его после reload и делайте уникальным для места интеграции. SDK создаёт отдельный свежий случайный message instance для каждого mount. Только table может передать tableLocator, если он нужен нативному сценарию стола. ready разрешается после сообщения готовности инициализированного frame; destroy идемпотентно удаляет только ресурсы этого mount.
<div id="hallify-reservation"></div>
<button id="close-widget" type="button">Close</button>
<p id="widget-status" role="status">Loading...</p>
<script type="module">
import { mountWidget } from 'https://hallify.co/sdk/0.1.0/browser/index.mjs';
const widget = mountWidget(document.getElementById('hallify-reservation'), {
frameOrigin: 'https://widgets.example.invalid',
connectionId: '2604de3a-da74-4ad5-89f6-2dfe000d5391',
parentBindingId: '3604de3a-da74-4ad5-89f6-2dfe000d5391',
venueId: '4604de3a-da74-4ad5-89f6-2dfe000d5391',
flow: 'reservation',
locale: 'en',
widgetId: 'reservation-main',
});
document.getElementById('close-widget').addEventListener('click', () => {
widget.destroy();
});
try {
await widget.ready;
document.getElementById('widget-status').textContent = 'Ready';
} catch {
document.getElementById('widget-status').textContent = 'Widget unavailable';
}
</script>Сохраняйте точные границы frame и parent
Фиксированный путь frame — /widgets/:connectionId с публичными query selectors binding, venue при выборе, flow, lng, widgetId и свежим instance; table может дополнительно использовать locator. В URL не передаются proof или нативные данные доступа. Bootstrap выполняется внутри frame при его фактическом изолированном Origin, возвращает точные parent/frame/API origin и определяет текущие типизированные resource/channel. Родитель никогда не получает swc1.
Frame проверяет точного родителя и ждёт действительный hello/init handshake до бизнес-действий. Сообщения проверяются по точным origin, source, версии протокола, instance и форме payload. ACTIVE bootstrap допускает NEW_DEMAND с текущей публикацией и краткосрочным context; DISABLED может вернуть CONTINUATION_ONLY без нового proof или discovery. Сохранённые нативные данные доступа независимо управляют исходным продолжением и сроками.
Новый widget-спрос передаёт swc1 как x-hallify-widget-context внутри request boundary frame. Он доказывает presentation, а не принадлежность нативного гостевого ресурса. Данные draft/manage/membership/payment остаются отдельными. Обновление proof не продлевает черновик, quote, доступ, платёжное окно или исходную команду. Origin задаёт браузер; не подставляйте родителя и не используйте cookies аккаунта.
Используйте безопасные события и отдельные storage slots
Публичные события: ready, ограниченный resize, close-requested, flow-completed и error с допустимым кодом. В них нет business/private ID, контакта, кода проверки, capability или данных провайдера. flow-completed сообщает этап сценария и не доказывает оплату, окончательное подтверждение или settlement. Эти факты читаются у нативного владельца.
Нативные приватные storage, cache и журналы команд ограничены проверенным parent binding, подключением, venue/flow и стабильным widgetId. Двум frame одного origin нужны разные стабильные slots; reload того же slot позволяет восстановить исходную команду. Случайный message instance задаёт свежесть текущего mount и не заменяет ключ восстановления. Ни один selector не даёт прав. Unmount не отменяет сохранённые заказы, брони или платежи.
Переведите оплату в сохранённый top-level receiver
Внутри виджета используйте нативный платёжный вход QR_MEMBERSHIP, PREORDER_MANAGE или RESERVATION_MANAGE. До prepare-transition сохраните один transition UUID и криптографически случайный gpw1_ permit, затем передайте только его SHA-256 digest с текущим приватным платёжным доступом. Ответ замораживает destinationOrigin и expiresAt не более чем на 60 секунд внутри исходных прав; он не создаёт согласие, финансовую команду или запрос провайдера.
Приватный top-level form POST на фиксированный адрес передаёт только permit и transition UUID, без native/payment-access данных, parent relay или зависимости от opener. Канонический receiver до claim-transition сохраняет свою capability/handoff tuple, при неизвестности повторяет точную tuple, затем использует обычный redeem-handoff и исходный checkout/журнал. Потеря tuple не разрешает заменяющий receiver, команду или оплату. UNKNOWN остаётся неразрешённым.
Отделяйте source-поставку от live-квалификации
Нативные правила бронирования/заказа/стола, согласия гарантии и восстановления сохраняют силу. Заказ предзаказа может использовать настроенные нативные SELF, UBER_DIRECT или WOLT_DRIVE и восстановление клиентского расчёта из руководства публичных предзаказов. Принятый клиентский сбор за доставку отделён от последующей staff-стоимости отправки; состояние курьера не доказывает оплату еды или возврат. Wolt Drive требует настоящие координаты доставки, frame их не выдумывает. Staff-команды курьеру и секреты перевозчика остаются вне виджета и его безопасных событий родителю. Настройки, DNS/TLS, реальное размещение frame, third-party storage, браузерные сценарии, эквайринг Stripe/BOG/TBC и боевая квалификация перевозчика требуют настоящей среды. Исходная реализация, generated types и примеры событий не доказывают эти long/live результаты или публикацию в npm.