SCA 实施
使用 Rapid API 生成 SCA-compliant 预订
无论您是使用 Rapid API 作为记录商户,还是允许旅客到达时付款,您都可以采用 Rapid 的 API 解决方案来生成符合 SCA 法规的预订。我们的 API 通过在预订流程中使用 3D-Secure (3DS) 2.0 来支持 SCA 合规性。3DS 2.0 支持 risk-based 身份验证,通过赋予银行何时要求旅客进行安全身份验证的自主权,减少了旅客的摩擦。
3DS 2.0 的解决方案包含三个不 同的步骤:
您将向 check-out 页面添加一个 iframe,该页面用于托管发卡银行为旅行者提供的身份验证体验。在集成文档中,这被称为 3DS iframe。
>>了解更多关于 iframe 的信息您还将在 check-out 页面上添加一个新的 client-side JavaScript 库,该库用于收集浏览器数据、与 iframe 通信以及在 iframe 中显示 SCA 体验。在集成文档中,这被称为 3DS 连接器库。
Rapid API 将接受银行的付款人信息,并在安全认证完成后完成预订。
当同时使用 JavaScript 和 Rapid API 时,使用 SCA 的预订流程现在将在调用 Booking API 之前和之后增加一些步骤。下图描绘了这个更新后的预订流程。

在修订后预订流程的每个步骤中,一个步骤的输出中包含着用作下一步输入的数据。数据将需要在浏览器上的 JavaScript 和 Rapid 之间传递。
集成组件详细信息
SCA 的实现始于浏览器 check-out 体验,然后进入 Rapid API 流程。
浏览器
放置在 check-out 体验中的 iframe 承载着向用户显示的身份验证体验,并将任何 traveler-supplied 信息直接传输到他们的银行;内容由旅行者的 card-issuing 银行拥有的 URL 提供。Iframe 最初应该隐藏,但在预订尝试后需要进行身份验证时,可以将其覆盖在页面上方。
JavaScript 库
该库已添加到 check-out 页面,并在预订时调用以支持身份验证过程。该库的 API 支持以下描述的功能。
旅行者设备信息
在尝试预订之前,必须收集有关旅行者设备的信息,以便准备预订进行身份验证。该信息将发送给旅行者的银行,以评估风险,决定交易是否需要 3DS 2.0 认证,并确保其正确显示。根据 3DS 2.0 规范,将从旅行者的浏览器收集以下数据:语言、颜色深度、屏幕高度、屏幕宽度、时区、用户代理以及是否启用 Java。
身份验证显示
预订尝试完 成后,该库用于显示 iframe 叠加层并将银行的内容加载到其中。在身份验证过程中,银行可能会收集有关旅行者设备的其他信息,以支持其风险评估。此流程是完成预订的必要步骤。
Rapid API
Rapid API 包含与 client-side JavaScript 库协同工作的 API。这些 API 现在支持下述功能。
旅客和付款详情
在尝试预订之前,Rapid API 需要收集有关旅行者的其他信息,以便进行身份验证,包括有关旅行者的信息,例如销售点和付款方式。之后,这些数据将被发送到旅行者的银行,以评估风险并决定交易是否需要安全认证。了解更多信息,请查看快速预订 API 中的注册支付 API。
付款和预订确认
预订尝试完成后,当浏览器中的 SCA 流程完成后,必须再次调用 Rapid API。后台,我们会确认身份验证是否成功,以便确认预订。请查看 Rapid Booking API 中的“完成付款”部分,了解更多信息。
预订流程
下面图示为旅客发起预订后所需的 API 调用顺序。该序列涉及对 JavaScript 库和 Rapid API 的调用。

准备进行身份验证的预订信息可能并非总是需要验证的。是否需要进行身份验证由用于支付的信用卡的发卡银行决定。该判断是在交易过程中进行的,并在创建预订 API 响应中指示。
Rapid Lodging API 还提供暂停和恢复功能。以下是该功能所需的 API 调用顺序。
