Подготовьте платёжное подключение ресторана
Откройте организацию и выберите «Платёжные подключения». Авторизованный сотрудник выбирает юридическое лицо, которому принадлежит эквайринг. Продавцом остаётся ресторан; настройка подключения не делает Hallify продавцом.
Для Bank of Georgia или TBC создайте подключение и добавьте credentials в защищённом кабинете. Выберите нужную версию credentials, проверьте политику и настройте привязки заведения, канала продаж, назначения платежа и валюты. Новое банковское подключение имеет статус PENDING. Успешная проверка получения токена сама по себе не подтверждает готовность принимать платежи.
Для Stripe Connect выберите точный доступный профиль платформы и его версию, затем пройдите подключение. Возвращайтесь через /payment-connections/stripe-return в том же контексте браузера. Если результат неизвестен или данные callback недоступны, используйте восстановление в кабинете: одного перенаправления браузера недостаточно для подтверждения авторизации или оплаты.
Договоры с провайдерами, профили платформы и серверные ключи заранее подготавливает ответственный администратор. Этот раздел кабинета не выпускает публичные ключи интеграции. Не вставляйте банковские credentials, OAuth code/state или секреты провайдера в примеры документации, публичные браузерные API-запросы и frontend своего сайта. Вводите credentials только через авторизованный защищённый кабинет.
API этих настроек относятся к авторизованным операциям сотрудников и намеренно отсутствуют в публичном справочнике. Настройка эквайринга не подтверждает наличие полного гостевого checkout. Проверка реальных merchant-подключений Stripe/BOG/TBC, callbacks и устройств остаётся отдельным условием активации.
Используйте нативную оплату счёта и гарантии брони
Ресторанный эквайринг — отдельное обязательное условие guest-payments. Текущие QR_MEMBERSHIP или PREORDER_MANAGE оплачивают положительный нативный principal ORDER_BILL через AUTOMATIC capture. Настоящий RESERVATION_MANAGE оплачивает точную RESERVATION_GUARANTEE: DEPOSIT/PREPAID используют AUTOMATIC capture, CARD_HOLD — MANUAL authorization. Каждый сценарий требует допустимой привязки purpose/currency/provider, серверного юридического получателя и явного сохранённого согласия; настройка провайдера не создаёт гостевой доступ или согласие.
Гостевой checkout использует собственный приватный доступ, неизменяемый результат команды, provider operation и восстановление original. Он не использует HMAC-рецепт симулятора с этой страницы для нативных Stripe, BOG или TBC платежей и не предоставляет публичных гостевых capture/void/refund. Путь /guest/payments/return означает только навигацию; он отделён от защищённого возврата подключения merchant /payment-connections/stripe-return.
Авторизация, capture и выполнение нативной гарантии разделены. CARD_HOLD требует доказанной действующей авторизации провайдера на точную сумму и период защиты; списанный DEPOSIT/PREPAID — фактического нативного применения. forfeitGuarantee/applyGuaranteeCredit защищены правами сотрудников и не являются публичными/headless командами оплаты. Читайте исходные квитанции команд и текущее состояние провайдера/нативного ресурса через их собственные сценарии.
Изолированный виджет не выполняет PSP checkout внутри страницы-родителя. Точный prepare/claim transition переносит только приватный transport permit в выбранный сервером top-level receiver и продолжает исходный handoff/checkout. SDK раскрывает canonical operations без вымышленного успеха, заменяющего согласия или другой оплаты.
Настройте доступ
Используйте настроенный профиль платёжного провайдера и ключ провайдера соответствующей попытки. Секреты остаются на отправляющем сервере и в конфигурации Hallify. Наличие контракта симулятора не подтверждает сертифицированную production-интеграцию.
Заведение работает с попытками оплаты в /venues/:venueId/pos. Выдача секрета webhook провайдера относится к конфигурации развёртывания и провайдера; публичного самостоятельного выпуска такого ключа в кабинете нет. До отправки callback согласуйте настройку с администратором Hallify.
Первый успешный сценарий
Выполните шаги по порядку. Откройте каждый метод для точного тела, обязательных заголовков и схемы ответа.
- Подготовьте идентификатор платёжной попытки Hallify, уникальный идентификатор события провайдера, статус и время.
- Для опубликованного контракта симулятора этого endpoint подпишите стабильный JSON настроенным секретом UTF-8, временем RFC3339 и подписью v1=<hex>. Не переносите этот способ подписи на native callbacks Stripe, BOG или TBC.
- Передайте событие в webhook провайдера и проверьте применение либо распознавание повтора.
Состояния, повторы и восстановление
Повтор идентификатора события с другим содержимым вызывает конфликт. Неизвестная платёжная попытка не создаётся автоматически. Ошибка после capture создаёт свидетельство исключения сверки вместо скрытой отмены уже списанных денег.
Этот callback обслуживает опубликованный контракт адаптера платёжных попыток. Попытка, уже связанная с ресторанным provider-operation workflow, отклоняется с кодом PAYMENT_PROVIDER_OPERATION_REQUIRED и должна продолжаться через свой доменный workflow. Endpoint симулятора не заменяет проверку подписей конкретного провайдера, финансовое восстановление и квалифицированные native callbacks.