hyperswitch-prism

hyperswitch-prism 是什么？

hyperswitch-prism 是一个无状态统一连接器库，用于集成支付处理器。它设计为提供单一请求/交互模式，从而在多个支付处理器间使用相同的调用模式，并减少代码变更。

Prism 由 Hyperswitch 开源支付平台背后的团队提取并维护。仓库将 Prism 描述为转型层，专注于连接器集成一致性，同时将 vault/令牌化、重试和路由逻辑等关注点留给 Hyperswitch。

跨连接器统一请求模式： 相同的 authorize 调用可用于多个处理器（例如 Stripe、Adyen），无需为每个处理器添加额外代码行。
无状态库（无需数据库、无存储 PII）： Prism 不需要数据库，避免存储个人数据；它声明凭证不被库存储或记录，仅在 HTTP 客户端生命周期内存在。
设计上控制 PCI 范围： 库可避免将卡数据引入 Prism；卡数据是否流经库被定位为选择项，可使用支付处理器 vault 或用户提供的 PCI 认证 vault。
持续连接器测试并发布状态模型： 连接器针对真实沙箱/生产环境持续测试，状态图例覆盖支持中、进行中/部分支持及需验证状态。
符合语法的多语言接口（按仓库文档）： Prism 被描述为类型安全的符合语法的接口，以多语言 SDK 形式打包。

选择适合您语言的 Prism SDK 并查看 SDK 指南中的认证和请求模式。
使用 Prism 的统一模式编写支付请求（例如，在不同支付处理器间使用相同的 authorize 调用形状）。
选择敏感支付数据处理位置：使用您自己的 PCI 认证 vault 或支付处理器的 vault，这与仓库说明的 vault/令牌化服务未内置 Prism 相符。
使用项目连接器覆盖/状态页面验证连接器覆盖，因为 Prism 描述了各连接器的支持水平不同。

多处理器结账集成： 您希望将支付操作路由至多个支付处理器，同时通过依赖 Prism 的统一请求模式将应用代码变更保持最小。
减少集成层状态和存储数据： 您的团队偏好无状态连接器层，其中 Prism 本身无需数据库且不存储或记录凭证。
通过 vault 选择对齐 PCI 责任： 您希望控制卡数据是否在基础设施内处理，并在支付处理器 vault 或您自己的 PCI 认证 vault 间选择。
工程团队长期维护连接器逻辑： 您需要针对沙箱/生产持续测试并逐连接器跟踪状态的连接器集成层。
在更大支付平台内转型层集成： 您将 Prism 用作转型层，同时在其他地方实现重试/路由逻辑（仓库指向 Juspay Hyperswitch 处理这些方面）。

Prism 是否负责重试和路由逻辑？

否。仓库说明，重试或路由逻辑位于 Juspay Hyperswitch 中；Prism 作为转换层。

Prism 是否包含内置保险库或令牌化服务？

否。这是设计选择；您可自带保险库或使用支付处理器的保险库。

Prism 是否存储凭证或 PII？

仓库说明，库不存储或记录凭证，它是无状态的、无数据库，且不存储 PII。还指出凭证仅在您的 HTTP 客户端生命周期内存在。

如何了解支持的支付处理器和支付方式？

Prism 发布连接器覆盖情况，并附带图例，标明支持（完全实现并测试）、不适用/不支持、进行中/部分，以及需针对生产环境验证的实现。

集成多家处理器需要实现多少支付调用？

仓库核心声明是，单一请求模式可让相同的 authorize 调用跨 Stripe 和 Adyen 等处理器工作，而无需额外处理器特定代码行。

直接逐处理器集成（多个 SDK / API）： 分别针对每个支付处理器实现。这会增加处理器特定代码和维护成本，与统一模式相比。
支付编排平台 / SaaS 连接器： 使用第三方编排抽象多家处理器。这些替代方案通常将复杂性转移到平台，而不是使用集成库作为转换层。
其他无状态连接器库或中间件层： 选择标准化跨提供商支付请求的中间件。差异在于它们如何处理保险库/令牌化、是否保持状态，以及连接器覆盖/测试的管理方式。
直接使用 Hyperswitch 连接器逻辑（不提取 Prism）： 如果已在 Hyperswitch 内运行，可依赖更广泛的平台组件，而非采用 Prism 作为独立统一库。