PAYSTAR / ДОКУМЕНТАЦИЯ ДЛЯ РАЗРАБОТЧИКОВ

Быстрый старт и доступ

Подготовьте правильные учётные данные, безопасно отправьте первый запрос и установите результат при неопределённости.

[01]

Уточните профиль интеграции

Выберите точный сценарий: P2P, ECOM H2H, готовая форма H2C, пополнение по токену или выплата.
Уточните тестовый режим, разрешённые хосты, IP сервера, включённые валюты и лимиты.
Получите обязательные additionalFields для этого pipeline и согласованные тестовые данные.
До запроса создания уточните настройки callback и перенаправлений клиента.

[02]

Аутентификация

Передавайте назначенный Bearer-ключ в каждом защищённом запросе. У каждого pipeline отдельный ключ: у двух pipeline пополнений ключи различаются, а пополнения и выплаты никогда не используют общий ключ pipeline.

HTTP-заголовокВыделите текст для копирования

Authorization: Bearer <PIPELINE_SPECIFIC_KEY>

Получение и замена учётных данных

Запросите у PayStar учётные данные назначенного pipeline и среды. Храните ключи на сервере, вне URL, репозиториев, браузерного кода и логов. При подозрении на раскрытие немедленно запросите замену.

Прежнее руководство допускает готовый Bearer-токен или согласованную пару открытого/закрытого ключей. Уточните поддерживаемый порядок выпуска и отзыва для вашего аккаунта.

Создание JWT — прежнее руководство подключенияДополнительно

Прежнее руководство · уточните выпуск

Прежний механизм использует JWT с HS256, с полем publicKey в payload; закрытый ключ применяется только для подписи. Не включайте закрытый ключ в payload.

Структура payload JWTВыделите текст для копирования

{
  "publicKey": "<PUBLIC_KEY>"
}

Срок действия токена и дополнительные claims не установлены проверенными материалами. Получите у PayStar проверенный пример подписи для согласованного способа подключения.

[03]

Создайте, сохраните ID и проверьте

01
Создайте заявку
Используйте число JSON в основных единицах валюты и уникальный externalTransactionId. Следуйте схеме выбранного сценария.
02
Сохраните оба идентификатора
Сохраните исходный ID мерчанта и возвращённый PayStar externalId.
03
Получите текущее состояние
Используйте orderStatus. Статус пополнения содержит непустую историю; история выплаты может быть пустой или запаздывать.

Открыть шаблоны запросов пополнения → Открыть руководство по выплатам →

Суммы, валюта и обратная совместимость

Используйте число, например 100.00, в основных единицах валюты. Числовые строки сохраняются только для обратной совместимости.
Утверждённое владельцем API округление P2P half-up: 100.124 → 100.12, 100.125 → 100.13, 100.126 → 100.13. Не переносите его на непроверенные сценарии.
Валюта — строковый ключ без проверки длины или шаблона написания. При создании платежа поиск во внутреннем справочнике валют предшествует поиску маршрута pipeline. См. ключи валют и примеры криптовалют.
В новых примерах ключи дополнительных полей используют lowerCamelCase. Прежний PascalCase принимается для совместимости.
Обязательные дополнительные поля и минимальные/максимальные суммы зависят от профиля.

[04]

Установите результат до повтора

После тайм-аута создания, обрыва соединения, отсутствия ответа или HTTP 5xx, запросите статус по тому же исходному ID мерчанта до повтора или каскадного перехода к другому запросу создания.

Проверка статуса по ID мерчанта →

Опрос и окончательные статусыНужно согласовать правила

Для пополнений P2P статус Failed означает неуспешный результат, который позднее может быть исправлен на Success в той же заявке, обычно по инициативе поддержки мерчанта. Сохраняйте существующие ID и обрабатывайте callback исправления с проверкой подлинности. Обратный бизнес-переход Success → Failed реализовывать не требуется. Это не меняет классификацию других сценариев и не требует бесконечного опроса. Интервал опроса, условия остановки, увеличение пауз и эскалацию нужно согласовать с PayStar.

Прежние страницы расходятся между двумя и пятью минутами; эта версия не выбирает один вариант молча. Получение callback не заменяет установление результата неизвестного запроса создания. См. callback исправления P2P.

[05]

Результаты тестовой среды

Используйте только возможности, явно назначенные тестовому профилю. Учитывайте каждый принятый запрос создания, включая негативные тесты, которые неожиданно завершились успехом.

Управление успехом и отказом из прежнего руководства

Описано в прежнем руководстве · на живом сервисе не проверено

Прежнее руководство описывает ключ дополнительного поля ExpectedResult с такими значениями:

Значение	Ожидаемый имитируемый результат
`status=success`	Успешный платёж
`status=failed`	Неуспешный платёж

В прежнем тексте также используется expectedResult. До использования уточните стандартный регистр, принимаемые алиасы и применимость к вашему профилю.

Чего не доказывает успешный статус тестовой среды

Статус тестовой среды Success сам по себе не доказывает прохождение клиентом 3DS, фактическую доставку callback, правильные перенаправления браузера или одинаковые проверки в production. Запросите отдельные тестовые данные для этих проверок.

Посмотреть датированную матрицу проверок →

Нужны обязательные поля, валюты или лимиты для вашего pipeline?

Уточнить профиль у Егора ↗