JSON PSP
@checkout-kit/provider-psp — пример адаптера для случая, когда у вас платёжный провайдер с JSON API: оплата картой, токены сохранённых карт и проверка банком 3-D Secure 2 во фрейме или во всём окне.
- id провайдера:
psp. - Чем платит покупатель (инструмент): карта или токен сохранённой карты.
Пакет показывает протокол сервера из примеров checkout kit. Используйте его как рабочий шаблон для своей интеграции вместе с поддельным сервером из @checkout-kit/testing/backend. Это не сертифицированный адаптер для какого-либо настоящего банка или платёжной системы. Для Stripe, Adyen и PayPal используйте их собственные пакеты.
Установка из npm
npm install @checkout-kit/core @checkout-kit/runtime-browser @checkout-kit/provider-pspПакет в npm · Все варианты установки
Настройка
Как установить пакеты, описано в быстром старте.
import { defineProvider } from '@checkout-kit/core'
import type { PspConfig } from '@checkout-kit/provider-psp'
const config: PspConfig = { baseUrl: '/api', acsOrigin: 'https://acs.example.com' }
const provider = defineProvider({
id: 'psp',
config: { ...config, credentials: 'include' },
load: () => import('@checkout-kit/provider-psp'),
})
// Pass provider to createCheckout({ providers: [provider], ... }).baseUrl— адрес API вашего сервера.headers(необязательно) — заголовки вашей сессии или защиты от CSRF.credentialsопределяет, отправляются ли cookie.- Секретные ключи платёжного сервиса храните на сервере.
- Браузерный runtime, адрес возврата и адаптер SDK (если нужен) даёт ваше приложение — см. React и работа в браузере.
API сервера
Пути ниже указаны относительно baseUrl. На своём сервере: авторизуйте покупателя, берите цену по planId, проверяйте, что заказ принадлежит этому покупателю, и разрешайте только допустимые смены статуса. Суммы — целые числа в минимальных единицах валюты (например, в копейках или центах).
| Метод | Путь | Что делает |
|---|---|---|
| POST | /payment-intents | Создаёт платёж из { planId } и возвращает его. |
| GET | /payment-intents/:id | Возвращает настоящее состояние платежа, включая активную проверку банком. |
| POST | /payment-intents/:id/confirm | Принимает { cardNumber } или { paymentMethodId } и возвращает платёж. |
| POST | /3ds/challenge/:id/complete | Только для симулятора: принимает { outcome }, возвращает { paymentIntent }. |
| POST | /payment-intents/:id/cancel | Отменяет ещё не завершённый платёж. |
Ответы с платежом, заказом или списанием содержат { id, amount, currency, status, error? }. Статусы — значения PaymentStatus из checkout kit. При отказе в error может быть { code?, message }.
Проверка банком (3DS). Если платежу нужна проверка банком, в ответе есть nextAction.three_d_secure.challengeId. Прежде чем завершить проверку, адаптер убеждается, что этот id совпадает с шагом, который вернулся.
В симуляторе запрос с { outcome } играет роль тестовой страницы банка (ACS). В настоящей интеграции результат проверки должен проверять ваш сервер. Никогда не определяйте его по transStatus, присланному браузером.
Повторы и проверка
Прежде чем снова открыть платёж, использовать другой токен или отменить, адаптер читает настоящий заказ с сервера. Успешные, отклонённые и отменённые заказы сохраняют свой результат. Для заказов в обработке статус продолжает проверяться. После потерянного ответа повтор сначала проверяет тот же заказ и только потом отправляет следующее изменение.
Идемпотентность. При создании CallOptions.idempotencyKey отправляется в заголовке Idempotency-Key. Для остальных изменений к ключу добавляются операция и id платежа (:confirm:, :resume:, :pay:, :code: или :cancel:). Ваш сервер должен учитывать ключ и отклонять запрос с тем же ключом, но другими данными. Один только заголовок не гарантирует единственное списание.
Тесты контракта и регрессии для этого пакета:
npm ci
npm test -- packages/provider-pspЗапуск и проверка
Запустите npm run dev:mock и npm run dev:bank или откройте демо на сайте. Проверьте успешную оплату, отказ, дополнительный шаг, обработку, повтор и данные от чужого заказа. Это пример протокола, а не интеграция с настоящим банком. Окружение симулятора, восстановление и тестирование объясняют остальное.