hyperswitch-prism

Что такое hyperswitch-prism?

Hyperswitch Prism — stateless единая библиотека-коннектор для интеграции с платежными процессорами. Она разработана для предоставления единой схемы запросов/взаимодействий, чтобы одни и те же шаблоны вызовов можно было использовать для нескольких платежных процессоров с меньшим количеством изменений в коде.

Prism был выделен и поддерживается командой, стоящей за Hyperswitch — открытой платформой для платежей. Репозиторий описывает Prism как слой трансформации, который фокусируется на согласованности интеграции коннекторов, оставляя такие аспекты, как хранилище/токенизация, повторы и логика маршрутизации, Hyperswitch.

Ключевые возможности

• Единая схема запросов для всех коннекторов: Один и тот же вызов authorize работает с несколькими процессорами (например, Stripe, Adyen) без дополнительных строк кода для каждого процессора.
• Stateless библиотека (без БД, без хранения PII): Prism не требует базы данных и избегает хранения персональных данных; указано, что учетные данные не хранятся и не логируются библиотекой, а существуют только на время жизни HTTP-клиента.
• Контроль PCI-охвата по дизайну: Библиотека может избегать передачи карточных данных в Prism; поток карточных данных (или его отсутствие) через библиотеку позиционируется как выбор, с возможностью использовать хранилище платежного процессора или PCI-сертифицированное хранилище пользователя.
• Непрерывное тестирование коннекторов с опубликованной моделью статусов: Коннекторы непрерывно тестируются на реальных sandbox/production-средах, с легендой статусов, охватывающей поддерживаемые, в работе/частичные и требующие валидации состояния.
• Идиоматичный многоязычный интерфейс (по документации репозитория): Prism описывается как type-safe идиоматичный интерфейс, упакованный как многоязычный SDK.

Как использовать hyperswitch-prism

1. Выберите Prism SDK для вашего языка и ознакомьтесь с руководством SDK по аутентификации и шаблонам запросов.
2. Пишите платежные запросы с использованием единой схемы Prism (например, используя одну и ту же форму вызова authorize для разных платежных процессоров).
3. Выберите, где обрабатывать чувствительные платежные данные: используйте собственное PCI-сертифицированное хранилище или хранилище платежного процессора, в соответствии с заметкой репозитория, что сервисы хранилища/токенизации не встроены в Prism.
4. Проверьте покрытие коннекторов для ваших нужд на странице покрытия/статусов проекта, поскольку Prism описывает разные уровни поддержки для коннекторов.

Случаи использования

• Интеграция чекаута с несколькими процессорами: Вы хотите маршрутизировать платежные операции на более чем один платежный процессор, минимизируя изменения в коде приложения за счет единой схемы запросов Prism.
• Снижение состояния и хранимых данных в слое интеграции: Ваша команда предпочитает stateless слой коннекторов, где сам Prism не требует базы данных и не хранит/не логирует учетные данные.
• Соответствие PCI-обязательствам через выбор хранилища: Вы хотите контролировать, обрабатываются ли карточные данные внутри вашей инфраструктуры, и выбирать между хранилищем платежного процессора или собственным PCI-сертифицированным хранилищем.
• Инженерные команды, поддерживающие логику коннекторов со временем: Вам нужен слой интеграции коннекторов, который непрерывно тестируется на sandbox/production и отслеживается по статусам для каждого коннектора.
• Интеграция слоя трансформации в крупной платежной платформе: Вы используете Prism как слой трансформации, реализуя логику повторов/маршрутизации в другом месте (репозиторий указывает на Juspay Hyperswitch для этих аспектов).

FAQ

Prism отвечает за повторные попытки и логику маршрутизации?
Нет. В репозитории указано, что повторные попытки и логика маршрутизации находятся в Juspay Hyperswitch; Prism представлен как слой трансформации.

В Prism есть встроенный vault или сервис токенизации?
Нет. Это осознанный выбор дизайна; вы можете использовать свой vault или vault платежного процессора.

Prism хранит учетные данные или PII?
В репозитории указано, что библиотека не хранит и не логирует учетные данные, она stateless без базы данных и не хранит PII. Также отмечено, что учетные данные существуют только на время жизни вашего HTTP-клиента.

Как узнать, какие платежные процессоры и методы платежа поддерживаются?
Prism публикует покрытие коннекторов с легендой, указывающей поддерживаемые (полностью реализованные и протестированные), не применимые/неподдерживаемые, в работе/частичные и требующие валидации на живых средах.

Сколько вызовов платежей нужно реализовать для нескольких процессоров?
Основное утверждение репозитория: единый request schema позволяет одному вызову authorize работать с процессорами вроде Stripe и Adyen без дополнительных строк кода, специфичных для процессора.

Альтернативы

• Прямые интеграции по процессорам (множество SDK / API): Реализация для каждого платежного процессора отдельно. Это может увеличить код и обслуживание, специфичные для процессора, по сравнению с unified schema.
• Платформы оркестрации платежей / SaaS-коннекторы: Использование сторонней оркестрации для абстракции нескольких процессоров. Такие альтернативы обычно переносят сложность на платформу, а не используют библиотеку интеграции как слой трансформации.
• Другие stateless библиотеки-коннекторы или слои middleware: Выбор middleware, нормализующего запросы платежей между провайдерами. Различия в обработке vault/токенизации, хранении состояния и управлении покрытием/тестированием коннекторов.
• Прямое использование логики коннекторов Hyperswitch (без Prism как извлечения): Если вы уже работаете в Hyperswitch, можно опираться на компоненты платформы вместо adoption Prism как standalone unified библиотеки.