Модели интеграции: hosted vs S2S
- Hosted (redirect/виджет): минимальные риски и быстрый старт. Данные карты вводятся на стороне провайдера. Подходит большинству.
- S2S (server‑to‑server): полный контроль UX, свои формы, кастомизация 3DS‑flows. Требует повышенных мер безопасности и часто — SAQ‑A‑EP.
Комбинации: checkout‑виджет + S2S для повторных списаний.
Архитектура API и ключевые эндпоинты
Типичные ресурсы: /payments (создание платежа), /captures (подтверждение), /refunds (возвраты), /payouts (выплаты), /customers (токены), /webhooks. Используйте correlation‑ID и идемпотентные ключи при повторах.
Вебхуки: надёжная доставка и идемпотентность
- Подпись вебхуков (HMAC) и проверка таймштампа.
- Ретраи с экспоненциальной паузой.
- Идемпотентность обработчика: повторные события — не проблема.
- Логи и трассировка (например, связка webhook‑ID ↔ order‑ID).
3‑D Secure 2.0: UX и риски
Поддерживайте фрикционную и фрикцион‑лес (frictionless) аутентификацию. Собирайте RBA‑атрибуты (email, адрес, device‑fingerprint) для повышения доли фрикцион‑лес. Тестируйте сценарии отклонений.
PCI DSS и модели соответствия (SAQ)
- SAQ‑A: redirect/виджет → минимум требований.
- SAQ‑A‑EP: если форма на вашем домене загружает элементы с провайдера.
- Полный scope: собственная обработка карт, крайне не рекомендуется без опыта.
Токенизация и one‑click платежи
Сохраняйте токены клиентов у провайдера, а не PAN. Обрабатывайте жизненный цикл токенов (обновление, отмена согласий). Для подписок важны «grace‑периоды» и умные ретраи.