Руководство: оформление платежа

Правильная архитектура интеграции: клиентский браузер общается с вашим сервером, а ваш сервер — с Eleven Pay. API‑ключ никогда не попадает в браузер.

Архитектура

Клиент (браузер/приложение)
        │  (ваш сайт/приложение)
        ▼
Ваш сервер (backend)  ──  Authorization: Bearer <API_KEY>  ──►  Eleven Pay API
        ▲
        │  (безопасные данные: reference, действие оплаты)

Никогда не делайте так:

Клиент (браузер) ──  Authorization: Bearer <API_KEY>  ──►  Eleven Pay API   ← НЕЛЬЗЯ

Ключ Merchant API — серверный секрет. Его раскрытие в клиенте компрометирует вашу интеграцию.

Поток

1. Клиент оформляет заказ на вашем сайте.
2. Ваш сервер определяет amount и merchant_order_id (не доверяйте сумме из браузера без серверной проверки).
3. Ваш сервер вызывает POST /v1/payments с Idempotency-Key (см. Создание платежа).
4. Ваш сервер возвращает браузеру только безопасные данные: reference и, при наличии, действие оплаты (qr/redirect).
5. Клиент выполняет действие оплаты.
6. Eleven Pay доставляет вебхук payment.succeeded на ваш сервер — выдайте товар/услугу (обработчик).
7. При неопределённости сервер сверяется через GET.

Владение суммой

amount и merchant_order_id определяет ваш сервер. Не принимайте сумму, присланную из браузера, без серверной проверки против вашего заказа — иначе клиент сможет подменить цену.

Данные действия оплаты в браузере

Если вы передаёте action.value (QR) или action.url (redirect) в браузер, относитесь к ним как к материалу платёжной сессии: не сохраняйте без необходимости, не логируйте, не отправляйте в сторонние сервисы (см. Действия оплаты).