替代支付方式小部件
我们支持模块化、可嵌入的替代支付方式（APM）小部件，称为 Hyperwidgets，商户可以使用它们以低代码的方式增强现有的结账流程。
示例说明
在以下结账界面中，商户的当前支付服务提供商（PSP）仅支持信用卡和 PayPal。
但如果商户想启用更多的替代支付方式（APMs），可能会面临多种问题：
- 可用性问题：当前 PSP 可能不支持所需的替代支付方式，这迫使商户需要直接集成该支付方式或更换 PSP。
- 集成复杂：即使 PSP 支持所需的 APM，将其集成到现有结账流程中也非常繁琐，往往需要大量工程投入。而 Hyperwidgets 提供了一种低代码解决方案，商户可以通过大量连接器轻松集成首选支付方式，且工程成本极低。
- 扩展困难：传统 PSP 和中间层（如订阅提供商 SDK、代币提供商 SDK 或支付编排提供商 SDK）为每种新 APM 提供单独的集成方式，每次扩展都需要额外的工程投入。
- Hyperwidgets 提供了扩展 APM 的简便方式。例如，可以将结账方式从“Apple Pay”扩展到“Apple Pay + Google Pay”，再扩展到“Apple Pay + Google Pay + Amazon Pay + 其他 10 种支付方式”，且无需额外的工程工作。
- Hyperwidgets 还能基于订单上下文（如订单金额、用户地区等）动态显示合适的 APM。
- 集成开销问题：部分 PSP 在启用 APM 时可能需要额外的集成步骤，这通常耗时且占用商户大量技术资源。例如：
- 某些 APM 仅在新版 PSP API 中可用；
- 部分钱包支付方式（如 Apple Pay 和 Google Pay）需要商户通过认证后才能上线；
- 部分 APM 需要在前端添加新的 JS 库。
下图展示了使用 Hyperwidgets 后的结账页面，支持更多的 APM。
✅ 使用 Hyperwidgets 增加更多 APM 的结账页面示例
🛠️ Hyperwidgets 的技术架构
Hyperwidgets 旨在简化和优化商户集成替代支付方式的流程，无论其当前支付体系如何。该设计通过模块化、可嵌入和低代码的解决方案，显著减少了扩展支付方式所需的工程工作量。
1️⃣ 单一 SDK 管理所有 APM
Hyperwidgets 以单一 SDK 的形式打包，商户只需在其 Web 应用中集成该 SDK，并将部分 APM 流量路由至 Hyperwidgets。
该小部件由 JS 文件驱动，部署在商户的顶级域名下，从而作为商户结账流程的扩展，能够提供多种支付方式，包括：
- 快捷支付方式（如 Apple Pay、PayPal 等）
- 数字钱包（如 微信支付、支付宝 等）
- 先买后付（BNPL）（如 Klarna、Affirm 等）
- 银行借记和转账（如 ACH、BACS、SEPA 等）
2️⃣ 适配多种技术栈
Hyperwidgets 为不同技术栈的商户提供无缝集成能力，支持 React、HTML、Angular 等多种封装方式，确保集成工作量低且简单易用。
3️⃣ 与 PSP 配置解耦
Hyperwidgets 只需集成一次即可运行。商户可在管理后台配置不同的支付方式、PSP 和路由规则，无需额外的工程工作。
4️⃣ 模块化兼容其他集成
Hyperwidgets 与商户现有的 PSP 和中间层（如订阅服务、支付编排服务等）完全兼容，不会产生冲突。只需在结账流程的合适触发点调用 Hyperwidgets 并处理回调即可。
5️⃣ 高度自定义
Hyperwidgets 的 UI 支持高度自定义，商户可调整：
- 背景颜色
- 按钮圆角
- 字体大小
通过配置对象即可轻松控制 UI 风格，使其与商户品牌一致。
6️⃣ 统一分析与订单管理
通过 Hyperwidgets 处理的所有交易都可在统一的仪表盘上查看，商户可：
- 分析不同支付方式的转化率
- 按客户 ID、交易类型（如 3DS、非 3DS）筛选数据
- 查看失败原因及其占比
7️⃣ 未来兼容性
Hyperwidgets 的架构设计确保未来新增支付方式或 PSP 时无需额外工程工作，一次集成即可持续扩展。
8️⃣ 自定义 UI（即将推出）
商户将能够为每种支付方式自定义 UI，并调用 Hyperwidget.confirm() 函数提交支付数据，从而完全掌控支付方式的展示与交互。
✅ 支持的商户集成方案
- 方案 A：商户与单一 PSP 直接集成，并希望通过相同或不同的 PSP 启用 APM。
- 方案 B：商户通过中间层（如订阅服务或支付编排 SDK）与 PSP 间接集成，并希望启用 APM。
若有收获，就点个赞吧
0 人点赞
