Что такое платёжный API простыми словами
Платёжный API нужен проектам, которые хотят создавать операции из собственного сайта, приложения или бота. Разберём смысл без лишних терминов и без предположений о возможностях интеграции.
Что такое API
Договор между двумя программами
API — это набор заранее описанных запросов и ответов. Одна система отправляет данные в установленном формате, другая проверяет их и возвращает результат. Разработчик не управляет внутренним устройством платёжного сервиса, а использует доступные команды.
В платёжном сценарии ваша серверная часть может создать операцию и получить данные для продолжения пути пользователя. Точные поля, ответы и ограничения всегда нужно брать из актуальной документации DonPay, а не из примеров сторонних сервисов.
API не является готовым экраном продаж. До интеграции проекту всё равно нужны описание предложения, сумма, номер заказа, обработка результата и интерфейс для клиента.
Кому нужен платёжный API
Когда ручной ссылки становится недостаточно
API нужен владельцам сайтов, приложений и собственных Telegram-ботов, где заказ уже создаётся автоматически. Интеграция связывает внутренний номер заказа с платёжной операцией и позволяет продолжить сценарий после изменения статуса.
Для редких ручных продаж API может быть избыточен. Платёжная ссылка проще: её можно отправить клиенту после согласования. Выбор зависит не от размера проекта, а от повторяемости процесса и наличия разработчика.
До начала интеграции опишите состояния заказа: создан, ожидает оплаты, оплачен, отклонён. Решите, какое действие разрешено в каждом состоянии и кто разбирает исключения.
- Есть собственный сервер.
- Заказы создаются регулярно.
- Нужно связать оплату с внутренним заказом.
- Команда готова поддерживать интеграцию.
Что такое API-ключ
Секрет для подтверждения запросов
API-ключ связывает запрос с конкретным проектом. Его следует считать секретом, даже если сам формат выглядит как обычная строка. Ключ не предназначен для публикации, переписки или вставки в код страницы, который загружается в браузер.
Запросы с секретом выполняются на сервере проекта. Пользовательский интерфейс обращается к вашему серверу, а уже он — к API. Так ключ не оказывается у посетителя.
Выдавайте доступ только тем людям и системам, которым он нужен. При подозрении на утечку прекратите использовать ключ, замените его через доступный процесс и проверьте связанные события.
Проверьте перед следующим шагом
- Ключ отсутствует в frontend-коде.
- Он не хранится в публичном репозитории.
- Логи не выводят секрет целиком.
- Есть порядок действий при утечке.
Как устроен базовый путь оплаты
Создание, переход и подтверждение
Сначала ваша серверная часть создаёт операцию с необходимыми данными. В ответ она получает идентификатор и сведения, которые использует для перехода клиента. Сохраняйте связь со своим заказом, чтобы не сопоставлять операции вручную.
Клиент завершает действие на платёжной странице. Возврат пользователя в интерфейс полезен для навигации, но сам по себе не является доказательством оплаты.
Фактический результат определяется статусом. Его получают по предусмотренному API-сценарию и через уведомления, если они настроены. Выдавать продукт или менять заказ можно только после проверки события на сервере.
- 1Создать внутренний заказ.
- 2С сервера запросить платёжную операцию.
- 3Перевести клиента по полученной ссылке.
- 4Проверить подтверждённый статус.
- 5Безопасно выполнить действие по заказу.
Чем API отличается от платёжной ссылки
Автоматизация против готового пути
Платёжная ссылка уже является точкой перехода для клиента. Её удобно отправить вручную или разместить рядом с предложением. API, напротив, встраивается в существующую систему и требует разработки серверной логики.
API даёт проекту контроль над связью заказа и операции, но добавляет ответственность: хранение ключа, проверка ответов, обработка повторов и ошибок. Не выбирайте интеграцию только потому, что она звучит технологичнее.
Начните с карты пользовательского пути и документации. Если готовая ссылка закрывает задачу, усложнение не нужно. Если заказ создаётся программно и должен продолжаться без ручной работы, API становится логичным инструментом.
Почему ключ нельзя передавать третьим лицам
Доступ означает возможность действовать от имени проекта
Человек или программа с ключом могут отправлять авторизованные запросы в пределах доступных операций. Поэтому пересылка в чат, публикация в инструкции или хранение в открытом файле создают риск.
Даже внутри команды передавайте секрет через предназначенное защищённое хранилище. Не вставляйте его в снимки экрана и обращения в поддержку целиком.
Безопасность интеграции — это постоянный процесс. Периодически проверяйте, где используется ключ, удаляйте ненужные копии и обновляйте доступ при изменении состава команды.