hyperswitch-prism

hyperswitch-prism이란?

hyperswitch-prism은 결제 프로세서 연동을 위한 무상태 통합 커넥터 라이브러리입니다. 단일 요청/상호작용 스키마를 제공하도록 설계되어 여러 결제 프로세서에서 동일한 호출 패턴을 코드 변경을 최소화하며 사용할 수 있습니다.

Prism은 오픈소스 결제 플랫폼 Hyperswitch를 만든 팀에서 추출하고 유지보수합니다. 리포지토리는 Prism을 커넥터 연동 일관성에 중점을 둔 변환 레이어로 설명하며, 볼트/토큰화, 재시도, 라우팅 로직 등의 사항은 Hyperswitch에 맡깁니다.

커넥터 전반의 단일 통합 요청 스키마: 동일한 authorize 호출이 여러 프로세서(예: Stripe, Adyen)에 추가 코드 없이 작동합니다.
무상태 라이브러리(데이터베이스 없음, PII 저장 없음): Prism은 데이터베이스가 필요 없으며 개인 데이터를 저장하지 않습니다. 자격 증명은 라이브러리에서 저장/로깅되지 않고 HTTP 클라이언트 수명 동안만 존재합니다.
설계상 PCI 범위 제어: 라이브러리가 카드 데이터를 Prism으로 가져오지 않도록 할 수 있습니다. 카드 데이터 흐름(또는 비흐름)은 선택 사항으로, 결제 프로세서 볼트나 사용자 제공 PCI 인증 볼트를 사용할 수 있습니다.
발행된 상태 모델과 지속적 커넥터 테스트: 커넥터는 실제 샌드박스/프로덕션 환경에서 지속적으로 테스트되며, 지원됨, 진행 중/부분적, 검증 필요 상태를 포함한 상태 범례가 있습니다.
리포지토리 문서에 따른 관용적 다국어 인터페이스: Prism은 타입 안전하고 관용적인 인터페이스로 다국어 SDK로 패키징됩니다.

언어에 맞는 Prism SDK 선택하고 인증 및 요청 패턴을 위한 SDK 가이드 검토.
Prism의 통합 스키마로 결제 요청 작성(예: 다른 결제 프로세서 전반에 동일한 authorize 호출 형태 사용).
민감한 결제 데이터 처리 위치 선택: 자체 PCI 인증 볼트나 결제 프로세서 볼트 사용. 리포지토리 노트에 따라 Prism에 볼트/토큰화 서비스가 내장되지 않음.
프로젝트의 커넥터 커버리지/상태 페이지로 필요 커넥터 커버리지 검증. Prism은 커넥터별 지원 수준이 다양함.

다중 프로세서 결제 연동: Prism의 통합 요청 스키마를 활용해 여러 결제 프로세서로 결제 작업 라우팅 시 애플리케이션 코드 변경 최소화.
연동 레이어의 상태 및 저장 데이터 감소: Prism 자체가 데이터베이스 불필요하고 자격 증명 저장/로깅하지 않는 무상태 커넥터 레이어 선호.
볼트 선택으로 PCI 책임 조정: 카드 데이터가 인프라 내 처리 여부 제어하고 결제 프로세서 볼트 또는 자체 PCI 인증 볼트 선택.
시간 경과에 따른 커넥터 로직 유지 엔지니어링 팀: 샌드박스/프로덕션에 지속 테스트되고 커넥터별 상태 추적되는 연동 레이어 필요.
대형 결제 플랫폼 내 변환 레이어 연동: Prism을 변환 레이어로 사용하고 재시도/라우팅 로직은 별도 구현(리포지토리는 Juspay Hyperswitch 지목).

Prism이 재시도 및 라우팅 로직을 담당하나요?
아니요. 저장소에서 재시도나 라우팅 로직은 Juspay Hyperswitch에 있으며, Prism은 변환 레이어로 제시됩니다.

Prism에 내장된 볼트나 토큰화 서비스가 포함되나요?
아니요. 이는 설계 선택으로 설명되며, 자체 볼트를 사용하거나 결제 프로세서의 볼트를 사용할 수 있습니다.

Prism이 자격 증명이나 PII를 저장하나요?
저장소에서 라이브러리가 자격 증명을 저장하거나 로깅하지 않으며, 무상태로 데이터베이스가 없고 PII를 저장하지 않는다고 명시합니다. 자격 증명은 HTTP 클라이언트 수명 동안만 존재합니다.

지원되는 결제 프로세서와 결제 방법을 어떻게 확인할 수 있나요?
Prism은 지원 범위를 게시하며, 범례에서 완전 구현 및 테스트된 지원, 적용 불가/미지원, 진행 중/부분, 라이브 환경 검증이 필요한 구현을 표시합니다.

여러 프로세서에 대해 몇 개의 결제 호출을 구현해야 하나요?
저장소의 핵심 주장은 단일 요청 스키마로 Stripe나 Adyen 같은 프로세서 간 동일한 authorize 호출이 추가 프로세서별 코드 없이 작동할 수 있다는 것입니다.

프로세서별 직접 통합 (여러 SDK / API): 각 결제 프로세서를 별도로 구현합니다. 이는 통합 스키마에 비해 프로세서별 코드와 유지보수를 증가시킬 수 있습니다.
결제 오케스트레이션 플랫폼 / SaaS 커넥터: 타사 오케스트레이션을 사용해 여러 프로세서를 추상화합니다. 이러한 대안은 변환 레이어로 통합 라이브러리를 사용하는 대신 복잡성을 플랫폼으로 이전합니다.
기타 무상태 커넥터 라이브러리 또는 미들웨어 레이어: 제공자 간 결제 요청을 정규화하는 미들웨어를 선택합니다. 차이점은 볼트/토큰화 처리 방식, 상태 유지 여부, 커넥터 범위/테스트 관리입니다.
Prism 추출 없이 Hyperswitch 커넥터 로직 직접 사용: Hyperswitch 내에서 이미 운영 중이라면, 독립 통합 라이브러리로 Prism을 채택하는 대신 광범위한 플랫폼 구성 요소에 의존할 수 있습니다.