hyperswitch-prism

hyperswitch-prism とは？

hyperswitch-prism は、決済プロセッサとの統合のためのステートレスな統一コネクタライブラリです。単一のリクエスト/インタラクションスキーマを提供するよう設計されており、複数の決済プロセッサ間で同じ呼び出しパターンを最小限のコード変更で使用できます。

Prism は、オープンソース決済プラットフォーム Hyperswitch の背後にあるチームによって抽出・メンテナンスされています。リポジトリでは、Prism をコネクタ統合の一貫性に焦点を当てた変換レイヤーと記述しており、ボールト/トークナイゼーション、リトライ、ラウティングロジックなどの懸念事項は Hyperswitch に委ねています。

主な機能

• コネクタ全体で統一されたリクエストスキーマ： 同じ authorize 呼び出しが複数のプロセッサ（例: Stripe、Adyen）で追加のプロセッサ専用コードなしで動作します。
• ステートレスライブラリ（データベース不要、PII 格納なし）： Prism はデータベースを必要とせず、個人データを格納しません。ライブラリは認証情報を格納・ログせず、HTTP クライアントの寿命中のみ存在すると述べています。
• 設計による PCI スコープ制御： ライブラリはカードデータを Prism に持ち込まないことが可能です。ライブラリを通る（または通らない）カードデータの流れは選択事項で、決済プロセッサのボールトやユーザー提供の PCI 認定ボールトを使用できます。
• 公開ステータスモデルによる継続的なコネクタテスト： コネクタは本物のサンドボックス/本番環境で継続的にテストされ、サポート済み、進行中/部分対応、検証必要の状態をカバーするステータスレジェンドがあります。
• イディオマチックで多言語インターフェース（リポジトリドキュメントによる）： Prism は型安全でイディオマチックなインターフェースとして、多言語 SDK にパッケージ化されています。

hyperswitch-prism の使い方

1. お使いの言語向け Prism SDK を選択 し、認証とリクエストパターンの SDK ガイドを確認します。
2. Prism の統一スキーマで決済リクエストを作成 （例: 異なる決済プロセッサ間で同じ authorize 呼び出し形状を使用）。
3. 機密決済データの処理場所を選択： 独自の PCI 認定ボールトまたは決済プロセッサのボールトを使用（リポジトリの注意事項通り、Prism にはボールト/トークナイゼーションサービスが組み込まれていません）。
4. ニーズに合ったコネクタカバレッジを検証： プロジェクトのコネクタカバレッジ/ステータスページを使用して、コネクタごとのサポートレベルが異なることを Prism が記述しています。

ユースケース

• マルチプロセッサチェックアウト統合： Prism の統一リクエストスキーマに依存してアプリケーションコード変更を最小限に抑えつつ、決済操作を複数の決済プロセッサにルーティングしたい場合。
• 統合レイヤーの状態と格納データを削減： チームがデータベース不要で認証情報を格納・ログしないステートレスコネクタレイヤーを好む場合。
• ボールト選択による PCI 責任の調整： カードデータが自社インフラ内で処理されるかを制御し、決済プロセッサのボールトか独自の PCI 認定ボールトかを選択したい場合。
• 長期的にコネクタロジックをメンテナンスするエンジニアリングチーム： サンドボックス/本番で継続テストされ、コネクタごとのステータスで追跡されるコネクタ統合レイヤーが必要な場合。
• 大規模決済プラットフォーム内の変換レイヤー統合： Prism を変換レイヤーとして使用し、リトライ/ラウティングロジックを別途実装（リポジトリはこれらの側面で Juspay Hyperswitch を指しています）。

FAQ

Prism はリトライやルーティングロジックを担当しますか？ いいえ。リポジトリでは、リトライやルーティングロジックは Juspay Hyperswitch にあり、Prism は変換レイヤーとして位置づけられています。

Prism にビルトインの vault やトークン化サービスは含まれていますか？ いいえ。これは設計上の選択です。独自の vault を使用するか、決済プロセッサの vault を利用できます。

Prism は認証情報や PII を保存しますか？ リポジトリでは、ライブラリは認証情報を保存・ログせず、ステートレスでデータベースなし、PII を保存しないと述べられています。また、認証情報は HTTP クライアントの寿命中のみ存在します。

どの決済プロセッサと決済方法がサポートされているかをどう確認できますか？ Prism はコネクタのカバレッジを公開しており、凡例でサポート済み（完全実装・テスト済み）、非該当/未サポート、進行中/部分実装、実装検証が必要（本番環境）を示しています。

複数プロセッサで何件の決済呼び出しを実装する必要がありますか？ リポジトリの核心的主張は、単一リクエストスキーマにより、Stripe や Adyen などのプロセッサ間で同じ authorize 呼び出しが追加のプロセッサ固有コードなしで動作することです。

代替案

• プロセッサごとの直接統合（複数 SDK / API）： 各決済プロセッサごとに個別に実装します。統一スキーマに比べてプロセッサ固有コードとメンテナンスが増えます。
• 決済オーケストレーションプラットフォーム / SaaS コネクタ： サードパーティのオーケストレーションで複数プロセッサを抽象化します。これらは通常、変換レイヤーとしての統合ライブラリではなく、プラットフォーム側に複雑さを移します。
• 他のステートレスコネクタライブラリやミドルウェアレイヤー： プロバイダ間で決済リクエストを正規化するミドルウェアを選択します。違いは vault/トークン化の扱い、ステート保持の有無、コネクタのカバレッジ/テスト管理にあります。
• Hyperswitch のコネクタロジックを直接使用（Prism を抽出なしで）： Hyperswitch 内で運用中の場合、Prism をスタンドアロン統一ライブラリとして採用せず、より広範なプラットフォームコンポーネントに依存できます。